Chapter 7

1. Chapter 7 Designing Classes

2. 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

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

4. 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).

5. 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.

6. Code quality • Two important concepts for quality of code: • Coupling • 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.

7. 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.

8. 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

9. 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.

10. 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.

11. 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

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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

19. 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

20. 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 )

21. 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()

22. 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.