OCA/OCP Java SE 7 Programmer I & II Study Guide (Exams 1Z0-803 & 1Z0-804) (2015)

Part 2. OCP

Chapter 10. Advanced OO and Design Patterns

CERTIFICATION OBJECTIVES

• Write Code that Declares, Implements, and/or Extends Interfaces

• Choose Between Interface Inheritance and Class Inheritance

• Apply Cohesion, Low-Coupling, IS-A, and HAS-A Principles

• Apply Object Composition Principles (Including HAS-A Relationships)

• Design a Class Using the Singleton Design Pattern

• Write Code to Implement the DAO Pattern

• Design and Create Objects Using a Factory and Use Factories from the API

Two-Minute Drill

Q&A Self Test

You were introduced to object-oriented (OO) principles in Chapter 2. We will be looking at some more advanced principles here, including coupling and cohesion. You’ll also learn what a design pattern is and dip your toe into the world of patterns by exploring three of them. As a bit of a teaser, a design pattern is a reusable solution to problems. Which will come in handy so you aren’t reinventing new ways to solve common problems.

CERTIFICATION OBJECTIVES

IS-A and HAS-A (OCP Objectives 3.3 and 3.4)

3.3 Apply cohesion, low-coupling, IS-A, and HAS-A principles.

3.4 Apply object composition principles (including HAS-A relationships).

You learned the difference between IS-A and HAS-A in Chapter 2. As a brief review, how many IS-A/HAS-A statements can you write about BeachUmbrella?

We can make four statements about BeachUmbrella:

BeachUmbrella IS-A Umbrella

BeachUmbrella IS-A SunProtector

BeachUmbrella HAS-A Stand

And, of course, as always, BeachUmbrella IS-A Object

In a nutshell, IS-A happens when a class uses inheritance—e.g., when a class extends another class or implements an interface. HAS-A happens when a class has instance variables of a class.

Coupling and Cohesion

We’re going to admit it up front: The Oracle exam’s definitions for cohesion and coupling are somewhat subjective, so what we discuss in this chapter is from the perspective of the exam and is by no means The One True Word on these two OO design principles. It may not be exactly the way that you’ve learned it, but it’s what you need to understand to answer the questions. You’ll have very few questions about coupling and cohesion on the real exam.

These two topics, coupling and cohesion, have to do with the quality of an OO design. In general, good OO design calls for loose coupling and shuns tight coupling, and good OO design calls for high cohesion and shuns low cohesion. As with most OO design discussions, the goals for an application are

Ease of creation

Ease of maintenance

Ease of enhancement

Coupling

Let’s start by attempting to define coupling. Coupling is the degree to which one class knows about another class. If the only knowledge that class A has about class B is what class B has exposed through its interface, then class A and class B are said to be loosely coupled… that’s a good thing. If, on the other hand, class A relies on parts of class B that are not part of class B’s interface, then the coupling between the classes is tighter… not a good thing. In other words, if A knows more than it should about the way in which B was implemented, then A and B are tightly coupled.

Using this second scenario, imagine what happens when class B is enhanced. It’s quite possible that the developer enhancing class B has no knowledge of class A—why would she? Class B’s developer ought to feel that any enhancements that don’t break the class’s interface should be safe, so she might change some noninterface part of the class, which then causes class A to break.

At the far end of the coupling spectrum is the horrible situation in which class A knows non-API stuff about class B, and class B knows non-API stuff about class A—this is REALLY BAD. If either class is ever changed, there’s a chance that the other class will break. Let’s look at an obvious example of tight coupling that has been enabled by poor encapsulation.

All nontrivial OO applications are a mix of many classes and interfaces working together. Ideally, all interactions between objects in an OO system should use the APIs—in other words, the contracts of the objects’ respective classes. Theoretically, if all of the classes in an application have well-designed APIs, then it should be possible for all interclass interactions to use those APIs exclusively. As we discussed in Chapter 2, an aspect of good class and API design is that classes should be well encapsulated.

The bottom line is that coupling is a somewhat subjective concept. Because of this, the exam will test you on really obvious examples of tight coupling; you won’t be asked to make subtle judgment calls.

Cohesion

While coupling has to do with how classes interact with each other, cohesion is all about how a single class is designed. The term cohesion is used to indicate the degree to which a class has a single, well-focused purpose. Keep in mind that cohesion is a subjective concept. The more focused a class is, the higher its cohesiveness—a good thing. The key benefit of high cohesion is that such classes are typically much easier to maintain (and less frequently changed) than classes with low cohesion. Another benefit of high cohesion is that classes with a well-focused purpose tend to be more reusable than other classes. Let’s look at a pseudo-code example:

