\nBuy the book!

What you read was just a sample of various chapters. If you like the style, why not buy the full book? Go on - treat yourself!

",{"_552":553,"_43":44,"_47":48,"_45":46,"_65":66,"_554":555,"_695":550},"previewContent","

\n Preface\n
\n Optimise for Clarity\n
\n What is an object, anyway?\n
- \n What’s all this got to do with Java?\n
- \n A simple example: Greeting users\n
- \n The big idea: calling code is simple\n
- \n Object Oriented Design is Behaviour Driven Design\n
\n
\n Clean Code\n
- \n Good Names\n
- \n Design methods around behaviours, not data\n
- \n Hidden data - No getters, no setters\n
\n
\n Aggregates: More than one\n
- \n Greeting more than one user\n
- \n Using forEach - not a loop\n
- \n Aggregate methods work on all the things\n
\n
\n Collaboration\n
- \n Basic Mechanics\n
- \n Example: Simple Point of Sale\n
\n
\n Test Driven Development\n
- \n Outside-in design with TDD\n
- \n First test: total starts at zero\n
- \n Arrange, Act, Assert - a rhythm inside each test\n
- \n Red, Green, Refactor - a rhythm in between tests\n
- \n Second test: Adding an item gives us the right total\n
- \n Designing the second feature\n
- \n TDD Steps - Too much? Too little?\n
- \n YAGNI - You Ain’t Gonna Need It\n
- \n YAYA - Yes, You Are\n
- \n Optimise for Clarity with well-named tests\n
- \n TDD and OOP - A natural fit\n
- \n FIRST Tests are usable tests\n
- \n Real-world TDD\n
\n
\n Polymorphism - The Jewel in the OOP Crown\n
- \n Classic example: Shape.draw()\n
- \n The Shape Interface\n
- \n Tell Don’t Ask - the key to OOP\n
\n
\n The SOLID Principles\n
- \n The five SOLID principles\n
- \n SRP Single Responsibility - do one thing well\n
- \n DIP Dependency Inversion: Bring out the Big Picture\n
- \n LSP Liskov Substitution Principle - Making things swappable\n
- \n OCP Open/Closed Principle - adding without change\n
- \n ISP Interface Segregation Principle - honest interfaces\n
\n
\n TDD and Test Doubles\n
- \n Test Doubles - Stubs and Mocks\n
- \n DIP for Unit Tests - Stubs and Mocks\n
- \n Mocking libraries\n
- \n Self-Shunt mocks and stubs\n
\n
\n Refactoring\n
- \n What is refactoring?\n
- \n Rename Method, Rename Variable\n
- \n Extract Method\n
- \n Change Method Signature\n
- \n Extract Parameter Object\n
- \n Can we refactor anything into anything else?\n
\n
\n Hexagonal Architecture\n
- \n The problems of external systems\n
- \n The Test Pyramid\n
- \n Removing external systems\n
- \n The Hexagonal Model\n
- \n Inversion / Injection: Two sides of the same coin\n
\n
\n Handling Errors\n
- \n Three kinds of errors\n
- \n The null reference\n
- \n Null object pattern\n
- \n Zombie object\n
- \n Exceptions - a quick primer\n
- \n Design By Contract, Bertrand Meyer style\n
- \n Fatal errors: Stop the world!\n
- \n Combined approach: Fixable and non-fixable errors\n
- \n Which approach is best?\n
- \n NullPointerException\n
- \n Application Specific Exceptions\n
- \n Error object\n
- \n Optionals - Java 8 streams approach\n
- \n Review: Which approach to use?\n
\n
\n Design Patterns\n
- \n Mechanism and Domain\n
- \n Patterns: Not libraries, not frameworks\n
- \n Strategy\n
- \n Observer\n
- \n Adapter\n
- \n Command\n
- \n Composite\n
- \n Facade\n
- \n Builder\n
- \n Repository\n
- \n Query\n
- \n CollectingParameter\n
- \n Item-Item Description\n
- \n Moment-Interval\n
- \n Clock\n
- \n Rules (or Policy)\n
- \n Aggregate\n
- \n Cache\n
- \n Decorator\n
- \n External System (Proxy)\n
- \n Configuration\n
- \n Order-OrderLineItem\n
- \n Request-Service-Response\n
- \n Anti-Patterns\n
\n
\n OOP Mistakes - OOP oops!\n
- \n Broken Encapsulation - Getters Galore!\n
- \n Broken Inheritance\n
- \n Bird extends Animal\n
- \n Square extends Rectangle\n
- \n Inheriting implementation\n
- \n Broken Shared State\n
- \n Ordinary Bad Code\n
\n
\n Data Structures and Pure Functions\n
- \n System Boundaries\n
- \n Fixed Data, Changing Functions\n
- \n Algorithms and Data Structures\n
\n
\n Putting It All Together\n
- \n No step-by-step plans\n
- \n Getting Started\n
- \n Perfection and Pragmatism\n
- \n Getting Past Stuck\n
\n
\n Further Reading\n
- \n Agile Software Development, Robert C Martin\n
- \n Growing Object Oriented Software Guided By Tests, Freeman and Pryce\n
- \n Refactoring, Martin Fowler\n
- \n Design Patterns Helm, Johnson, Richards, Vlissides\n
- \n Domain Driven Design, Eric Evans\n
- \n Applying UML with Patterns, Craig Larman\n
- \n Home page for this book\n
- \n My Blog\n
- \n My Quora Space\n
- \n LinkedIn\n
- \n LeanPub page\n
\n
\n Cheat Sheet\n
- \n Behaviours First\n
- \n Design Principles\n
- \n Clean Code\n
- \n General Code Review Points\n
\n
\n About the Author\n
- \n Thanks\n
\n
\n Buy the book!\n
\n Notes\n

\nPreface

Why another book on OOP in Java?

\n\n

I’ve been a writer on Quora for a few years now. I really enjoy it. I get to interact with people from all over the world about a subject I love - the craft of designing good software. I started learning this craft in 1981. I haven’t finished yet.

\n\n

This book came about after seeing a common thread amongst new Java developers on Quora. Many of them thought OOP in Java was ‘verbose’ or ‘complex’ or ‘outdated’. And that it needed ‘getters and setters’ everywhere.

\n\n

Yet we’ve had great books on Java, as well as classics on OOP.

