book

Simple Object-Oriented Design

Name: Simple Object-Oriented Design
Author: Mauricio Aniche
ISBN: 9781633437999

by Mauricio Aniche

May 2024

Intermediate to advanced

192 pages

4h 26m

English

Manning Publications

Read now

Unlock full access

Simple Object-Oriented Design
Copyright
dedication
contents
front matter
prefaceacknowledgmentsabout this bookWho should read this bookHow this book is organized: A road mapAbout the codeliveBook discussion forumOther online resourcesabout the authorabout the cover illustration
1 It’s all about managing complexity
1.1 Object-oriented design and the test of time1.2 Designing simple object-oriented systems1.2.1 Simple code1.2.2 Consistent objects1.2.3 Proper dependency management1.2.4 Good abstractions1.2.5 Properly handled external dependencies and infrastructure1.2.6 Well modularized1.3 Simple design as a day-to-day activity1.3.1 Reducing complexity is similar to personal hygiene1.3.2 Complexity may be necessary but should not be permanent1.3.3 Consistently addressing complexity is cost effective1.3.4 High-quality code promotes good practices1.3.5 Controlling complexity isn’t as difficult as it seems1.3.6 Keeping the design simple is a developer’s responsibility1.3.7 Good-enough designs1.4 A short dive into the architecture of an information system1.5 The example project: PeopleGrow!1.6 ExercisesSummary
2 Making code small
2.1 Make units of code small2.1.1 Break complex methods into private methods2.1.2 Move a complex unit of code to another class2.1.3 When not to divide code into small units2.1.4 Get a helicopter view of the refactoring before you do it2.1.5 Example: Importing employees2.2 Make code readable and documented2.2.1 Keep looking for good names2.2.2 Document decisions2.2.3 Add code comments2.2.4 Example: Deciding when to send an update email2.3 Move new complexity away from existing classes2.3.1 Give the complex business logic a class of its own2.3.2 Break down large business flows2.3.3 Example: Waiting list for offerings2.4 ExercisesSummary
3 Keeping objects consistent
3.1 Ensure consistency at all times3.1.1 Make the class responsible for its consistency3.1.2 Encapsulate entire actions and complex consistency checks3.1.3 Example: The Employee entity3.2 Design effective data validation mechanisms3.2.1 Make preconditions explicit3.2.2 Create validation components3.2.3 Use nulls carefully or avoid them if you can3.2.4 Example: Adding an employee to a training offering3.3 Encapsulate state checks3.3.1 Tell, don’t ask3.3.2 Example: Available spots in an offering3.4 Provide only getters and setters that matter3.4.1 Getters that don’t change state and don’t reveal too much to clients3.4.2 Setters only to attributes that describe the object3.4.3 Example: Getters and setters in the Offering class3.5 Model aggregates to ensure invariants in clusters of objects3.5.1 Don’t break the rules of an aggregate root3.5.2 Example: The Offering aggregate3.6 ExercisesSummary
4 Managing dependencies
4.1 Separate high-level and low-level code4.1.1 Design stable code4.1.2 Interface discovery4.1.3 When not to separate the higher level from the lower level4.1.4 Example: The messaging job4.2 Avoid coupling to details or things you don’t need4.2.1 Only require or return classes that you own4.2.2 Example: Replacing the HTTP bot with the chat SDK4.2.3 Don’t give clients more than they need4.2.4 Example: The offering list4.3 Break down classes that depend on too many other classes4.3.1 Example: Breaking down the MessageSender service4.4 Inject dependencies, aka dependency injection4.4.1 Avoid static methods for operations that change the state4.4.2 Always inject collaborators: Everything else is optional4.4.3 Strategies to instantiate the class together with its dependencies4.4.4 Example: Dependency injection in MessageSender and collaborators4.5 ExercisesSummary
5 Designing good abstractions
5.1 Design abstractions and extension points5.1.1 Identifying the need for an abstraction5.1.2 Designing an extension point5.1.3 Attributes of good abstractions5.1.4 Learn from your abstractions5.1.5 Learn about abstractions5.1.6 Abstractions and coupling5.1.7 Example: Giving badges to employees5.2 Generalize important business rules5.2.1 Separate the concrete data from the generalized business rule5.2.2 Example: Generalizing the badge rules5.3 Prefer simple abstractions5.3.1 Rules of thumb5.3.2 Simple is always better5.3.3 Enough is enough5.3.4 Don’t be afraid of modeling abstractions from day one5.3.5 Example: Revisiting the badge example5.4 ExercisesSummary

6 Handling external dependencies and infrastructure
6.1 Separate infrastructure from the domain code6.1.1 Do you need an interface?6.1.2 Hide details from the code, not from the developers6.1.3 Changing the infrastructure someday: Myth or reality?6.1.4 Example: Database access and the message bot6.2 Use the infrastructure fully6.2.1 Do your best not to break your design6.2.2 Example: Cancelling an enrollment6.3 Only depend on things you own6.3.1 Don’t fight your frameworks6.3.2 Be aware of indirect leakage6.3.3 Example: Message bot6.4 Encapsulate low-level infrastructure errors into high-level domain errors6.4.1 Example: Handling exceptions in SDKBot6.5 ExercisesSummary
7 Achieving modularization
7.1 Build deep modules7.1.1 Find ways to reduce the effects of changes7.1.2 Keep refining your domain boundaries7.1.3 Keep related things close7.1.4 Fight accidental coupling, or document it when you can’t7.2 Design clear interfaces7.2.1 Keep the module’s interface simple7.2.2 Backward-compatible modules7.2.3 Provide clean extension points7.2.4 Code as if your module will be used by someone with different needs7.2.5 Modules should have clear ownership and engagement rules7.3 No intimacy between modules7.3.1 Make modules and clients responsible for the lack of intimacy7.3.2 Don’t depend on internal classes7.3.3 Monitor the web of dependencies7.3.4 Monoliths or microservices?7.3.5 Consider events as a way to decouple modules7.3.6 Example: The notification system7.4 ExercisesSummary
8 Being pragmatic
8.1 Be pragmatic and go only as far as you must8.2 Refactor aggressively but in small steps8.3 Accept that your code won’t ever be perfect8.4 Consider redesigns8.5 You owe this to junior developers8.6 References8.7 ExercisesSummary
index

Content preview from Simple Object-Oriented Design

index

A Philosophy of Software Design (Ousterhout) 159

abstractions 91 – 111

and coupling 97

attributes of good 95 – 96

designing 94 – 95

example of 97 – 102

extension points 93 – 102

good 8

identifying need for abstractions 93 – 94

learning from abstractions 96

simplicity of 108 – 111

addEmployee() method 46, 49, 61, 66

AddEmployeeToOfferingService class 54, 66

AddEmployeeToOfferingValidator class 55

aggregates

ensuring invariants in clusters of objects 63 – 68

Offering aggregate 65 – 68

rules of 64 – 65

allEmployees() method 116

Amazon AWS 130

Amazon SQS 130

API (application programming interface) 141

api package 149

architecture, of information systems 13 – 15

availableSpots attribute 126 – 127

availableSpots(Offering) method 127

BadgeGiver ...

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: 9781633437999Publisher Support Publisher Website

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Simple Object-Oriented Design

by Mauricio Aniche

index

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.