Chapter 7 Designing Classes

Class Design When we are developing a piece of software, we want to design the software We don’t want to just sit down and bang on the keyboard for a while We want to think about what we are going to be writing first and then type

What should we be thinking about? There are 3 main things we should think about 1.Code Quality 2.Responsibility-driven design 3.Refactoring

Software changes Software is not like a novel that is written once and then remains unchanged. Software is extended, corrected, maintained, ported, adapted… The work is done by different people over time (often decades).

Change or die There are only two options for software: –Either it is continuously maintained –or it dies. Software that cannot be maintained will be thrown away.

Code quality Two important concepts for quality of code: 1.Coupling 2.Cohesion These are related topics, but different ideas and sometime difficult to grasp. Code duplication is a third minor concept for code quality. If you have good coupling and cohesion, code duplication will be less of an issue.

Coupling Coupling describes the interconnectedness of classes We strive for loose coupling Each class should be largely independent of the other classes in the system Communication should be done through a well defined interface.

Cohesion Cohesion refers to how well a unit of code maps to a logical task. Each unit of code (method, class or module) is responsible for a well- defined task. There are two main types of cohesion –Method –Class

Method Cohesion Method cohesion refers to how well does a method do its job. In general, each method should do one thing and do it well. You can build up bigger methods from smaller ones.

Class Cohesion How well does a class do its job. Each class should focus on one idea and do it well. Classes should represent one noun from the project scope. For example, a CD class can be used to store tracks, as do real CDs You shouldn’t try to make a CD into a Frisbee. It’s not what it was designed to do and it doesn’t do it very well.

Code Duplication Code duplication is an indicator of bad design The problem is that any change to one piece of code requires changes to all places where that code is located It is easy to forget to change all the locations Worse yet, if you are working on someone else’s code, you may not know that the code duplication exists

Responsibility-Driven Design Responsibility-driven design expresses the idea that each class should be responsible for handling its own data. We can use this notion to determine which classes should implement a piece of functionality. If a class has the information necessary to process something, then it should do so. We can use this idea to decide where to put a method.

Refactoring When classes are maintained, often code is added. Classes and methods tend to become longer. Every now and then, classes and methods should be refactored to maintain cohesion and low coupling.

Refactoring and testing When refactoring code, separate the refactoring from making other changes. First do the refactoring only, without changing the functionality. Test before and after refactoring to ensure that nothing was broken.

Design questions Common questions: How long should a class be? How long should a method be? Can now be answered in terms of cohesion and coupling.

Design guidelines A method is too long if it does more then one logical task. A class is too complex if it represents more than one logical entity. Note: these are guidelines - they still leave much open to the designer.

Making Extensions How well or poorly designed a class is, is sometimes very evident when you want to make extensions to a class. The question often comes up, how extensible is a class? A class that can be extended easily, was probably designed with care. A class that cannot be extended easily, may have been designed quickly, with little thought to how it might be extended.

Encapsulation Encapsulation is a major idea behind OOP Encapsulation suggests that only information about what a class can do should be visible to the outside How it does what it does should be hidden from the user of the object This is why we want to have our fields be private instead of public

Executing without BlueJ So far all we have done is write classes that can de run inside of BlueJ You might write a program one day that you want other people to be able to use In order to do that, you need to learn about class methods

Class Methods A class method is a method that can be run without an instance of the class Every Java program will have at least one class method, the main method public static void main( String[ ] Args )

Class Methods Any method that is declared to be static is a class method This will allow you to call a method without have an object around We saw one of these the other day: Math.abs() Also, System.out.println()

Limitations to Class Methods Since you don’t have an object around, static methods cannot use any variable that is not also declared to be static Also a static method may not call any other method that is not declared to be static.