Object-Oriented Design
Overall View
Object-oriented design is focused on identifying objects and operations. Here's a high-level view of the process:
I personally start by parsing the statement of the problem (from its original form as a paragraph of English) into nouns and verbs, eliminating redundancies, and creating a mapping between nouns and data structures and verbs and transformations of data structures.- Paul Fisher (ap-compsci, 8/98)
Identifying Objects (and Classes)
- Identify the nouns (objects) in the problem description.
- Identify more objects in your developing problem solution. (Design is incremental and iterative! -- Grady Booch)
- From these objects, determine what new types (classes) you need.
Example: BlackJack Program
- cards
- a deck
- a dealer
- player(s)
Sample Design Questions:
- Do different cards represent different types? Or are suit and rank attributes of a single card type?
- Are the dealer and player instances of the same class? I.e., objects of the same type?
- Should there be a separate Hand class?
Identifying Operations
- Identify what can be done to objects. or
- Identify what objects can do for themselves. or
- Identify who is responsible for doing what.
- Terminology: operations, responsibilities, contracts, message passing, encapsulation, data hiding
Example: BlackJack Program
- Card: display, report value (report suit? maybe internally) (modify value/suit? or set these in constructor only?)
- Deck: shuffle, deal next card, report how many cards left in deck
- Dealer: deal cards, add card to hand, show (sometimes partial) hand, calculate (partial) hand value, number of cards in hand, hit?, determine winner, reset hand
- Player: add card to hand, show hand, calculate hand value, number of cards in hand, hit?, reset hand
Identifying Relationships
- Identify object relationships, e.g. what objects need to know about what other objects, what objects are part of other objects.
- Terminology: collaboration; aggregation/has-a relationships; knows-about relationships
(Note: is-a relationships are class relationships, not object relationships. They should be handled separately, usually by inheritance.)
Example: BlackJack Program
- Card:
- Deck: has cards
- Dealer: has deck, has cards (or hand, which has cards), knows about player(s)
- Player: has cards (or has hand, which has cards)
Developing Scenarios
- Develop scenarios of how the objects interact to see if you have identified the right objects, the right operations, and the right relationships.
- Develop common scenarios (this is how the thing should usually work).
- Remember to also develop uncommon scenarios, "weird cases," boundary conditions.
- Scenarios are similar to, but more informal than, design-based test cases.
- Developing scenarios will often cause you to recognize new design requirements. Remember that design is incremental and iterative! (Grady Booch)
Implementing an Object-Oriented Design
- Design public interfaces (public member function declarations) for the classes and operations you identified in the design.
- Design the internal data representation (private data members). Include information about relationships.
- Implement the public member functions. Identify useful internal helper functions (private member functions).
- Test individual objects and member functions before putting everything together.
For More Information ...
Excellent Book for Beginners:
- Designing Object-Oriented Software by Wirfs-Brock, Wilkerson, and Wiener, Prentice Hall, 1990.
UML:
- UML Distilled: Applying the Standard Object Modeling Language by Martin Fowler, Addison-Wesley, 1997.
- latest edition of Object-Oriented Design by Booch, Benjamin Cummings
- latest UML book by Booch, Rumbaugh, etc