Now imagine your manager comes along and says, “Hey, you know that accounting application we’re working on? The clients just decided that they’re also going to want to generate a revenue projection report, oh and they want to do some inventory reporting also. They do like our reporting features, however, so make sure that all of these reports will let them choose a database, choose a printer, and save generated reports to data files….” Ouch!

Rather than putting all the printing code into one report class, we probably would have been better off with the following design right from the start:

This design is much more cohesive. Instead of one class that does everything, we’ve broken the system into four main classes, each with a very specific, or cohesive, role. Because we’ve built these specialized, reusable classes, it’ll be much easier to write a new report since we already have the database connection class, the printing class, and the file saver class, and that means they can be reused by other classes that might want to print a report.

CERTIFICATION OBJECTIVE

Object Composition Principles (OCP Objective 3.4)

3.4 Apply object composition principles.

Object composition principles build on IS-A and HAS-A. If you aren’t 100 percent comfortable with the differences between IS-A and HAS-A, go back and reread Chapter 2 before continuing on.

Object composition refers to one object having another as an instance variable (HAS-A). Sometimes, that instance variable might be the same type as the object we are writing. Think about when you get that package from Amazon that is a box containing some bubble wrap, a receipt, and yet another box. That is composition at work. The outer (containing class) box contains an inner (instance) box.

Let’s build out this box example. We want to reuse as much code as possible. After all, the procedure for sealing a box with some tape doesn’t change from box to box. Let’s start with the concept of a Box:

Wait. Boxes are simple. Why do we need an interface? We realize there are many types of boxes. There are gift boxes, jewelry boxes, small boxes, large boxes, etc. Now we create a concrete type of Box:

GiftBox implements Box by implementing the two methods Box requires. Providing an interface lets us keep the Box logic where it belongs—in the relevant subclasses. And to review, GiftBox IS-A Box.

Now that we’ve figured out Box, it’s time to build a MailerBox:

See any problems? That’s right, we’ve duplicated the logic to pack and seal the Box. All two lines of it. Our real Box logic would be a lot longer, though. And when we start manufacturing different types of boxes, we’d have that Box logic all over the place.

One thought is to solve this by having MailerBox extend GiftBox. It doesn’t take long to see the problem here. We would need MailerGiftBox, MailerSmallBox, MailerMediumBox, etc. That’s a lot of classes! And this technique would repeat for other types of functionality we create. Which means we would also need WrappedGiftBox, MailerWrappedGiftBox. Uh oh. We can only extend one class in Java. We can’t inherit both Mailer and GiftBox functionality. Clearly, IS-A isn’t going to work for us here.

Instead, we can use HAS-A. First, we create the interface for our desired functionality:

Then we can create the object that is both a Box and Mailer:

The first thing to notice is that the logic to pack and seal a box is only in one place—in the Box hierarchy where it belongs. In fact, the MailerBox doesn’t even know what kind of Box it has. This allows us to be very flexible.

Next, notice the implementation of pack() and seal(). That’s right—each is one line. We delegate to Box to actually do the work. This is called method forwarding or method delegation. These two terms mean the same thing.

Finally, notice that MailerBox is both a Box and a Mailer. This allows us to pass it to any method that needs a Box or a Mailer.

Polymorphism

Looking at these classes graphically, we have the following:

Think about which of the objects can be passed to this method:

GiftBox can because it implements Box. So can MailerBox for the same reason. MailerBox knows how to pack—by delegating to the Box instance. This is why it is important for the composing class to both contain and implement the same interface. Repeating the relevant parts here, we have:

You can see the composition part. MailerBox both IS-A Box and HAS-A Box. MailerBox is composed of a Box and delegates to Box for logic. That’s the terminology for object composition.

Benefits of Composition

Benefits of composition include

Reuse An object can delegate to another object rather than repeating the same code.

Preventing a proliferation of subclasses We can have one class per functionality rather than needing one for every combination of functionalities.

CERTIFICATION OBJECTIVES

Singleton Design Pattern (OCP Objective 3.5)

3.5 Design a class using the singleton design pattern.

In a nutshell, the singleton design pattern ensures we only have one instance of a class of an object within the application. It’s called a creational design pattern because it deals with creating objects. But wait, what’s this “design pattern”?

What Is a Design Pattern?