\n\n

So what changed?

\n\n

Here’s my theory. All the great books were written in the 1990s - before some of our modern Java developers were even born. The reason nobody knows the lessons in them is simple. We don’t teach them anymore.

\n\n

This book is my distillation of those classic ideas plus a twist of experience. Each chapter contains stuff I actually use, day to day, to get results. It’s full of hard-won wisdom from 25 years at the code face. It’s practical. And very simple. Bugs hide in complexity. I like to give bugs no place to hide.

\n\n

My hope is this book gets you past ‘getter and setter’ coding and gets you into high gear using objects as they were intended to be used. It might be your first insight into how OOP fits together in the real world. Java has a reputation for being verbose. I hope this book shows you how to fix that. I want you to take away the techniques of crafting clean, powerful, readable OOP code.

\n\n

This book is not an introduction to Java. It should be suitable for beginners who can write Java “Hello World” and understand the basic syntax for variables, conditionals and classes. Examples use Java 11 syntax. Many work in Java 1.

\n\n

Alan Mellor
Rock Cottage
February 2021

\n\n\n

\nOptimise for Clarity

Before we start, here’s the big theme of this book:

\n\n\n\n

Programming is all about explaining to another human what the computer happens to be doing at any given moment. As a by-product, it also tells the computer what to do.

\n\n

The reason this is so important is that what the computer actually runs is almost incomprehensible to anyone.

\n\n

As an example, if I write this:

\n\n\n

1 clearScreen();\n

\n\n\n\n\n

you can understand that I want the computer to clear everything off the screen, leaving it blank.

\n\n

The computer can’t though. It’s as dumb as rocks. Literally. Silicon chips are made of Silicon Dioxide - Sand.

\n\n

We need to pass this code through some kind of translator to turn this into the language of the computer. One that looks nothing like English.

\n\n

One of my old computers would need something like this:

\n\n

1   LD HL, 4000H  00100001 00000000 01000000\n2   LD DE, 4001H  00010001 00000001 01000000\n3   LD BC, 6143   00000001 11111111 00010111 \n4   LD (HL), 0    00110110 00000000\n5   LDIR          11101101 10110000\n

\n\n\n\n\n

Where the assembly language on the left was still a human-readable form. The binary on the right was what that computer ran on its Z80A microprocessor.

\n\n

I know which one I like better.

\n\n

The art of programming is making programs clear. Readable. Easy to skim read. No tricks.

\n\n

It is the difference between having to read all that binary and work out that it meant ‘clear the screen’, compared to reading ‘clearScreen()’.

\n\n

In a working professional team, nobody has the time, money, or desire to do that. Ever.

\n\n

This book is all about helping you create code that both you and your colleagues can understand.

\n\n\n

\nWhat is an object, anyway?

The best way to think about objects is as people at work. Each one has a specific job to do. They know how to do their job. They have all the knowledge, tools and supplies they need to do it.

\n\n

Think about how a handwritten letter gets sent through the post.

\n\n

We have a writer. They choose what words go in that letter, then write them down. This letter is then handed to a postman. The postman drives the letter to a sorting office.

\n\n

The sorting office has inside it a big map of postcodes. On that map, each postcode has a little pin with the another postman’s name, who is responsible for delivering the letters.

\n\n

The sorting office hands over the letter to the correct postman, who delivers it to a reader.

\n\n

So far, so dull. Just an everyday story about an outdated way of sending mail. But it contains the two key insights into Object Oriented Programming.

\n\n

Notice how the writer asks the postman to deliver the letter. The writer does not tell the postman how to deliver the letter. That’s not the writer’s job. The writer writes. The postman delivers. They each do their own job without interference from the other.

\n\n

The writer also doesn’t ask the postman anything at all about how the delivery will be done. The postman is free to do that however they see fit. They can even change how they do the delivery later. The writer will not be affected at all.

\n\n

This is the essence of OOP. Instead of people, we have objects. Each object knows how to do its own job.

\n\n

You’ll notice that this description is quite independent of programming languages. OOP itself is a design approach that can be done in any language - even assembler or C.

\n\n

Languages like Java are called OOP languages because they provide direct support for writing code that reads like this.

\n\n

\nWhat’s all this got to do with Java?

As an object oriented language, Java was designed to reflect the real world, like in our example above. It allows us to write code that speaks about Postman and Letter and deliver() and so on. It allows us to write computer code that reads like an English description of our problem. Not like code.

\n\n

We can write short pieces of code that can hold secrets, and present behaviours. Those short pieces of code can be asked to do things. The code representing what a postman knows and does can be asked to deliver a letter.

\n\n

The way Java does this is in two parts.

\n\n

First, it provides a ‘traditional’ computer language. It has variables, conditionals, loops and all the other good stuff we think of as code.

\n\n

Then it gives us a way to package up that code to represent real world concepts.

\n\n

These packages of code and data are called ‘objects’. Each object has a certain type - like “this object represents a postman”, or “this one is a user”. We call these Classes in Java. All objects belong to a class, which tells you what they represent. You can have any number of objects of the same class. You can have any number of classes.

\n\n

A Class represents an idea. It can create multiple objects. Objects can store their own data. They provide methods, which are small chunks of code that can be called by a program. These methods represent the behaviours we talked about. Things like ‘deliver a letter’, or ‘check spelling’ on a word.

\n\n

Methods can describe absolutely any behaviour we can think of. This is the superpower of object oriented programming.

\n\n

Confusing? Yes. It is at first. There’s a lot to learn.

\n\n

The easiest way to understand it all, I think, is by the ‘User’ example in the next section. But let’s introduce some terminology and Java syntax before we look at that.

\n\n

\nClasses, methods, constructors, objects, references

Object An object is a small bundles of methods and data, used to represent a single, specific thing: a person, a train, a word, a product.

\n\n

Class In Java, all objects belong to a class. A class allows one or more objects to be created. It is a blueprint or a template for the common features of each object.

\n\n

Method A method is used to describe the behaviours our object gives us. It is rather like a function that is specific to a class.

\n\n

New Keyword new takes a class name, then creates a specific object. It returns a reference to that object that we can store. This lets us use that object later in our code.

\n\n

Constructor A special method that new will call. It is responsible for setting up the object as it is being created. We can supply initial values of things here.

