Certification Objective Coupling and Cohesion (Exam Objective 5.1)

Certification Objective —Coupling and Cohesion (Exam Objective 5.1)

5. 1 Develop code that implements tight encapsulation, loose coupling, and high cohesion in classes, and describe the benefits.

We're going to admit it up front. The Sun 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 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 making an attempt at a definition of 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 non-interface 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, which has been enabled by poor encapsulation:

 class DoTaxes {   float rate;   float doColorado() {     SalesTaxRates str = new SalesTaxRates();     rate = str.salesRate;     // ouch                               // this should be a method call:                               // rate = str.getSalesRate("CO");     // do stuff with rate   } } class SalesTaxRates {   public float salesRate;            // should be private   public float adjustedSalesRate;    // should be private   public float getSalesRate(String region) {     salesRate = new DoTaxes().doColorado();    // ouch again!     // do region-based calculations     return adjustedSalesRate;   } } 

All non-trivial 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 earlier in this chapter, 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 take a look at a pseudo-code example:

 class BudgetReport {   void connectToRDBMS(){ }   void generateBudgetReport() { }   void saveToFile() { }   void print() { } } 

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:

 class BudgetReport {   Options getReportingOptions() { }   void generateBudgetReport(Options o) { } } class ConnectToRDBMS {   DBconnection getRDBMS() { } } class PrintStuff {   PrintOptions getPrintOptions() { } } class FileSaver {   SaveOptions getFileSaveOptions() { } } 

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've already got 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.