Wikipedia currently defines a design pattern as “a general reusable solution to a commonly occurring problem within a given context.” What does that mean? As programmers, we frequently need to solve the same problem repeatedly. Such as how to only have one of a class of an object in the application. Rather than have everyone come up with their own solution, we use a “best practice” type solution that has been documented and proven to work. The word “general” is important. We can’t just copy and paste a design pattern into our code. It’s just an idea. We can write an implementation for it and put that in our code.

Using a design pattern has a few advantages. We get to use a solution that is known to work. The tradeoffs, if any, are well documented so we don’t stumble over problems that have already been solved. Design patterns also serve as a communication aid. Your boss can say, “We will use a singleton,” and that one word is enough to tell you what is expected.

When books or web pages document patterns, they do so using consistent sections. In this book, we have sections for the “Problem,” “Solution,” and “Benefits.” The “Problem” section explains why we need the pattern—what problem we are trying to solve. The “Solution” section explains how to implement the pattern. The “Benefits” section reviews why we need the pattern and how it has helped us solve the problem. Some of the benefits are hinted at in the “Problem” section. Others are additional benefits that come from the pattern.

While the exam only covers three patterns, this is just to get your feet wet. Whole books are written on the topic of design patterns. Head First Design Patterns (O’Reilly Media, 2004) covers more patterns. And the most famous book on patterns, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional, 1994)—also known as “Gang of Four”—covers 23 design patterns. You may notice that these books are over 10 years old. That’s because the classic patterns haven’t changed.

While each book does use a consistent set of sections, there isn’t one common set of names. You will see synonyms used such as “Problem” versus “Motivation.” You will also see additional sections such as “Consequences.” The exam picks simpler patterns so you can use the simpler sections.

When talking about patterns, they are usually presented in a problem/solution format. Then, depending on the level of detail, other sections are added. In this book, each pattern will cover the problem, solution, and benefits.

Problem

Let’s suppose we are going to put on a show. We have one performance of this show and we only have a few seats in the theater.

This code prints out true twice. That’s a problem. We just put two people in the same seat. Why? We created a new Show object every time we needed it. Even though we want to use the same theater and seats, Show deals with a new set of seats each time. Which causes us to double-book seats.

Solution

There are a few ways to implement the singleton pattern. The simplest is

Now the code prints true and false. Much better! We are no longer going to have two people in the same seat. The bolded bits in the code call attention to the implementation of the singleton pattern.

The key parts of the singleton pattern are

A private static variable to store the single instance called the singleton. This variable is usually final to keep developers from accidentally changing it.

A public static method for callers to get a reference to the instance.

A private constructor so no callers can instantiate the object directly.

Remember, the code doesn’t create a new Show each time, but merely returns the singleton instance of Show each time getInstance() is called.

To understand this a little better, consider what happens if we change parts of the code.

If the constructor weren’t private, we wouldn’t have a singleton. Callers would be free to ignore getInstance() and instantiate their own instances. Which would leave us with multiple instances in the program and defeat the purpose entirely.

If getInstance() weren’t public, we would still have a singleton. However, it wouldn’t be as useful because only static methods of the class Show would be able to use the singleton.

If getInstance() weren’t static, we’d have a bigger problem. Callers couldn’t instantiate the class directly, which means they wouldn’t be able to call getInstance() at all.

If INSTANCE weren’t static and final, we could have multiple instances at different points in time. These keywords signal that we assign the field once and it stays that way for the life of the program.

When talking about design patterns, it is common to also communicate the pattern in diagram form. The singleton pattern diagram looks like this:

A format called UML (Unified Modeling Language) is used. The diagrams in this book use some aspects of UML, such as a box with three sections representing each class. Actual UML uses more notation, such as showing public versus private visibility. You can think of this as faux-UML.

As long as the method in the diagram keeps the same signature, we can change our logic to other implementations of the singleton pattern. One “feature” of the above implementation is that it creates the Show object before we need it. This is called eager initialization, which is good if the object isn’t expensive to create or we know it will be needed for every run of the program. Sometimes, however, we want to create the object only on the first use. This is called lazy initialization.

In this case, INSTANCE isn’t set to be a Show until the first time getInstance() is called. Walking through what happens, the first time getInstance() is called, Java sees INSTANCE is still null and creates the singleton. The second time getInstance() is called, Java sees INSTANCE has already been set and simply returns it. In this example, INSTANCE isn’t final because that would prevent the code from compiling.

The singleton code here assumes you are only running one thread at a time. It is NOT thread-safe. Think about if this were a web site and two users managed to be booking a seat at the exact same time. If getInstance() were running at the exact same time, it would be possible for both of them to see that INSTANCE was null and create a new Show at the same time. There are a few ways to solve this. One is to add synchronized to the getInstance() method. This works, but comes with a small performance hit. We’re getting way beyond the scope of the exam, but you can Google “double checked locked pattern” for more information.

