Chapter 7 achieving object-oriented design
- 1. ACHIEVING OBJECT- ORIENTED DESIGN Sergio Andrés Rodríguez Galeano
- 2. How Writing a Test First Helps the Design 1. Starting with a test means that we have to describe what we want to achieve before we consider how. 2. To keep unit tests understandable, we have to limit their scope. 3. To construct an object for a unit test, we have to pass its dependencies to it, which means that we have to know what they are.
- 3. Communication over Classification ● We view a running system as a web of communicating objects, so we focus our design effort on how the objects collaborate to deliver the functionality we need. ● In languages such as Java, we can use interfaces to define the available messages between objects, but we also need to define their patterns of communication, their communication protocols.
- 4. Values Types ● Values are immutable, so they’re simpler and have no meaningful identity ● Objects have state, so they have identity and relationships with each other. ● There are three basic techniques values types: Breaking out, Budding off and Bundling up.
- 5. Breaking out, Budding off and Bundling up ● Breaking out: When we find that the code in an object is becoming complex. ● Budding off: When we want to mark a new domain concept in code. ● Bundling up: When we notice that a group of values are always used together, we take that as a suggestion that there’s missing construct.
- 6. Breaking Out: Splittings a Large Object into a Group of Collaborating Objects ● When starting a new area of code, we might temporarily suspend our design judgment and just write code without attempting to impose much structure. ● Break up an object if it becomes too large to test easily, or if its test failures become difficult to interpret. Then unit-test the new parts separately.
- 7. Budding Off: Defining a New Service that an Object Needs and Adding a New Object to Provide It ● When the code is more stable and has some degree of structure, we often discover new types by “pulling” them into existence. ● When writing a test, we ask ourselves, “If this worked, who would know?” If the right answer to that question is not in the target object, it’s probably time to introduce a new collaborator.
- 8. Bundling Up: Hiding Related Objects into a Containing Object ● This is the application of the “composite simpler than the sum of its parts” rule. ● When we have a cluster of related objects that work together, we can package them up in a containing object. ● When the test for an object becomes too complicated to set up, when there are too many moving parts to get the code into the relevant state, consider bundling up some of the collaborating objects.
- 9. Identify Relationships with Interfaces ● We use interfaces to name the roles that objects can play and to describe the messages they’ll accept. ● The fewer methods there are on an interface, the more obvious is its role in the calling object.
- 10. Compose Objects to Describe System Behavior ● TDD at the unit level guides us to decompose our system into value types and loosely coupled computational objects. ● The tests give us a good understanding of how each object behaves and how it can be combined with others.
- 11. Building Up to Higher-Level Programming ● Organize the code into two layers: an implementation layer which is the graph of objects and, a declarative layer which builds up the objects in the implementation layer, using small “sugar” methods and syntax to describe the purpose of each fragment. ● The declarative layer describes what the code will do, while the implementation layer describes how the code does it.
- 12. Building Up to Higher-Level Programming ● For the implementation layer we stick to the conventional object oriented style guidelines. ● For the declarative layer we might even use “train wreck” chaining of method calls or static methods to help get the point across. ● Our purpose, in the end, is to achieve more with less code. ● We aspire to raise ourselves from programming in terms of control flow and data manipulation, to composing programs from smaller programs, where objects form the smallest unit of behavior.
- 13. And What about Classes? We view classes for objects as an “implementation detail”, a way of implementing types, not the types themselves.