book

Object Design Style Guide

Name: Object Design Style Guide
Author: Matthias Noback
ISBN: 9781617296857

by Matthias Noback

January 2020

Intermediate to advanced

288 pages

6h 45m

English

Manning Publications

Read now

Unlock full access

Copyright
Dedication
Brief Table of Contents
Table of Contents
Foreword
Preface
Acknowledgments
About this Book
Who should read this bookHow this book is organized: A roadmapAbout the codeliveBook discussion forum
About the Author
About the Cover Illustration

Chapter 1. Programming with objects: A primer
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
Chapter 2. Creating services
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
Chapter 3. Creating other objects
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
Chapter 4. Manipulating objects
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
Chapter 5. Using objects
5.1. A template for implementing methods5.2. Some rules for exceptionsSummaryAnswers to the exercises
Chapter 6. Retrieving information
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
Chapter 7. Performing tasks
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
Chapter 8. Dividing responsibilities
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
Chapter 9. Changing the behavior of services
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
Chapter 10. A field guide to objects
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
Chapter 11. Epilogue
11.1. Architectural patterns11.2. Testing11.3. Domain-driven design11.4. Conclusion
Appendix: Coding standard for the code samples
Style guide cheat sheet
Index
List of Figures
List of Tables
List of Listings

Content preview from Object Design Style Guide

Chapter 4. Manipulating objects

This chapter covers

Making a distinction between mutable and immutable objects
Using modifier methods to change state or create modified copies
Comparing objects
Protecting against invalid state changes
Using events to track changes in mutable objects

As you’ve learned in the previous chapters, services should be designed to be immutable. This means that once a service object has been created, it can never be modified. The biggest advantage is that its behavior will be predictable, and it can be reused to perform the same task using different input.

So we know that services should be immutable objects, but what about the other types of objects: entities, value objects, and data transfer objects?

4.1. Entities: ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781617296857Publisher Support Publisher Website Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Object Design Style Guide

by Matthias Noback