book

Object Design Style Guide

by Matthias Noback

January 2020

Intermediate to advanced

288 pages

6h 45m

English

Manning Publications

Read now

Unlock full access

Who should read this bookHow this book is organized: A roadmapAbout the codeliveBook discussion forum

1.1. Classes and objects1.2. State1.3. Behavior1.4. Dependencies1.5. Inheritance1.6. Polymorphism1.7. Composition1.8. Class organization1.9. Return statements and exceptions1.10. Unit testing1.11. Dynamic arraysSummary
2.1. Two types of objects2.2. Inject dependencies and configuration values as constructor arguments2.3. Inject what you need, not where you can get it from2.4. All constructor arguments should be required2.5. Only use constructor injection2.6. There’s no such thing as an optional dependency2.7. Make all dependencies explicit2.8. Task-relevant data should be passed as method arguments instead o- of constructor arguments2.9. Don’t allow the behavior of a service to change after it has been instantiated2.10. Do nothing inside a constructor, only assign properties2.11. Throw an exception when an argument is invalid2.12. Define services as an immutable object graph with only a few entry pointsSummaryAnswers to the exercises
3.1. Require the minimum amount of data needed 3.1 to behave consistently3.2. Require data that is meaningful3.3. Don’t use custom exception classes for invalid argument exceptions3.4. Test for specific invalid argument exceptions by analyzing the ex- xception’s message3.5. Extract new objects to prevent domain invariants from being verif- fied in multiple places3.6. Extract new objects to represent composite values3.7. Use assertions to validate constructor arguments3.8. Don’t inject dependencies; optionally pass them as method arguments3.9. Use named constructors3.10. Don’t use property fillers3.11. Don’t put anything more into an object than it needs3.12. Don’t test constructors3.13. The exception to the rule: Data transfer objectsSummaryAnswers to the exercises
4.1. Entities: Identifiable objects that track changes and record events4.2. Value objects: Replaceable, anonymous, and immutable values4.3. Data transfer objects: Simple objects with fewer design rules4.4. Prefer immutable objects4.5. A modifier on an immutable object should return a modified copy4.6. On a mutable object, modifier methods should be command methods4.7. On an immutable object, modifier methods should have declarative names4.8. Compare whole objects4.9. When comparing immutable objects, assert equality, not sameness4.10. Calling a modifier method should always result in a valid object4.11. A modifier method should verify that the requested state change is valid4.12. Use internally recorded events to verify changes on mutable objects4.13. Don’t implement fluent interfaces on mutable objectsSummaryAnswers to the exercises
5.1. A template for implementing methods5.2. Some rules for exceptionsSummaryAnswers to the exercises
6.1. Use query methods for information retrieval6.2. Query methods should have single-type return values6.3. Avoid query methods that expose internal state6.4. Define specific methods and return types for the queries you want to make6.5. Define an abstraction for queries that cross system boundaries6.6. Use stubs for test doubles with query methods6.7. Query methods should use other query methods, not command methodsSummaryAnswers to the exercises
7.1. Use command methods with a name in the imperative form7.2. Limit the scope of a command method, and use events to perform secondary tasks7.3. Make services immutable from the outside as well as on the inside7.4. When something goes wrong, throw an exception7.5. Use queries to collect information and commands to take the next steps7.6. Define abstractions for commands that cross system boundaries7.7. Only verify calls to command methods with a mockSummaryAnswers to the exercises
8.1. Separate write models from read models8.2. Create read models that are specific for their use cases8.3. Create read models directly from their data source8.4. Build read models from domain eventsSummaryAnswers to the exercises
9.1. Introduce constructor arguments to make behavior configurable9.2. Introduce constructor arguments to make behavior replaceable9.3. Compose abstractions to achieve more complicated behavior9.4. Decorate existing behavior9.5. Use notification objects or event listeners for additional behavior9.6. Don’t use inheritance to change an object’s behavior9.7. Mark classes as final by default9.8. Mark methods and properties private by defaultSummaryAnswers to the exercises
10.1. Controllers10.2. Application services10.3. Write model repositories10.4. Entities10.5. Value objects10.6. Event listeners10.7. Read models and read model repositories10.8. Abstractions, concretions, layers, and dependenciesSummary
11.1. Architectural patterns11.2. Testing11.3. Domain-driven design11.4. Conclusion

Content preview from Object Design Style Guide

Chapter 9. Changing the behavior of services

This chapter covers

Changing behavior without changing code
Making behaviors configurable and replaceable
Introducing abstractions to allow for composition and decoration
Avoiding inheritance for overriding object behaviors
Making classes final and methods private to prevent object abuse

You can design your services to be created and used in certain ways. But the nature of a software project is that it will change over time. You’ll often modify a class in such a way that, when it’s used, it will behave the way you want it to. However, modifying a class comes with a cost: the danger of breaking it in some way. A common alternative to changing a class is to override some of its methods, but this can ...