You might have noticed that the code for getInstance() can get a bit complicated. In Java 5, there became a much shorter way of creating a singleton:

Short and sweet. By definition, there is only one instance of an enum constant. You are probably wondering why we’ve had this whole discussion of the singleton pattern when it can be written so easily. The main reason is that enums were introduced with Java 5 and there is a ton of older code out there that you need to be able to understand. Another reason is that sometimes the older versions of the pattern are still needed.

Benefits

Benefits of the singleton pattern include the following:

The primary benefit is that there is only one instance of the object in the program. When an object’s instance variables are keeping track of information that is used across the program, this becomes useful. For example, consider a web site visitor counter. You only want one count that is shared.

Another benefit is performance. Some objects are expensive to create. For example, maybe we need to make a database call to look up the state for the object.

CERTIFICATION OBJECTIVES

DAO Design Pattern (OCP Objective 3.6)

3.6 Write code to implement the DAO pattern.

DAO stands for “Data Access Object.” A DAO is only responsible for storing data. Nothing else. Why can’t we do this in the object with everything else, you ask?

Suppose we have three objects in our program as shown in Table 10-1.

TABLE 10-1 Object Responsibilities

Already there is a problem. These classes aren’t cohesive. Remember cohesion? We want each class to have a single purpose. Storing and searching objects in the database is NOT that purpose. Having that database code all over makes it hard to focus on the classes’ core purpose for existing, which is clearly for our entertainment. Since dealing with a database is very common, separating out that responsibility is a pattern—the DAO.

Problem

Let’s drill down into just the Book class. This is the poorly written, noncohesive version. Pay particular attention to the two responsibilities.

Counting the getters and setters we didn’t want to bore you with, the Book class is over 50 lines. And it hardly does anything! A real Book class would have a lot more fields. A bookstore needs to tell you when the book was written, the edition, the price, and all sorts of other information. A bookstore also needs to be able to keep track of books somewhere other than a map. After all, we don’t want our bookstore to forget everything when we reboot.

The problem is that our class is responsible for two things. The first is keeping track of being a book. This seems like a good responsibility for a class to have that is named Book. The other is keeping track of storage responsibilities.

A datastore is the name of—wait for it—where data is stored. In the real world, we’d use a database or possibly a file containing the books. For testing, we might use an in-memory database. The map in Book is actually a bare-bones in-memory datastore. As you’ll see in Chapter 15, using a real database would make the Book class MUCH longer.

This is a problem. We want our code to be easy to read and focused on one responsibility.

Solution

The DAO pattern has us split up these two responsibilities. We start by letting our Book class focus on being a book:

There can be other methods in Book such as toString(), hashCode(), and equals(). These methods have to do with the Book object. Methods that have to do with a bookstore or database are now gone. Much better. Now we can go on to the data access code:

The new InMemoryBookDao class only knows how to do one thing—deal with the datastore. This is such a common technique that it has a name: the single responsibility principle. The method names in the DAO are actually standard. You’ll see them again when you get to Chapter 15.

When everything was in the Book object, we just created a Book and started calling methods. Now that Book and DAO are separate objects, the caller deals with two objects:

The new DAO object gets all the calls that have to do with the datastore. Table 10-2 shows why each method call is associated with each class.

TABLE 10-2 DAO Method Call Associations

Good so far? The DAO pattern only has one more part. Our datastore is pretty wimpy right now. Every time we restart the program, it forgets what books we have. At some point, we are going to want to change that. But when we do, we want to make it easier for callers to change.

Since all the method names in the interface match our existing DAO, all we have to do is have it implement the new interface:

And we can use the interface type when declaring the DAO:

Wait a minute. We still have InMemoryBookDao in the line of code that instantiates the DAO. It is a bit like writing Collection c = new ArrayList();. It just so happens to be an ArrayList right now, but we could change it at any time. It is a bit like signifying that the surrounding code shouldn’t get too cozy with any particular implementation. We can always change the specific DAO implementation later without changing the interface. And we will learn in the next section how to get rid of even the one reference to InMemoryBookDao.

To review the classes involved in the DAO pattern, we have the following illustration:

Now we have three objects, each responsible for one thing. We have the public interface BookDao, which specifies the contract. Next, we have the implementation of that interface, InMemoryBookDao. Finally, we have the Book class itself, which focuses on the object state and any methods related to Book.

