Designing with Objects: Deciding What Each Class Owns
Reading a problem description and deciding which things deserve a class, what each one is responsible for, and where the boundaries between them fall. The judgement is about responsibility, not about syntax.
What a learner can do afterwards
- Pull candidate classes and responsibilities out of a written problem description
- Defend a boundary: say why one piece of data belongs to this class and not that one
- Spot a class that has taken on two unrelated jobs and split it
1 · Read
Read the requirements and identify the records or things the system must represent. Nouns suggest candidate classes, but a noun might instead be a field or a value. In a library, Book, Member and Loan are candidates because the system tracks books, members and individual borrowing relationships.
Responsibilities come from required actions and rules, not names alone. Verbs can suggest actions, but check which class has the information and duty to perform them. A Book can maintain its title; a Loan can track one borrowing relationship. A method belongs where its responsibility is clear.
Enrollment links one learner to one course and maintains enrollment dates. Those dates describe the relationship, so Enrollment owns their updates. Learner maintains learner details. Frequent reading alone does not establish ownership.
Cohesion means related state and methods serve one purpose. Account's deposit and withdraw both maintain its balance. The word and does not prove a split. Separate responsibilities when their rules or reasons for change differ.
Customer maintains and validates its email address. A newsletter reads it to send a message. That read does not transfer maintenance to Newsletter. Keep one maintained address and request it when needed, rather than allowing separately editable copies to disagree.
To split unrelated responsibilities, identify each group of state and the methods that maintain it. Move each group together, give it a clear owner, then replace cross-group access with defined requests. For example, payroll calculations and weather readings need different rules. A vague name is a clue to inspect, not proof that a split is required.
Use requirements to find candidate records and duties. Put maintained data with its responsible owner. Consider a split when responsibilities have different rules or change separately.
Object-design teaching, examples and assessment repairs independently written for this dataset.
Records before class names, One maintained value, many readers and Related work and separate rules were independently written for this dataset.
2 · Watch
به انگلیسیTake it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.