Object Design Style Guide

by Matthias Noback

Overview

”Demystifies object-oriented programming, and lays out how to use it to design truly secure and performant applications.” —Charles Soetan, Plum.io

Key Features
Dozens of techniques for writing object-oriented code that’s easy to read, reuse, and maintain
Write code that other programmers will instantly understand
Design rules for constructing objects, changing and exposing state, and more
Examples written in an instantly familiar pseudocode that’s easy to apply to Java, Python, C#, and any object-oriented language

Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.

About The Book
Well-written object-oriented code is easy to read, modify, and debug. Elevate your coding style by mastering the universal best practices for object design presented in this book. These clearly presented rules, which apply to any OO language, maximize the clarity and durability of your codebase and increase productivity for you and your team.

In Object Design Style Guide, veteran developer Matthias Noback lays out design rules for constructing objects, defining methods, and much more. All examples use instantly familiar pseudocode, so you can follow along in the language you prefer. You’ll go case by case through important scenarios and challenges for object design and then walk through a simple web application that demonstrates how different types of objects can work together effectively.

What You Will Learn
Universal design rules for a wide range of objects
Best practices for testing objects
A catalog of common object types
Changing and exposing state
Test your object design skills with exercises

This Book Is Written For
For readers familiar with an object-oriented language and basic application architecture.

About the Author
Matthias Noback is a professional web developer with nearly two decades of experience. He runs his own web development, training, and consultancy company called “Noback’s Office.”

Table of Contents:

1 ¦ Programming with objects: A primer
2 ¦ Creating services
3 ¦ Creating other objects
4 ¦ Manipulating objects
5 ¦ Using objects
6 ¦ Retrieving information
7 ¦ Performing tasks
8 ¦ Dividing responsibilities
9 ¦ Changing the behavior of services
10 ¦ A field guide to objects
11 ¦ Epilogue
 

Product Details

ISBN-13:	9781638350194
Publisher:	Manning
Publication date:	12/23/2019
Sold by:	SIMON & SCHUSTER
Format:	eBook
Pages:	288
File size:	989 KB

About the Author

Matthias Noback is a professional web developer with nearly two decades of experience. He runs his own web development, training, and consultancy company called “Noback’s Office.”
Matthias Noback is a professional web developer with nearly two decades of experience. He runs his own web development, training, and consultancy company called "Noback's Office.”

Table of Contents

Foreword xi

Preface xiii

Acknowledgments xv

About this book xvi

About the author xix

About the cover illustration xx

1 Programming with objects: A primer 1

1.1 Classes and objects 2

1.2 State 4

1.3 Behavior 7

1.4 Dependencies 9

1.5 Inheritance 10

1.6 Polymorphism 13

1.7 Composition 14

1.8 Class organization 15

1.9 Return statements and exceptions 16

1.10 Unit testing 18

1.11 Dynamic arrays 23

2 Creating services 25

2.1 Two types of objects 25

2.2 Inject dependencies and configuration values as constructor arguments 27

Keeping together configuration values that belong together 28

2.3 Inject what you need, not where you can get it from 30

2.4 All constructor arguments should be required 34

2.5 Only use constructor injection 36

2.6 There's no such thing as an optional dependency 37

2.7 Make all dependencies explicit 38

Turn static dependencies into object dependencies 38

Turn complicated functions into object dependencies 39

Make system calls explicit 41

2.8 Task-relevant data should be passed as method arguments instead of constructor arguments 45

2.9 Don't, allow the behavior of a service to change after it has been instantiated 48

2.10 Do nothing inside a constructor, only assign properties 50

2.11 Throw an exception when an argument is invalid 55

2.12 Define services as an immutable object graph with only a few entry points 59

3 Creating other objects 66

3.1 Require the minimum amount of data needed to behave consistently 67

3.2 Require data that is meaningful 68

3.3 Don't use custom exception classes for invalid argument exceptions 74

3.4 Test for specific invalid argument exceptions by analyzing the exception's message 75

3.5 Extract new objects to prevent domain invariants from being verified in multiple places 77

