إيجاد الكائنات في وصف المشكلة
في هذا الدرس 11 موضوعات
هذا الدرس متاح حاليًا باللغة الإنجليزية فقط، ولم تُنشر نسخته العربية بعد.
Lesson Overview
You can now describe an object (state and behavior) and tell a class from an object. The next skill is the one you will use at the start of every real project: reading a plain-language description of a problem and deciding which classes it needs.
A classic first technique is the noun and verb hunt. You read the text, underline the nouns (candidates for classes or for state) and the verbs (candidates for behavior), and then filter the list by asking whether each candidate has state and behavior that matter in this problem. The filter is the important part: the most common mistake is to make a class for every noun.
Why this matters: this is the beginning of domain modeling, which senior backend developers and architects do daily. The technique is a first guess, not a law. You will improve your guesses as you learn more.
This lesson builds on state and behavior (lesson 2) and classes versus objects (lesson 3). No Java is needed here; we work on text.
Learning Objectives
By the end of this lesson you will be able to:
- Underline the nouns and verbs of a short problem description.
- Turn nouns into candidate classes and verbs into candidate behaviors.
- Recognize nouns that are really state (fields) of another class.
- Reject nouns that are outside the system, duplicate another noun, or have nothing to do.
- Justify each kept and rejected candidate in one sentence.
- Say why the result is a first draft that you will revise.
Written Explanation
The technique in five steps
- Read the description once for meaning. Do not underline yet.
- Underline nouns and noun phrases. These are candidate classes or candidate state.
- Underline verbs. These are candidate behaviors, and they hint at which noun performs them.
- Filter the nouns with the tests below.
- Attach each surviving verb to the class whose data it needs, then write down each class's state and behaviors.
Noun/verb analysis is a widely taught way to get a first set of candidate classes from a requirements text, usually followed by other checks. It depends on judgement: two people can get slightly different lists, and that is normal.
The filtering tests
For every noun, ask:
| Test | Question | If the answer is yes |
|---|---|---|
| Outside the system | Is it something the program does not manage or model (the weather, "the user" who simply types)? | Reject it |
| Synonym | Is it another word for a noun already on the list ("client" and "customer")? | Merge them |
| Just a value | Is it a simple fact about something else (a balance, a name, a date)? | Keep it as state (a field) of that thing |
| Nothing to do | Does it have no state or behavior that matters in this problem? | Reject, or keep as a plain value |
| Has state and behavior | Does it know things and do things that the problem needs? | Keep it as a candidate class |
Two special cases deserve attention.
"Money". In a bank text, money appears everywhere. Is it a class? Usually not at this stage: an amount is just a number (in this course, cents in an int). It would become a class only if it had behavior of its own that mattered, such as converting currencies. Do not make it automatically.
A noun that is really an event. "A transaction" (a deposit or withdrawal that is recorded) has state (amount, date, type) and the bank keeps a list of them, so it often does deserve a class. Nouns for things the system must remember over time are good candidates.
Where do verbs go?
A verb tells you a behavior, and the noun that performs it or owns the data it needs usually gets it. "The customer deposits money" gives the verb deposit. Who needs to change when a deposit happens? The account, because its balance changes. So deposit belongs to the account, even though the sentence's subject was the customer. The customer may ask for a deposit; the account does the work on its own balance.
This is the lesson of the demo that follows: keep behavior together with the data it changes. When a verb needs data from two classes, you will often let the more important one coordinate and ask the other to do part of the work. Lesson 5 and the next module show how.
It is a first guess
You will rename classes, merge them, split them, and move behaviors as you learn the real rules of the problem. If a class ends up with no behavior, that is a signal to reconsider whether it deserves to be a class. The reward for a good first draft is not perfection; it is having something concrete to discuss and improve.
Examples
Example 1: the spec's three sentences (simple)
A customer opens an account. The customer deposits money. The bank keeps a record of each transaction.
Nouns: customer, account, money, bank, transaction. Verbs: opens, deposits, keeps a record.
| Noun | Decision | Reason |
|---|---|---|
| customer | keep | Has a name and takes part in the actions |
| account | keep | Has a balance and must handle deposits |
| money | not a class (for now) | A number (amount in cents); no behavior of its own here |
| bank | keep (for now) | It opens accounts and keeps records; may later be a manager of accounts |
| transaction | keep | Has an amount, type, and date, and must be remembered |
Verbs attached: open account (the bank creates an account for a customer), deposit (the account), record (the bank keeps transactions).
Candidate classes: Customer, Account, Bank, Transaction.
Example 2: a library (practical)
The library lends books to members. Each book has a title and an author. A member can borrow up to three books. The librarian records every loan and the return date. When a book is returned, it becomes available again. The weather affects how many people come.
Nouns: library, books, members, title, author, librarian, loan, return date, weather, people.
| Noun | Decision | Reason |
|---|---|---|
| library | keep or merge | The whole system; it may become the class that holds the lists |
| book | keep | Title and author state, plus available; behavior: lend, return |
| member | keep | Has a name and a limit of three loans |
| title, author | state of Book | Simple facts |
| return date | state of Loan | A value attached to a loan |
| loan | keep | Links a member to a book and holds a return date |
| librarian | reject or later | In this text the librarian only performs the recording; nothing needs a Librarian object |
| weather, people | reject | Outside the system; "people" duplicates "members" |
Verbs: lends, has (title), borrow, records, returned, becomes available. Attach: borrow to a member (checks the limit), lend/return to the book (changes its availability), recording to the loan or library.
Candidate classes: Book, Member, Loan (and perhaps Library). Note that the librarian could become a class later, if the problem adds librarian-specific data such as a login. A rejection is a decision for now, not forever.
Example 3: from an almost-class-per-noun disaster to a sensible model (realistic)
A small gym sells monthly subscriptions. A member pays a monthly fee. The gym keeps a list of members and checks them in at the door. A trainer assigns a workout plan to each member. The gym has a reception, a car park, and a juice bar.
Nouns: gym, subscription, member, fee, list, door, trainer, workout plan, reception, car park, juice bar.
A class-per-noun attempt gives eleven classes, including Door, List, Reception, CarPark, JuiceBar. Most have no state or behavior that the problem needs.
Filtering:
Reception,CarPark,JuiceBar: reject, nothing in the text depends on them. (If the text said "the juice bar sells drinks to members", that would change.)List: reject, a list is a way to store members (an array or another collection later), not a business thing.Door: reject; "checks them in at the door" is a behavior (checkIn) of the gym or member.Fee: state of the subscription (an amount in cents).Subscription: keep; it has a start, a fee, and can be paid or expire.Member,Trainer,WorkoutPlan: keep; they have data and actions the text describes.
Result: Gym, Member, Subscription, Trainer, WorkoutPlan. Five classes instead of eleven.
Backend Insight
Real requirements arrive as emails, tickets, and meeting notes, not as neat class lists. The first design step in a backend project is exactly this: read the description, find the nouns that the system must remember (customers, orders, payments, products), and find the verbs that change them (place an order, cancel, refund). The nouns that must be remembered usually become the database tables and Java classes you will meet later; the verbs become the operations your service offers.
A second habit: whenever two stakeholders use different words for one thing ("client" and "customer"), settle on one. Synonyms in the description become duplicate classes in the code, and duplicate classes become bugs.
The technique also has limits. It tells you about things the text mentions and may miss things nobody said out loud. In practice you combine it with asking questions about the business.
Common Mistakes
Mistake 1: A class per noun
- Incorrect: "The text has eleven nouns, so I need eleven classes."
- Correct: "I keep nouns that have state and behavior that matter here; others become fields or are rejected."
Mistake 2: Treating every noun as a class instead of as a field
"Balance", "title", "name", "date" are usually state (fields) of something. A sign: a noun that is only ever described by "has" or "is" in the text is likely state.
Mistake 3: Putting a verb on the wrong noun
- Incorrect: "The customer deposits, so
depositis a method ofCustomerthat changes the account's balance from outside." - Correct: "The balance belongs to the account, so the account has
deposit. The customer may call it."
This is the common-mistake note from the module: behavior separated from the data it acts on.
Mistake 4: Treating the first list as final
A first noun/verb pass is a draft. Merge synonyms, drop empty classes, and move behaviors as you understand the problem better.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. Underline the nouns and verbs: "A passenger buys a ticket. The driver checks the ticket."
أظهر الحل A1
A1. Nouns: passenger, ticket, driver. Verbs: buys, checks.
A2. Is "price" more likely a class or a field of Ticket? Why?
أظهر الحل A2
A2. More likely a field: it is a simple fact about a ticket and has no behavior of its own.
A3. Is "the weather" a good candidate class for a ticket-selling program? Why or why not?
أظهر الحل A3
A3. No: it is outside what the program manages and has nothing the program needs to know or do.
Level B: Application
B1. Run the noun/verb hunt on: "A pharmacy sells medicines to customers. Each medicine has a name, a price, and an expiry date. The pharmacist checks the expiry date before every sale. The pharmacy has a nice sign above its door." List the nouns, mark each keep, field, or reject, with one reason each.
أظهر الحل B1
B1. Nouns: pharmacy (keep, as the holder of the stock, or merge into a Pharmacy class), medicines (keep: class Medicine), customers (keep, if you track them; or reject if the sale does not need customer data, say so), name, price, expiry date (fields of Medicine), pharmacist (keep or fold into pharmacy behavior, depending on data), sale (keep as a class if the pharmacy records sales), sign and door (reject: nothing depends on them). Reasons will vary; the key is that sign/door are rejected and name/price/expiry date are fields.
B2. From your B1 list, write the state and behaviors of each class you kept.
أظهر الحل B2
B2. Example. Medicine: state name, price in cents, expiry date; behaviors: check whether expired, sell. Sale: state medicine, customer, amount; behavior: record. Pharmacy: state list of medicines; behavior: sell a medicine after the expiry check. (Any sensible version is fine.)
B3. The text says "the customer pays the cashier". Which candidate class should own a pay behavior if the problem is about recording the sale? Explain your choice and say what you would need to know to be sure.
أظهر الحل B3
B3. Example answer: Sale or Pharmacy should coordinate the payment record because the problem is recording the sale; a Cashier class makes sense only if the cashier has data or rules the problem needs. To be sure you need to know whether cashiers have their own data (name, shift) and rules.
Level C: Challenge
C1. Write your own three-sentence description of a small system (a pet shelter, a bike rental) with at least two nouns that should be rejected and two that should become fields. Exchange it mentally with a classmate: list the candidates you would choose and the reasons.
أظهر الحل C1
C1. Answers vary. Check: rejected nouns have a reason (outside the system, no behavior), fields are simple values, and kept classes have both state and behavior.
C2. A teammate's analysis of the pharmacy text produced classes Name, Price, ExpiryDate, Sign, Medicine. Review it: which are wrong and why? What would you change?
أظهر الحل C2
C2. Name, Price, and ExpiryDate are state of Medicine and should be fields (they are simple values with no behavior needed here). Sign is outside the system and should be rejected. Medicine is correct. This is the class-per-noun mistake.
Mini Challenge
Write a six-to-eight-sentence description of a small system you know well (a school canteen, a car wash, an online course). Include on purpose at least two nouns that are outside the system and at least two that are just values.
Then perform the noun/verb hunt:
- Underline every noun and verb in your text.
- Make a table of the nouns: keep, field, merge, or reject, with one-sentence reasons.
- For each kept class, list state and behaviors, attaching each verb to the class that owns the data it changes.
- Write one sentence naming something you are unsure about, and what question you would ask the client.
Check your work: you rejected at least one noun with a reason, every verb is attached to some class, and no field is listed as a class.
Summary & Next Lesson
Key takeaways
- Nouns are candidate classes or state; verbs are candidate behaviors.
- Filter each noun: outside the system, synonym, just a value, nothing to do, or a real class with state and behavior.
- Do not make a class for every noun.
- Attach a verb to the class that owns the data it changes, not necessarily the sentence's subject.
- The result is a first draft you will revise.
Next lesson
Next is "Demo: rewriting a procedural bank as objects". You will take the parallel-array bank from lesson 1 and turn it into an Account class, step by step, using the ideas of the last four lessons, and prepare for the module's noun and verb lab.
Self-check
- What do nouns suggest, and what do verbs suggest?
- Should "money" automatically become its own class?
- Name two reasons to reject a noun.
- In "The customer deposits money", which class should own
deposit? - Why is the first noun/verb list only a draft?
أظهر الإجابات
- Nouns suggest candidate classes or state; verbs suggest candidate behaviors.
- No. It may be just a number field for now, unless it has its own behavior that matters.
- It is outside the system; it is a synonym of another noun; it is just a value; it has no state or behavior that matters.
- The account, because it owns the balance that changes.
- Because you understand the problem better over time, so classes get merged, split, renamed, and behaviors move.
References
- Search results I reviewed (a university lecture on finding analysis classes, class notes on object-oriented analysis, and noun-phrase analysis slides) describe noun/verb analysis as a common first pass for candidate classes and responsibilities, followed by refinement. I could not open these pages (one refused the connection, the other was an unreadable PDF), so the claim that the technique is a widely taught first step rests on the search summaries, and the filtering tests are my own teaching simplification of it. For example: Lecture 7: Finding Analysis Classes, not opened.
- Oracle, The Java Tutorials: What Is an Object?. Supports the idea that an object has state and behavior, which is the test used to keep or reject a candidate.
التطبيق
طبّق هذا الدرس بمختبر الوحدة وتمارينها واختبارها.
تعليم الدرس كمكتمل اختياري ويمكنك التراجع عنه في أي وقت. يبقى تقدمك محفوظًا في هذا المتصفح.