\n\n

Fields These are variables that are unique to each object. To help our behaviour methods do their work, we can store data in our object in fields.

\n\n

Object reference keyword new will create an object, set it up with a constructor, then return a ‘reference’. We can store this reference in a local variable, or in an object field. We can then call methods on that object, using the reference and the dot operator.

\n\n

this Inside a method, keyword ‘this’ is an object reference that refers to the ‘current object’. It is the same idea as when I talk to you and say ‘me’. I am referring to myself.

\n\n

private A keyword to mark a field or method as being usable only inside the Class. Outside, it is invisible. It is used to mark ‘secrets’.

\n\n

public A keyword to mark a method as being usable from outside the Class in calling code. Can be used on fields, but that is rare.

\n\n

\nA simple example: Greeting users

To show what we mean, let’s make a simple object: a User.

\n\n

Most systems have users. Hopefully, we’ll have loads of users - if our marketing works right. Our job is to show a personalised greeting to every one of them.

\n\n

The first design decision is to represent each user as an object. And to do that, we’ll need to code up a ‘blueprint’ for what all user objects have in common. A Java ‘User’ class:

\n\n\n

 1 public class User {\n 2   private String name ;  // 3. private data\n 3 \n 4   public User( String name ){. // 2. constructor\n 5     this.name = name ;\n 6   }\n 7 \n 8   public void greet() { // 1. greet method\n 9     System.out.println( \"Hello, \" + name );\n10   } \n11 }\n

\n\n\n\n\n

Before we can do anything with them, we need to create a simple test application. We’ll use the standard bit of Java boilerplate code to create an Application class with a ‘static main()’ - That’s a ‘magic method’ that tells the operating system where to start our Java program.

\n\n\n

1 public class GreetingsApplication {\n2   public static void main( String[] commandLineArgs ) {\n3     User u1 = new User( \"Jake\" );\n4     User u2 = new User( \"Katy\" );\n5 \n6     u1.greet();\n7     u2.greet();\n8   }\n9 }\n

\n\n\n\n\n

Running this program shows us ‘Hello, Jake’ and ‘Hello, Katy’. It does this by creating two, separate user objects and asking them to greet the user they represent.

\n\n

This code might look underwhelming, but it contains the most important basics of OOP. Let’s go through the key pieces.

\n\n

\nMethods - Making objects do stuff

The most important part about each object is what you can ask it to do: the public methods.

\n\n

Class User has a single method on it called ‘greet()’ (see 1).

\n\n

The method name tells us what the method does, not how. When we write the calling code, this name describes what this method will do for us. It also insulates us from having to care about how this gets done.

\n\n

This is important because it lets us change the internals of method greet(). When we do, there will be no change at all to the calling code.

\n\n

Our test app creates two user objects and calls the greet() method on each of them. Notice how close to plain English the test app reads. OOP is all about designing customised objects that do exactly the right thing for our app. We can name methods the same way we talk in English about the problem we’re solving.

\n\n

When we design objects, we start with behaviour methods. We add data and logic later, if it is needed to make those methods do their job.

\n\n

\nSecrets - Specialist knowledge for our objects

Just like the people in our example know things and have tools to help them work, objects have their secrets, too.

\n\n

Objects typically have two secrets:

\n\n

Data - which is unique to each object
Algorithms - the logic of how work is done

\n\n

Our greet method has both kinds of secrets.

\n\n

The logic secret of greet() is simple. We use Java’s System.out.println() library method to write text to the console.

\n\n

This is the how - how our method greets a user. Because it is hidden behind the greet method’s signature, we are free to change how we do this without affecting the calling code. This is important. This stops changes from ‘rippling out’ through the system. That makes the code easier to understand and safer to change.

\n\n

This is also why the calling code looks so simple. It is not concerned with deep technical details. It just asks for what it needs doing - user.greet(). It leaves it up to the object to get the work done.

\n\n

This is called the Tell Don’t Ask principle

\n\n

We tell the object what we would like it to do for us. We don’t ask it for any of its secrets and try to do its job ourselves in the calling code. It is a huge advantage in simplifying our code.

\n\n

Our object also has the other secret - data.

\n\n

For our greet() method to work, it will need to know the user’s name.

\n\n

We decided upfront that each User object will represent one individual user in the real world. That user has a name. So our user objects make the perfect place to store their name. We do this in the private field called ‘name’ (see 3)

\n\n

Having just one String field can be confusing to OOP beginners. How do you store the names of all the users without an array or something?

\n\n

Non-OOP code might well have an array or dictionary to store all the names of the users. OOP code splits this problem up a different way. As we have one object per user and only store one name for each user, our object only needs to store one name.

\n\n

Instead of one array with many names, we have many objects each with only one name. It’s less to think about and a lot more obvious. Where can we find a user’s name? In their object.

\n\n

This idea of self-contained objects makes Object Oriented programs simpler to understand.

\n\n

\nConstructors - Getting objects ready to use

As we create one object per user, we want to make sure that the object is ready to use after creation. This avoids many problems of ‘uninitialised data’ that plague other approaches.

\n\n

We have a special method to do this: the Constructor.

\n\n

The big idea of a constructor is that it creates an object, loads it up and makes it ready to use.

\n\n

For our User objects, the private ‘name’ field (see 3) is set inside the constructor. We pass each individual name into the constructor as a parameter.

\n\n

Constructors help keep our private data secret. They provide a way for the calling code to set up an object without knowing anything about its secrets.

\n\n

\nThe big idea: calling code is simple

Now we understand how the User class has been coded inside, let’s look at the big win of OOP: the public interface. The part that the calling code sees.

\n\n

It’s really simple.

\n\n

1 User u = new User(\"Alan\");\n2 u.greet();\n

\n\n\n\n\n

To write a program that knows how to greet a user, all we need to know - and call - are the two public pieces. We call the constructor to create the object and get it ready for use. Then we call greet(). It really couldn’t be any easier.

\n\n

Now, imagine how this helps us as we grow bigger programs. We might have hundreds or thousands of classes. Maybe tens of millions of lines of code. But with OOP, we only need to understand what our object’s public interface can do. It insulates us from the details.

\n\n

This is the key of OOP done right: the calling code is simple

\n\n

And if it isn’t … we’re doing it wrong.

\n\n

\nObject Oriented Design is Behaviour Driven Design

The key to doing OOP right is to let behaviours drive the design.

\n\n

The first question is always ‘what does this object need to do?’. We represent that as a method, using the name to describe the behaviour.

\n\n

Then, we can add supporting code inside that method to make it work. We might add calls to private methods to break the work into small chunks. We might need stored data as fields in the object. We would need a constructor in that case.

\n\n\n

\nClean Code

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nGood Names

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nMethod names: Tell me the outcome

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nVariable names: Tell me the contents

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDesign methods around behaviours, not data

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nHidden data - No getters, no setters

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nAggregates: More than one

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nGreeting more than one user

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nType safe collections, not raw arrays

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nUsing forEach - not a loop

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nAggregate methods work on all the things

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nCommon themes

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nCollaboration

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nBasic Mechanics

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nHow to decide: field or parameter?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nExample: Simple Point of Sale

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nReview of design so far

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nExercise: Total Amount

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nTest Driven Development

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nOutside-in design with TDD

TDD helps us design the public interface of our objects to be easy to use.

\n\n

The key is to write code that calls our object using what we think will be a good public interface. We do this before writing code inside our object. This forces us to think about making the calling code simple. Our ‘backwards thinking’ of OOP again.

\n\n

This piece of code is known as the test code. It will set up our object, call a behavioural method on it, and then check whether that method worked or not.

\n\n

This test does two things for us:

\n\n

verifies the behaviour is correct
verifies the call is easy to make - a hallmark of good design

\n\n

If our design is hard to set up or hard to use, we’ll see that in hard to read test code.

\n\n

Java projects use the wonderful JUnit test framework to help out with this. I like to add AssertJ to help with the checking part.

\n\n

Let’s use TDD to build a little calculator that can add up our restaurant bill. As you follow along, notice the rhythm of TDD - write a bit of test, see a failure, fix it with a bit of code, repeat.

\n\n

Our calculator class should do two things:

\n\n

give us a running total of all the items we’ve added
add another item.

\n\n

We start by writing an empty test. We want this test to prove something that will be true of our BillCalculator class as soon as we create it. If we create this object and don’t add any items to it, the total must be zero.

\n\n

Let’s start to write a test for that.

\n\n

\nFirst test: total starts at zero

\n\n\n

1 class BillCalculatorTest {\n2     @Test\n3     public void totalStartsAtZero() {\n4         // ... todo\n5     }\n6 }\n

\n\n\n\n\n

We’ve got a test class and a test harness method all named for what they do.

\n\n

Now we do a tiny step of design for our object. We want to be able to access the latest running total. For this, despite all my bleating in previous chapters, a getTotal() method seems like the simplest, most clear design.

\n\n\n\n

Let’s add this design decision to the test:

\n\n\n

1 class BillCalculatorTest {\n2     @Test\n3     public void totalStartsAtZero() {\n4         // Act\n5         float total = calculator.getTotal();\n6     }\n7 }\n

\n\n\n\n\n

The compiler will be loudly complaining at this point, as indeed might you if this is your first TDD session: “There isn’t any object yet!”

\n\n

Quite right. Let’s fix that.

\n\n

Using your IDE shortcuts, create a new Class called BillCalculator:

\n\n\n

1 class BillCalculator {\n2 }\n

\n\n\n\n

Now, we can fix the first of our compiler’s many complaints and create a calculator object:

\n\n\n

 1 class BillCalculatorTest {\n 2     @Test\n 3     public void totalStartsAtZero() {\n 4         // Arrange\n 5         var calculator = new BillCalculator();\n 6 \n 7         // Act\n 8         float total = calculator.getTotal();\n 9     }\n10 }\n

\n\n\n\n\n

I’m using the ‘var’ keyword from recent Java editions (don’t ask me which one; I never was a language lawyer kind of guy). I think this reads very clearly here.

\n\n

The compiler will grudgingly accept we are now not complete idiots and remove the red X from under ‘calculator’. It will then move on to its next complaint. We need to add the getTotal() method.

\n\n

Let the IDE shortcuts do this, because the IDE has all the information it needs to get it right:

\n\n\n

1 class BillCalculator {\n2     public float getTotal() {\n3         return 0.0;\n4     }\n5 }\n

\n\n\n\n\n

I love working backwards like this. The IDE has enough information to do most of the grunt work and not make as many typing mistakes as I do. It’s also a very fast way to work once you get into the rhythm of it. You even look (to the clueless) like a 10x mega ninja rock star programmer.

\n\n

Anyway. The compiler will be happy, allowing us to add our check that everything is ok. We’ll use the wonderful ‘AssertJ’¹ library to provide the ‘assertThat’ method.

\n\n\n

 1 class BillCalculatorTest {\n 2     @Test\n 3     public void totalStartsAtZero() {\n 4         // Arrange\n 5         var calculator = new BillCalculator();\n 6 \n 7         // Act\n 8         float total = calculator.getTotal();\n 9 \n10         // Assert\n11         assertThat(total).isZero();\n12     }\n13 }\n

\n\n\n\n\n

We can run this test - and it will pass! Our calculator object has passed its first and only test. It just so happens that the only thing we are testing is that the total is zero and the IDE generated code always returns zero.

\n\n

\nArrange, Act, Assert - a rhythm inside each test

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nRed, Green, Refactor - a rhythm in between tests

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nSecond test: Adding an item gives us the right total

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDesigning the second feature

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nTDD Steps - Too much? Too little?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nYAGNI - You Ain’t Gonna Need It

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nYAYA - Yes, You Are

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nOptimise for Clarity with well-named tests

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nTDD and OOP - A natural fit

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nFIRST Tests are usable tests

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nReal-world TDD

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe Good

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe Bad

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe Ugly

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nPolymorphism - The Jewel in the OOP Crown

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nClassic example: Shape.draw()

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe Shape Interface

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nTell Don’t Ask - the key to OOP

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe SOLID Principles

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe five SOLID principles

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nSRP Single Responsibility - do one thing well

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nWhat is ‘one thing’, anyway?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDIP Dependency Inversion: Bring out the Big Picture

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nWhat is an ‘inverted dependency’?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nWhy is ‘new’ such a problem?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nInverting the input Dependency

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nMaking a concrete KeyboardInput class

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDependency Injection - using our inverted dependency

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nSwappable input sources

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nInverting the output to display

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nInversion - Injection: two sides of the same coin

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nLSP Liskov Substitution Principle - Making things swappable

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nWhen Shapes go Bad

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nSubstitutability

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nOCP Open/Closed Principle - adding without change

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nStrategy Pattern: Externalising behaviour

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nISP Interface Segregation Principle - honest interfaces

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nBad Example: TV Controls

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nFixing our ISP violation

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nRedesigning to Command objects

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nPragmatics: I would choose to do it wrong

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nTDD and Test Doubles

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nTest Doubles - Stubs and Mocks

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDIP for Unit Tests - Stubs and Mocks

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nMocking libraries

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nSelf-Shunt mocks and stubs

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nRefactoring

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nWhat is refactoring?

Refactoring is the name given to changing the structure of our code whilst keeping its behaviour the same. Re-structuring our code, but without breaking anything.

\n\n

The name comes from factoring, which comes from algebra. Factoring is the basic idea of splitting something up into smaller parts. Refactoring is simply ‘doing it again’.

\n\n

I am always refactoring.

\n\n

I’ll refactor as part of the TDD process, as is standard. I will write a failing test, add the simplest production code to make it pass, then refactor.

\n\n

When faced with new code that’s hard to understand, I’ll refactor it first. That way, I capture any insights I get and preserve this hard-won understanding in the code.

\n\n

That’s why refactoring is useful. But how do we do it?

\n\n

Martin Fowler’s book Refactoring is the reference on this subject. The first edition is all Java-based and the one I recommend for Java devs. The second edition uses JavaScript ES6 with class support for the examples. It’s okay, but not as direct for us Java developers.

\n\n

Here are the refactoring steps I use all the time - and why.

\n\n

\nRename Method, Rename Variable

\n\n

 1 class User {\n 2     private final String text ;\n 3 \n 4     public User( String name ) {\n 5         this.text = name ;\n 6     }\n 7     \n 8     public void printout() {\n 9         System.out.println(\"Welcome back, \" + text);\n10     }\n11 }\n

\n\n\n\n\n

This User class will print out ‘Welcome back, Alan’ after creating the object passing in the name Alan.

\n\n

The name is stored in a field called ‘text’. Hmm. It is text - but that’s not really telling me what that field is used for. It is being used to store the User’s name that we want to put into the welcome message.

\n\n

The fix is to use Refactor > Rename of that field. Call it ‘name’.

\n\n

In the same vein, method ‘printout()’ isn’t very helpful in understanding the code, either. Yes, the method will print something out. We can read that. But that isn’t what it is doing, that’s how. We want our methods to explain why they are there and what their outcome is.

\n\n

We can use Refactor > Rename on the method name to give it a descriptive name. Let’s choose ‘welcome()’. This better explains what is being done.

\n\n\n

 1 class User {\n 2     private final String name ;\n 3 \n 4     public User( String name ) {\n 5         this.name = name ;\n 6     }\n 7     \n 8     public void welcome() {\n 9         System.out.println(\"Welcome back, \" + name);\n10     }\n11 }\n

\n\n\n\n\n

These two refactorings - changing the name of a field or method - are the ones I use all the time. Literally. To the point where I no longer stress out about thinking up ‘the best’ names. I just code, come up with a first stab at a name, then come back and refactor it when I get a better idea.

\n\n

I find my brain works like that. Something happens in the background as I am working away. I’ll get a better insight a little later.

\n\n

\nPrefer IDE tools over manual changes

Your IDE if it is IntelliJ, Eclipse, NetBeans or VS Code will automate this process. As Java is a strongly typed language, the IDE can find all references to that field text and change them all in one go. Same for the method and all its call sites.

\n\n\n\n

Use the tools. It is much faster. You will introduce fewer bugs.

\n\n

\nExtract Method

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nChange Method Signature

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nExtract Parameter Object

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nCan we refactor anything into anything else?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nHexagonal Architecture

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe problems of external systems

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe Test Pyramid

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nRemoving external systems

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe Hexagonal Model

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nInversion / Injection: Two sides of the same coin

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nHandling Errors

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThree kinds of errors

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nThe null reference

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nNull object pattern

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nZombie object

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nExceptions - a quick primer

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDesign By Contract, Bertrand Meyer style

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nFatal errors: Stop the world!

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nCombined approach: Fixable and non-fixable errors

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nWhich approach is best?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nNullPointerException

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nApplication Specific Exceptions

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nError object

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nOptionals - Java 8 streams approach

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nReview: Which approach to use?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDesign Patterns

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nMechanism and Domain

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nPatterns: Not libraries, not frameworks

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nStrategy

[GoF] Gives you pluggable behaviour

\n\n

Strategy is used when you have an object that needs a way to change its behaviour. Depending on configuration, or in response to external events, it needs to do some processing differently. You could do this with conditionals like switch statements. But you want to respect OCP and keep that object unmodified.

\n\n

Injecting a Strategy object enables this.

\n\n

As an example, employees can have different bonus schemes as they hit different targets.

\n\n

Here is our Strategy pattern interface. It will allow us to make various implementations:

\n\n\n

1 interface BonusScheme {\n2     void applyTo(Money pay);\n3 }\n

\n\n\n\n\n

We can now inject that in our Employee objects:

\n\n\n

 1 class Employee {\n 2   private BonusScheme bonus ;\n 3 \n 4   public Employee(BonusScheme bonus) {\n 5       this.bonus = bonus;\n 6   }\n 7 \n 8   Money totalPay() {\n 9       Money pay = calculateBasePay();\n10 \n11       // Use the strategy\n12       bonus.applyTo(pay);\n13 \n14       return pay;\n15   }\n16 \n17   private Money calculateBasePay() {\n18       // ... code\n19   }\n20 }\n

\n\n\n\n\n

This Employee object is now open for behaviour changes in its bonus scheme. But it is closed to modification. We don’t need to change the insides just to change a bonus scheme.

\n\n

Let’s demonstrate that with two simple schemes - NoBonus and BonusTwenty

\n\n\n

 1 class NoBonus implements BonusScheme {\n 2     void apply(Money pay) {\n 3         // No Action\n 4     }\n 5 }\n 6 \n 7 class BonusTwenty {\n 8     void apply(Money pay) {\n 9         pay.add(new Money(\"20.00\"));\n10     }\n11 }\n

\n\n\n\n\n

When we create employee objects, we inject whichever bonus scheme concrete object we want to use.

\n\n

Real payment systems are more complex and would have logic in the bonus scheme. That would collaborate with other objects, like Targets perhaps, to see if we qualify. The BonusScheme objects might even get Strategy pattern objects of their own.

\n\n

Strategy crops up everywhere you want to vary behaviour. In the same way a variable handles variable data, the Strategy pattern handles variable behaviour. It’s as simple as that.

\n\n

Strategy can be a low-level mechanism technique. At a higher level, it can express domain ideas that have changing behaviour in the real world. The classic being Employee objects that start out as juniors but then get promoted to managers. Strategy makes for a direct model of that.

\n\n

Examples: Tax Calculation, Payment schedule, Data source selection, Graphics filters, Plugins of all kinds, Extension points, Customisations, Skins, Complex rules.

\n\n

\nObserver

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nAdapter

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nCommand

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nComposite

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nFacade

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nBuilder

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nRepository

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nQuery

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nSimple Query Object

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nCollectingParameter

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nItem-Item Description

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nMoment-Interval

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nClock

[Own] Provides a way to represent current time that can be stubbed

\n\n

Time driven functions need to know the actual real-world time now. Writing this, it is the 11 Nov 2020, 22:54:23 BST.

\n\n

All usable systems provide a way to get real-world time. Java provides the older new Date() syntax to access the system clock. The Java 8 Joda-time inspired update provides newer features and a less zany syntax.

\n\n

But both systems share the same problem. If you use them directly in your code, you are stuck with the actual time, right now, in the real world. This makes testing either hard or impossible. Recreating a production fault from logs captured earlier is impossible, too.

\n\n

In both cases, we need a way to force the time to a test value.

\n\n

The Clock pattern is a simple abstraction of the system clock. Using the older Date syntax for simplicity, it looks like this:

\n\n\n

1 interface Clock {\n2     Date now();\n3 }\n

\n\n\n\n\n

This is a Dependency Inversion (DIP). Our code now depends on only this interface for its source of the current time, using the now() method.

\n\n

For production, we define a SystemClock class:

\n\n\n

1 class SystemClock implements Clock {\n2     public Date now() {\n3         return new Date();\n4     }\n5 }\n

\n\n\n\n\n

We Dependency Inject this SystemClock class to everywhere that needs to know the time. Often, this comes from a Config class that runs at application startup.

\n\n

For testing, we inject a stub class:

\n\n\n

 1 class StubClock implements Clock {\n 2     private Date date ;\n 3 \n 4     public Date now() {\n 5         return date ;\n 6     }\n 7 \n 8     public void setTo( Date d ) {\n 9         this.date = d;\n10     }\n11 \n12     public void oneHourLater() {\n13         // code to go forward one hour\n14     }\n15 \n16     public void oneHourEarlier() {\n17         // code to go back one hour\n18     }\n19 }\n

\n\n\n\n\n

This stub has features to set to a specific time, then move to an hour later or earlier. You would change these to your specific test requirements. The idea is that you are creating a Domain Specific Language (DSL) about test times, to make your test code into readable documentation.

\n\n

This is one of those insanely useful patterns that it is actually muscle memory for me.

\n\n

\nRules (or Policy)

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nAggregate

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nCache

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDecorator

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nExternal System (Proxy)

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nConfiguration

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nOrder-OrderLineItem

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nRequest-Service-Response

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nAnti-Patterns

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDesign Pattern Soup

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nUnneeded Flexibility

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nMechanism Madness

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nOOP Mistakes - OOP oops!

So far, we’ve covered ways to use OOP well.

\n\n

We’ve seen a lot of techniques that make code readable, easy to test and compact. Remember how easy it was to combine Repository with Cache with Decorator and get a pluggable speed boost?

\n\n

It turns out that not everybody agrees that OOP is a good thing.

\n\n

In part, of course, they are right. Plenty of things just are not suited to OOP. I can think of simple batch scripts, build scripts and Terraform scripts that set up infrastructure. We also have ‘Serverless Designs’, which use many small functions to do their work. OOP often gets in the way there.

\n\n

Another driver of non-OOP designs has been processing power limitations.

\n\n

For decades, CPUs followed Moore’s Law. Computing power doubled every two years. But then it hit a physical limit. CPUs had as many transistors on them as could be fitted. “I cannae change the laws o’ physics!” said Scottie in Star Trek; So it is with photolithography. A transistor can be made only so small, but no smaller. Then physics fights back.

\n\n

To get around this, CPUs created multiple cores - multiple copies of a CPU design on the same chip.

\n\n

This impacted software design. Suddenly, we needed parallel processing rather than sequential. The kinds of state that lived inside one object of OOP was not accessible to other CPU cores. OOP became less useful as a model of communicating state across CPU cores. Functional Programming - “stateless” programming - is useful here.

\n\n

However, none of that was what gave OOP a bad name. What gave it a bad name was OOP done wrong.

\n\n

So, what are the common mistakes?

\n\n

\nBroken Encapsulation - Getters Galore!

At Number 1 in my chart of badness, a very common error:

\n\n\n

 1 class User {\n 2     private String name ;\n 3 \n 4     // This is painful to type ...\n 5     public String getName() {\n 6         return name ;\n 7     }\n 8 \n 9     // ... so is this\n10     public void setName( String name ) {\n11         this.name = name;\n12     }\n13 }\n14 \n15 class UserGreeter {\n16 \n17     // I swear fairies and kittens are dying right now\n18     public void greet( User u ) {\n19         System.out.prinltn( u.getName() );\n20     }\n21 }\n

\n\n\n\n\n

We’ve all seen this - getters and setters everywhere!

\n\n

It makes me sad. It really does.

\n\n

Now, to be fair, Java has to take a lot of blame for this. Right from version 1.0, Java had this idea of “Java Beans” which were things like User above.

\n\n

You had fields, but every field had a getter and setter. Somehow, that became A Thing (TM), and it was used everywhere. Then taught everywhere. Then somebody decided this was an “object” - because it is in a class and has private data and public methods.

\n\n

This caught on with developers who had understood procedural programming but hadn’t yet learned OO. They hadn’t learned about objects exposing behaviour and hiding secrets.

\n\n

When you think in that way, every problem looks like getters-and-setters. Object secrets are made un-secret. Code that should be a method on the User object now appears in some redundant “class” UserGreeter. It’s not really a class, because it doesn’t really have any real secret. It has stolen a secret from User.

\n\n

It’s just procedural programming, plain and simple.

\n\n

Procedural designs simply do not gain the benefits of OOP. But they do have the words ‘class’ and ‘private’ in them. To the uninformed, they look like an OO design. But they are not.

\n\n

When people criticise OOP for not delivering on its promises - but base it on code like this - it is obvious where the fault lies: This one is on them.

\n\n

If you don’t even realise your code is not OOP, then don’t criticise OOP for your code!

\n\n

\nBroken Inheritance

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nBird extends Animal

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nSquare extends Rectangle

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nInheriting implementation

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nBroken Shared State

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nOrdinary Bad Code

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nData Structures and Pure Functions

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nSystem Boundaries

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nFixed Data, Changing Functions

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nAlgorithms and Data Structures

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nPutting It All Together

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nNo step-by-step plans

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nGetting Started

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nPerfection and Pragmatism

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nGetting Past Stuck

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nFurther Reading

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nAgile Software Development, Robert C Martin

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nGrowing Object Oriented Software Guided By Tests, Freeman and Pryce

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nRefactoring, Martin Fowler

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDesign Patterns Helm, Johnson, Richards, Vlissides

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDomain Driven Design, Eric Evans

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nApplying UML with Patterns, Craig Larman

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nHome page for this book

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nMy Blog

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nMy Quora Space

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nLinkedIn

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nLeanPub page

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nCheat Sheet

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nBehaviours First

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nDesign Principles

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nClean Code

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nGeneral Code Review Points

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/javaoopdoneright.

\n\n\n

\nAbout the Author

Starting from age 12, Alan Mellor has four decades of experience developing software, for various companies, startups and as a freelancer.

\n\n

From a humble Sinclair ZX81 home computer with 1k of RAM, Alan has progressed to creating systems for industrial automation, defence, e-commerce, games and mobile phones.

\n\n

Some you may have heard of: Nokia Bounce, The Ericsson R380s smartphone, The Red Arrows flight simulator from 1985 and Fun School 2. All had Alan’s code in them. Other code sits there quietly, doing its thing unnoticed. Yet more has been consigned to the great /dev/null of history.

\n\n

More recently, Alan has been involved with training UK Level 4 Apprentices. He has designed and delivered content that hopefully helps ‘switch the light on’ about programming.

\n\n

Alan also enjoys dabbling variously with guitars, electronics, videography and cheeseboards. You just can’t beat a great Roquefort with Rioja.

\n\n

\nThanks

BJSS Limited and Manchester Digital for opportunities to use and teach this stuff.

\n\n

Steven Taylor - great suggestions on the first draft (despite more work!)

\n\n

My Mum. That ZX81 didn’t buy itself. You made my career happen.

\n\n

Stephanie, Katy, Jake. Who would have guessed a 1980s computer nerd would end up surrounded by amazing humans he can call ‘family’. What a privilege.

\n\n

Katy for front cover art https://www.redbubble.com/people/kath-ryn/shop

\n\n

\nBuy the book!

\n\n

What you read was just a sample of various chapters. If you like the style, why not buy the full book? Go on - treat yourself!

\nNotes

What is an object, anyway?

\n\n

\n\n","tocStructure",[556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684,685,686,687,688,689,690,691,692,693,694],{"_75":76,"_43":77,"_70":-5,"_78":79,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":85,"_70":-5,"_78":86,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":89,"_70":-5,"_78":90,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":94,"_70":-5,"_78":95,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":99,"_70":-5,"_78":100,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":102,"_70":-5,"_78":103,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":105,"_70":-5,"_78":106,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":108,"_70":-5,"_78":109,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":112,"_70":-5,"_78":113,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":115,"_70":-5,"_78":116,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":118,"_70":-5,"_78":119,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":121,"_70":-5,"_78":122,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":125,"_70":-5,"_78":126,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":128,"_70":-5,"_78":129,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":131,"_70":-5,"_78":132,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":134,"_70":-5,"_78":135,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":138,"_70":-5,"_78":139,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":141,"_70":-5,"_78":142,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":144,"_70":-5,"_78":145,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":148,"_70":-5,"_78":149,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":151,"_70":-5,"_78":152,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":154,"_70":-5,"_78":155,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":157,"_70":-5,"_78":158,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":160,"_70":-5,"_78":161,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":163,"_70":-5,"_78":164,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":166,"_70":-5,"_78":167,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":169,"_70":-5,"_78":170,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":172,"_70":-5,"_78":173,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":175,"_70":-5,"_78":176,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":178,"_70":-5,"_78":179,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":181,"_70":-5,"_78":182,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":184,"_70":-5,"_78":185,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":187,"_70":-5,"_78":188,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":191,"_70":-5,"_78":192,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":194,"_70":-5,"_78":195,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":197,"_70":-5,"_78":198,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":200,"_70":-5,"_78":201,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":204,"_70":-5,"_78":205,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":207,"_70":-5,"_78":208,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":210,"_70":-5,"_78":211,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":213,"_70":-5,"_78":214,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":216,"_70":-5,"_78":217,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":219,"_70":-5,"_78":220,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":222,"_70":-5,"_78":223,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":226,"_70":-5,"_78":227,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":229,"_70":-5,"_78":230,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":232,"_70":-5,"_78":233,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":235,"_70":-5,"_78":236,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":238,"_70":-5,"_78":239,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":242,"_70":-5,"_78":243,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":245,"_70":-5,"_78":246,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":248,"_70":-5,"_78":249,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":251,"_70":-5,"_78":252,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":254,"_70":-5,"_78":255,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":257,"_70":-5,"_78":258,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":260,"_70":-5,"_78":261,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":264,"_70":-5,"_78":265,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":267,"_70":-5,"_78":268,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":270,"_70":-5,"_78":271,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":273,"_70":-5,"_78":274,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":276,"_70":-5,"_78":277,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":279,"_70":-5,"_78":280,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":283,"_70":-5,"_78":284,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":286,"_70":-5,"_78":287,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":289,"_70":-5,"_78":290,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":292,"_70":-5,"_78":293,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":295,"_70":-5,"_78":296,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":298,"_70":-5,"_78":299,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":301,"_70":-5,"_78":302,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":304,"_70":-5,"_78":305,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":307,"_70":-5,"_78":308,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":310,"_70":-5,"_78":311,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":313,"_70":-5,"_78":314,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":316,"_70":-5,"_78":317,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":319,"_70":-5,"_78":320,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":322,"_70":-5,"_78":323,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":325,"_70":-5,"_78":326,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":329,"_70":-5,"_78":330,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":332,"_70":-5,"_78":333,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":335,"_70":-5,"_78":336,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":338,"_70":-5,"_78":339,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":341,"_70":-5,"_78":342,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":344,"_70":-5,"_78":345,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":347,"_70":-5,"_78":348,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":350,"_70":-5,"_78":351,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":353,"_70":-5,"_78":354,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":356,"_70":-5,"_78":357,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":359,"_70":-5,"_78":360,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":362,"_70":-5,"_78":363,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":365,"_70":-5,"_78":366,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":368,"_70":-5,"_78":369,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":371,"_70":-5,"_78":372,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":374,"_70":-5,"_78":375,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":377,"_70":-5,"_78":378,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":380,"_70":-5,"_78":381,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":383,"_70":-5,"_78":384,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":386,"_70":-5,"_78":387,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":389,"_70":-5,"_78":390,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":392,"_70":-5,"_78":393,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":395,"_70":-5,"_78":396,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":398,"_70":-5,"_78":399,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":401,"_70":-5,"_78":402,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":405,"_70":-5,"_78":406,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":408,"_70":-5,"_78":409,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":411,"_70":-5,"_78":412,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":414,"_70":-5,"_78":415,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":417,"_70":-5,"_78":418,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":420,"_70":-5,"_78":421,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":423,"_70":-5,"_78":424,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":426,"_70":-5,"_78":427,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":430,"_70":-5,"_78":431,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":433,"_70":-5,"_78":434,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":436,"_70":-5,"_78":437,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":439,"_70":-5,"_78":440,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":443,"_70":-5,"_78":444,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":446,"_70":-5,"_78":447,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":449,"_70":-5,"_78":450,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":452,"_70":-5,"_78":453,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":455,"_70":-5,"_78":456,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":459,"_70":-5,"_78":460,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":462,"_70":-5,"_78":463,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":465,"_70":-5,"_78":466,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":468,"_70":-5,"_78":469,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":471,"_70":-5,"_78":472,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":474,"_70":-5,"_78":475,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":477,"_70":-5,"_78":478,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":480,"_70":-5,"_78":481,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":483,"_70":-5,"_78":484,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":486,"_70":-5,"_78":487,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":489,"_70":-5,"_78":490,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":492,"_70":-5,"_78":493,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":496,"_70":-5,"_78":497,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":499,"_70":-5,"_78":500,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":108,"_70":-5,"_78":502,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":504,"_70":-5,"_78":505,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":507,"_70":-5,"_78":508,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":93,"_43":511,"_70":-5,"_78":512,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":514,"_70":-5,"_78":515,"_71":80,"_96":-5,"_97":-5,"_83":-5},{"_75":76,"_43":518,"_70":-5,"_78":519,"_71":80,"_96":-5,"_97":-5,"_83":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nBuy the book!

Table of Contents

\nPreface

\nOptimise for Clarity

\nWhat is an object, anyway?

\nWhat’s all this got to do with Java?

\nClasses, methods, constructors, objects, references

\nA simple example: Greeting users

\nMethods - Making objects do stuff

\nSecrets - Specialist knowledge for our objects

\nConstructors - Getting objects ready to use

\nThe big idea: calling code is simple

\nObject Oriented Design is Behaviour Driven Design

\nClean Code

\nGood Names

\nMethod names: Tell me the outcome

\nVariable names: Tell me the contents

\nDesign methods around behaviours, not data

\nHidden data - No getters, no setters

\nAggregates: More than one

\nGreeting more than one user

\nType safe collections, not raw arrays

\nUsing forEach - not a loop

\nAggregate methods work on all the things

\nCommon themes

\nCollaboration

\nBasic Mechanics

\nHow to decide: field or parameter?

\nExample: Simple Point of Sale

\nReview of design so far

\nExercise: Total Amount

\nTest Driven Development

\nOutside-in design with TDD

\nFirst test: total starts at zero

\nArrange, Act, Assert - a rhythm inside each test

\nRed, Green, Refactor - a rhythm in between tests

\nSecond test: Adding an item gives us the right total

\nDesigning the second feature

\nTDD Steps - Too much? Too little?

\nYAGNI - You Ain’t Gonna Need It

\nYAYA - Yes, You Are

\nOptimise for Clarity with well-named tests

\nTDD and OOP - A natural fit

\nFIRST Tests are usable tests

\nReal-world TDD

\nThe Good

\nThe Bad

\nThe Ugly

\nPolymorphism - The Jewel in the OOP Crown

\nClassic example: Shape.draw()

\nThe Shape Interface

\nTell Don’t Ask - the key to OOP

\nThe SOLID Principles

\nThe five SOLID principles

\nSRP Single Responsibility - do one thing well

\nWhat is ‘one thing’, anyway?

\nDIP Dependency Inversion: Bring out the Big Picture

\nWhat is an ‘inverted dependency’?

\nWhy is ‘new’ such a problem?

\nInverting the input Dependency

\nMaking a concrete KeyboardInput class

\nDependency Injection - using our inverted dependency

\nSwappable input sources

\nInverting the output to display

\nInversion - Injection: two sides of the same coin

\nLSP Liskov Substitution Principle - Making things swappable

\nWhen Shapes go Bad

\nSubstitutability

\nOCP Open/Closed Principle - adding without change

\nStrategy Pattern: Externalising behaviour

\nISP Interface Segregation Principle - honest interfaces

\nBad Example: TV Controls

\nFixing our ISP violation

\nRedesigning to Command objects

\nPragmatics: I would choose to do it wrong

\nTDD and Test Doubles

\nTest Doubles - Stubs and Mocks

\nDIP for Unit Tests - Stubs and Mocks

\nMocking libraries

\nSelf-Shunt mocks and stubs