In addition to making the code easier to read, this pattern makes it easy for us to organize code. We could put all the JavaBeans in one package, the interfaces in another package, and the implementations in still another package. This approach allows us to have one package for in-memory implementations and another for JDBC implementations.

Benefits

To review, the benefits of the DAO pattern are as follows:

The main object (Book in this case) is cohesive and doesn’t have database code cluttering it up.

All the database code is in one part of the program, making it easy to find.

We can change the database implementation without changing the business object.

Reuse is easier. As the database code grows, we can create helper classes and even helper superclasses.

CERTIFICATION OBJECTIVES

Factory Design Pattern (OCP Objective 3.7)

3.7 Design and create objects using a factory and use factories from the API.

Like the singleton design pattern, the factory design pattern is a creational design pattern. Unlike the singleton, it doesn’t limit you to only having one copy of an object. The factory design pattern creates new objects of whatever implementation it chooses.

Problem

So far, we only have one implementation of our BookDAO called InMemoryBookDao. It isn’t very robust since it only stores objects in memory. We will need to create a version of it that uses JDBC or writes to a file or does something else where we can remember state. We want to be able to change the DAO implementation without having to change the caller code (Student). Remember coupling? This is loose coupling. Interfaces are part of loose coupling, but we want to go a step further.

Solution

The simplest factory we can write while still implementing the pattern is an abstract class and implementation with one method:

This is very simple. The Factory is an abstract class with one method. Its implementation simply returns an in-memory DAO. From Student’s point of view, this is all that exists—the Factory class and the BookDao interface. Note that Student no longer has the code new InMemoryBookDao.

In diagram form, here is how our classes fit together:

To review, Student only interacts with the two abstract classes Factory and BookDao. All implementation is in the concrete subclasses.

This setup frees us up to change the implementation of FactoryImpl without affecting the caller.

Let’s try an example to show how we can change the factory. Suppose we write a DAO implementation OracleBookDao that uses a real database. We might change FactoryImpl to:

Just like that—nothing changes in Student. Yet it starts using the real database implementation. This is good design. A change only needs to be made in one place.

You might be wondering why Factory is an abstract class rather than an interface. It is common with the factory method pattern to work “around” the creation logic, or at least recognize that it might happen later.

As an example here, we could decide that we want to include the test logic check in the superclass so any future subclasses use it:

In this case, the superclass Factory has all the common logic, and the subclass FactoryImpl merely creates the relevant object. Notice how the API createDao() hasn’t changed its signature at all despite our extensive changes to the method implementation. That is why we are using the factory pattern. So the caller Student isn’t affected by any changes to our factory and DAO.

There are three patterns with factory in their name:

Factory method This is the pattern we are talking about in this chapter and is on the exam.

Abstract factory This takes the factory method pattern a bit further and is used to create families of related classes.

Factory It’s debatable whether this is even a pattern. It’s not in the “Gang of Four” book. However, on the job, when developers say “factory,” they are often referring to a method like
public Foo createFoo() {return new Foo(); } rather than a full-fledged factory method pattern. The method may return Foo or SubclassOfFoo, but it doesn’t have the superclass/subclass relationship for the creator object that the factory method pattern has.

You might have noticed we didn’t say anything about making the DAO constructors private. In the singleton pattern, we needed to force callers to use getInstance() to prevent multiple copies. The factory pattern is merely a convenience. At times, it is a pretty big convenience. However, callers can still instantiate the DAO directly without breaking our logic, so we let them.

In fact, Oracle uses the factory pattern in the Java API in many places. When we learned how to create a DateFormat, we used DateFormat.getInstance(), DateFormat.getDateInstance(), and other similar factory methods. If you wanted more control over the format string, you could still write new SimpleDateFormat(“yyyy MM”). Oracle leaves the constructor available for when you need it.

Similarly, when we learned how to create a Calendar, we wrote Calendar.getInstance() or Calendar.getInstance(Locale). You will see many more examples of the factory pattern as you explore the Java API.

Benefits

Benefits of the factory design pattern include the following

The caller doesn’t change when the factory returns different subclasses. This is useful when the final implementation isn’t ready yet. For example, maybe the database isn’t yet available. It’s also useful when we want to use different implementations for unit testing and production code. For example, you want to write code that behaves the same way, regardless of what happens to be in the database.

Centralizes creation logic outside the calling class. This prevents duplication and makes the code more cohesive.

Allows for extra logic in the object creation process. For example, an object is time-consuming to create, and you want to reuse the same one each time.

CERTIFICATION SUMMARY