Style Guide for Object Design
Style Guide for Object Design
About the Book
Note: this book is no longer available via Leanpub. It has been republished by Manning Publications: https://www.manning.com/books/object-design-style-guide Manning also offers a print edition, which will be shipped at the end of the early access program.
This book is right in the middle between learning how to write code and learning how to apply design principles and patterns. Using lots of code samples it teaches you the basics of object design. It provides you with simple rules to follow when defining your classes, methods, properties and interfaces.
After the fundamentals, this book provides you with a discussion of object design related topics that are worth investigating.
About the Author
Table of Contents
-
- Foreword
-
Introduction
- Who is this book for?
- Design rules for this book
- Conventions
- Overview of the contents
- Acknowledgments
-
The lifecycle of an object
-
1. Creating services
-
1.1 Inject dependencies and configuration values as constructor arguments
- Keeping together configuration values that belong together
- 1.2 Inject what you need, not where you can get it from
- 1.3 All constructor arguments should be required
- 1.4 Only use constructor injection
- 1.5 There’s no such thing as an optional dependency
-
1.6 Make all dependencies explicit
- Turn static dependencies into object dependencies
- Turn complicated functions into object dependencies
- Make system calls explicit
- 1.7 Data relevant for the task should be passed as method arguments instead of constructor arguments
- 1.8 Don’t allow the behavior of a service to change after it has been instantiated
- 1.9 Do nothing inside a constructor, only assign properties
- 1.10 Throw an exception when an argument is invalid
- 1.11 Define services as an immutable object graph with only a few entry points
- 1.12 Summary
-
1.1 Inject dependencies and configuration values as constructor arguments
-
2. Creating other objects
- 2.1 Require the minimum amount of data needed to behave consistently
- 2.2 Require data that is meaningful
- 2.3 Don’t use custom exception classes for invalid argument exceptions
- 2.4 Extract new objects to prevent domain invariants from being verified in multiple places
- 2.5 Extract new objects to represent composite values
- 2.6 Use assertions to validate constructor arguments
- 2.7 Don’t inject dependencies, optionally pass them as method arguments
-
2.8 Use named constructors
- Create from primitive type values
-
Don’t immediately add
toString(),toInt(), etc. - Introduce a domain-specific concept
- Optionally use the private constructor to enforce constraints
- 2.9 Don’t use property fillers
- 2.10 Don’t put anything more into an object than it needs
- 2.11 Don’t test constructors
-
2.12 The exception to the rule: Data transfer objects {#the-exception-to-the-rules:-data-transfer-objects}
- Use public properties
- Don’t throw exceptions, collect validation errors
- Use property fillers when needed
- 2.13 Summary
-
3. Manipulating objects
-
- Entities: identifiable objects which track changes and record events
- Value objects: replaceable, anonymous, and immutable values
- Data transfer objects: simple objects with fewer design rules
-
3.1 Prefer immutable objects
- Replace values instead of modifying them
- 3.2 A modifier on an immutable object should return a modified copy
- 3.3 On a mutable object, modifier methods should be command methods
- 3.4 On an immutable object, modifier methods should have declarative names
- 3.5 Compare whole objects
- 3.6 When comparing immutable objects, assert equality, not sameness
- 3.7 Calling a modifier method should always result in a valid object
- 3.8 A modifier method should verify that the requested state change is valid
- 3.9 Use internally recorded events to verify changes on mutable objects
- 3.10 Don’t implement fluent interfaces on mutable objects
- 3.11 Summary
-
-
1. Creating services
-
Using objects
-
4. A template for implementing methods
- 4.1 Pre-condition checks
- 4.2 Failure scenarios
- 4.3 Happy path
- 4.4 Post-condition checks
- 4.5 Return value
-
4.6 Some rules for exceptions
- Use custom exception classes only if needed
- Naming invalid argument or logic exception classes
- Naming runtime exception classes
- Use named constructors to indicate reasons for failure
- Add detailed messages
- 4.7 Summary
-
5. Retrieving information
- 5.1 Use query methods for information retrieval
- 5.2 Query methods should have single-type return values
- 5.3 Avoid query methods that expose internal state
- 5.4 Define specific methods and return types for the queries you want to make
- 5.5 Define an abstraction for queries that cross system boundaries
- 5.6 Use stubs for test doubles with query methods
- 5.7 Query methods should use other query methods, no command methods
- 5.8 Summary
-
6. Performing tasks
- 6.1 Use command methods with a name in the imperative form
- 6.2 Limit the scope of a command method, use events to perform secondary tasks
- 6.3 Make services immutable from the outside as well as on the inside
- 6.4 When something goes wrong, throw an exception
- 6.5 Use queries to collect information, commands to take the next steps
- 6.6 Define an abstraction for commands that cross system boundaries
- 6.7 Only verify calls to command methods with a mock
- 6.8 Summary
-
7. Dividing responsibilities
- 7.1 Separate write models from read models
-
7.2 Create read models that are specific for their use cases
- Create read models directly from their data source
- Build read models from domain events
- 7.3 Summary
-
4. A template for implementing methods
-
Changing the behavior of objects
-
8. Changing the behavior of services
- 8.1 Introduce constructor arguments to make behavior configurable
- 8.2 Introduce constructor arguments to make behavior replaceable
- 8.3 Compose abstractions to achieve more complicated behavior
- 8.4 Decorate existing behavior
- 8.5 Use notification objects or event listeners for additional behavior
- 8.6 Don’t use inheritance to change an object’s behavior
- 8.7 Mark classes as final by default
- 8.8 Mark methods and properties private by default
- 8.9 Summary
-
8. Changing the behavior of services
-
A field guide to objects
- 9. Controllers
- 10. Application services
- 11. Write model repositories
- 12. Entities
- 13. Value objects
- 14. Event listeners
- 15. Read models and read model repositories
- 16. Abstractions, concretions, layers, and dependencies
- 17. Summary
-
Epilogue
- 18. Architectural patterns
-
19. Testing
- 19.1 Class testing versus object testing
- 19.2 Top down feature development
- 20. Domain-Driven Design
- 21. Conclusion
-
Changelog
- 6/3/2019
- Notes
The Leanpub 60-day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
