Welcome to Manning India!
We are pleased to be able to offer regional eBook pricing for Indian residents.
All eBook prices are discounted 40% or more!
Object Design Style Guide
FREE
You can see any available part of this book for free.Click the table of contents to start reading.
Objects are the central concept of languages like Java, Python, C#. Applying best practices for object design means that your code will be easy to read, write, and maintain. Object Design Style Guide captures dozens of techniques for creating pro-quality OO code that can stand the test of time. Examples are in an instantly-familiar pseudocode, teaching techniques you can apply to any OO language, from C++ to PHP.An excellent array of tips and facts to building software objects the way every developer should.
Table of Contents takes you straight to the bookdetailed table of contents
1 Introduction
1.1 Dynamic arrays
1.2 Classes and objects
1.3 State
1.4 Behavior
1.5 Dependencies
1.6 Inheritance
1.7 Class organization
1.8 Return statements and exceptions
1.9 Unit testing
1.10 Summary
2 Creating services
2.1 Two types of objects
2.2 Inject dependencies and configuration values as constructor arguments
2.2.1 Keeping together configuration values that belong together
2.3 Inject what you need, not where you can get it from
2.4 All constructor arguments should be required
2.5 Only use constructor injection
2.6 There’s no such thing as an optional dependency
2.7 Make all dependencies explicit
2.7.1 Turn static dependencies into object dependencies
2.7.2 Turn complicated functions into object dependencies
2.7.3 Make system calls explicit
2.8 Data relevant for the task should be passed as method arguments instead of constructor arguments
2.9 Don’t allow the behavior of a service to change after it has been instantiated
2.10 Do nothing inside a constructor, only assign properties
2.11 Throw an exception when an argument is invalid
2.12 Define services as an immutable object graph with only a few entry points
2.13 Summary
2.14 Answers to the exercises
3 Creating other objects
3.1 Require the minimum amount of data needed to behave consistently
3.2 Require data that is meaningful
3.3 Don’t use custom exception classes for invalid argument exceptions
3.4 Test for specific invalid argument exceptions by analyzing the exception’s message
3.5 Extract new objects to prevent domain invariants from being verified in multiple places
3.6 Extract new objects to represent composite values
3.7 Use assertions to validate constructor arguments
3.8 Don’t inject dependencies; optionally pass them as method arguments
3.9 Use named constructors
3.9.1 Create from primitive type values
3.9.2 Don’t immediately add toString(), toInt(), etc.
3.9.3 Introduce a domain-specific concept
3.9.4 Optionally use the private constructor to enforce constraints
3.10 Don’t use property fillers
3.11 Don’t put anything more into an object than it needs
3.12 Don’t test constructors
3.13 The exception to the rule: Data transfer objects
3.13.1 Use public properties
3.13.2 Don’t throw exceptions, collect validation errors
3.13.3 Use property fillers when needed
3.14 Summary
3.15 Answers to the exercises
4 Manipulating objects
4.1 Entities: Identifiable objects that track changes and record events
4.2 Value objects: Replaceable, anonymous, and immutable values
4.3 Data transfer objects: Simple objects with fewer design rules
4.4 Prefer immutable objects
4.4.1 Replace values instead of modifying them
4.5 A modifier on an immutable object should return a modified copy
4.6 On a mutable object, modifier methods should be command methods
4.7 On an immutable object, modifier methods should have declarative names
4.8 Compare whole objects
4.9 When comparing immutable objects, assert equality, not sameness
4.10 Calling a modifier method should always result in a valid object
4.11 A modifier method should verify that the requested state change is valid
4.12 Use internally recorded events to verify changes on mutable objects
4.13 Don’t implement fluent interfaces on mutable objects
4.14 Summary
4.15 Answers to the exercises
5 Using objects
5.1 A template for implementing methods
5.1.1 Precondition checks
5.1.2 Failure scenarios
5.1.3 Happy path
5.1.4 Postcondition checks
5.1.5 Return value
5.2 Some rules for exceptions
5.2.1 Use custom exception classes only if needed
5.2.2 Naming invalid argument or logic exception classes
5.2.3 Naming runtime exception classes
5.2.4 Use named constructors to indicate reasons for failure
5.2.5 Add detailed messages
5.3 Summary
5.4 Answers to the exercises
6 Retrieving information
6.1 Use query methods for information retrieval
6.2 Query methods should have single-type return values
6.3 Avoid query methods that expose internal state
6.4 Define specific methods and return types for the queries you want to make
6.5 Define an abstraction for queries that cross system boundaries
6.6 Use stubs for test doubles with query methods
6.7 Query methods should use other query methods, not command methods
6.8 Summary
6.9 Answers to the exercises
7 Performing tasks
7.1 Use command methods with a name in the imperative form
7.2 Limit the scope of a command method, and use events to perform secondary tasks
7.3 Make services immutable from the outside as well as on the inside
7.4 When something goes wrong, throw an exception
7.5 Use queries to collect information and commands to take the next steps
7.6 Define abstractions for commands that cross system boundaries
7.7 Only verify calls to command methods with a mock
7.8 Summary
7.9 Answers to the exercises
8 Dividing responsibilities
8.1 Separate write models from read models
8.2 Create read models that are specific for their use cases
8.3 Create read models directly from their data source
8.4 Build read models from domain events
8.5 Summary
8.6 Answers to the exercises
9 Changing the behavior of services
9.1 Introduce constructor arguments to make behavior configurable
9.2 Introduce constructor arguments to make behavior replaceable
9.3 Compose abstractions to achieve more complicated behavior
9.4 Decorate existing behavior
9.5 Use notification objects or event listeners for additional behavior
9.6 Don’t use inheritance to change an object’s behavior
9.6.1 When is it okay to use inheritance?
9.7 Mark classes as final by default
9.8 Mark methods and properties private by default
9.9 Summary
9.10 Answers to the exercises
10 A field guide to objects
10.1 Controllers
10.2 Application services
10.3 Write model repositories
10.4 Entities
10.5 Value objects
10.6 Event listeners
10.7 Read models and read model repositories
10.8 Abstractions, concretions, layers, and dependencies
10.9 Summary
Epilogue
11.1 Architectural patterns
11.2 Testing
11.2.1 Class testing versus object testing
11.2.2 Top-down feature development
11.3 Domain-driven design
11.4 Conclusion
Appendixes
Appendix A: Coding standard for the code samples
Style guide cheat sheet
About the Technology
Because object-oriented code can be written in many different languages, each of which has it unique syntax, libraries, frameworks, and communities, many software projects end up with a mixed style. Object Design Style Guide lays out a set of universal guidelines for designing objects with a best practice approach to writing classes, methods, and properties. Applying the language agnostic rules in this practical book will make your code simpler, easier to read, debug, and change.About the book
In Object Design Style Guide, veteran developer Matthias Noback sets out best practices for designing objects that apply regardless of the object-oriented programming language you choose. Covering the most important scenarios and challenges for object design, Noback shares experience-based design rules for modelling code. Step-by-step, this book guides you through best practices for constructing objects, defining methods, changing and exposing state, and much more. Finally, you’ll explore a simple web application to see theory in action and how different types of objects all work together. As you use these valuable techniques, your OO code will become more elegant, efficient, and professional.What's inside
- The design rules for different types of objects
- Best practices for naming objects
- Testing an object’s behavior instead of its implementation
- Exercises for each chapter to test your design skills
Manning Early Access Program (MEAP)
Read chapters as they are written, get the finished eBook as soon as it’s ready, and receive the pBook long before it's in bookstores.
- customers also bought these items
- Terraform in Action
- Unit Testing
- API Security in Action
- Seriously Good Software
- The Design of Web APIs
- Human-in-the-Loop Machine Learning
- customers also bought these items
- Seriously Good Software
- Algorithms and Data Structures in Action
- Grokking Simplicity
- Programming with Types
- API Security in Action
- Unit Testing
Prices displayed in rupees will be charged in USD when you check out.
placing your order...
Don't refresh or navigate away from the page.FREE domestic shipping on three or more pBooks