3.6 Extract new objects to represent composite values 79

3.7 Use assertions to validate constructor arguments 81

3.8 Don't inject dependencies; optionally pass them as method arguments 84

3.9 Use named constructors 88

Create from primitive-type values 88

Don't immediately add toString(), toInt(), etc. 89

Introduce a domain-specific concept 89

Optionally use the private constructor to enforce constraints 89

3.10 Don't use property fillers 91

3.11 Don't put anything more into an object than it needs 92

3.12 Don't test constructors 93

3.13 The exception to the rule: Data transfer objects 96

Use public properties 96

Don't throw exceptions, collect validation errors 97

Use property fillers when needed 98

4 Manipulating objects 102

4.1 Entities: Identifiable objects that track changes and record events 103

4.2 Value objects: Replaceable, anonymous, and immutable values 105

4.3 Data transfer objects: Simple objects with fewer design rules 108

4.4 Prefer immutable objects 110

Replace values instead of modifying them 111

4.5 A modifier on an immutable object should return a modified copy 114

4.6 On a mutable object, modifier methods should be command methods 117

4.7 On an immutable object, modifier methods should have declarative names 118

4.8 Compare whole objects 120

4.9 When comparing immutable objects, assert equality, not sameness 121

4.10 Calling a modifier method should always result in a valid object 123

4.11 A modifier method should verify that the requested state change is valid 125

4.12 Use internally recorded events to verify changes on mutable objects 127

4.13 Don't implement fluent interfaces on mutable objects 132

5 Using objects 137

5.1 A template for implementing methods 137

Precondition checks 138

Failure scenarios 139

Happy path 140

Postcondition checks 140

Return value 141

5.2 Some rules for exceptions 141

Use custom exception classes only if needed 141

Naming invalid argument or logic exception classes 143

Naming runtime exception classes 143

Use named constructors to indicate reasons for failure 143

Add detailed messages 144

6 Retrieving information 146

6.1 Use query methods for information retrieval 146

6.2 Query methods should have single-type return values 149

6.3 Avoid query methods that expose internal state 152

6.4 Define specific methods and return types for the queries you want to make 157

6.5 Define an abstraction for queries that cross system boundaries 159

6.6 Use stubs for test doubles with query methods 163

6.7 Query methods should use other query methods, not command methods 166

7 Performing tasks 171

7.1 Use command methods with a name in the imperative form 172

7.2 Limit the scope of a command method, and use events to perform secondary tasks 172

7.3 Make services immutable from the outside as well as on the inside 176

7.4 When something goes wrong, throw an exception 179

7.5 Use queries to collect information and commands to take the next steps 180

7.6 Define abstractions for commands that cross system boundaries 182

7.7 Only verify calls to command methods with a mock 184

8 Dividing responsibilities 188

8.1 Separate write models from read models 189

8.2 Create read models that are specific for their use cases 196

8.3 Create read models directly from their data source 197

8.4 Build read models from domain events 198

9 Changing the behavior of services 205

9.1 Introduce constructor arguments to make behavior configurable 206

9.2 Introduce constructor arguments to make behavior replaceable 207

9.3 Compose abstractions to achieve more complicated behavior 210

9.4 Decorate existing behavior 212

9.5 Use notification objects or event listeners for additional behavior 215

9.6 Don't use inheritance to change an object's behavior 220

When is it okay to use inheritance? 223

9.7 Mark classes as final by default 224

9.8 Mark methods and properties private by default 225

10 A field guide to objects 231

10.1 Controllers 233

10.2 Application services 235

10.3 Write model repositories 237

10.4 Entities 239

10.5 Value objects 240

10.6 Event listeners 243

10.7 Read models and read model repositories 244

10.8 Abstractions, concretions, layers, and dependencies 247

11 Epilogue 250

11.1 Architectural patterns 251

11.2 Testing 251

Class testing versus object testing 251

Top-down feature development 252

11.3 Domain-driven design 253

11.4 Conclusion 253

Appendix Coding standard for the code samples 254

Index 259