CS 350 – Software Design Expanding Our Horizons – Chapter 8 The traditional view of objects is that they are data with methods. Sometimes objects could be referred to as “Smart Data.” Indeed, when I learned objects, this is how I thought of them. However, it is better to think of them as “entities that have responsibilities.” This helps us focus on what objects are supposed to do. By focusing on what an object is supposed to do, you can hide the implementation details. This causes us to focus on an object’s public interface. If you focus on the public interface, then you do not need to know what is going on inside the object. This enables you to delegate responsibility.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Think about the Shape example. What responsibilities does a Shape have? To know where it is located. To know where it is located. To be able to draw itself on a display. To be able to draw itself on a display. To be able to remove itself from a display. To be able to remove itself from a display. This implies three methods: getLocation(…) getLocation(…) drawShape(…) drawShape(…) unDrawShape(…) unDrawShape(…) We do not need to know anything about the inner workings of the Shape class. Shape could contain attributes or another object. We do not care.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Hiding the implementation of Shape behind interfaces essentially decouples them from the using objects. Decoupling is the key to good design. It means that if something changes on the other side of the interface, the non-changed side should not require alteration.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Most of us learned encapsulation as data hiding. Before we improve that definition (ok, we already did earlier), here’s a nice little story. Many have accused me of being a tech gadget nut. So let me tell you about my cool umbrella. It is large enough to get into! In fact I have fit three or four people in it. While we are in there, staying out of the rain, I can even move from one place to the other. Of course, it has a stereo system to keep me entertained while I stay dry. It even has an air conditioner and heater. This is one cool umbrella. It was not cheap. An additional feature is my umbrella will even wait for me. It also has wheels so I do not have to carry it around. It even has a motor to self propel it.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Actually many people have umbrellas like this. It’s called a car. Of course a car isn’t an umbrella, but it does serve the purpose of one. The view that an car is an umbrella, may not be wrong, but it is a very limited view of a car. Long story to say, encapsulation isn’t just data hiding. Encapsulation is any kind of hiding. You can hide: Implementations Implementations Derived Classes Derived Classes Design Details Design Details Instantiation Rules Instantiation Rules

CS 350 – Software Design Expanding Our Horizons – Chapter 8 The Adapter pattern example shows many kinds of encapsulation. Can you name them?

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Encapsulating data Encapsulating data Encapsulating methods Encapsulating methods Encapsulating other objects Encapsulating other objects Encapsulating shapes Encapsulating shapes

CS 350 – Software Design Expanding Our Horizons – Chapter 8 In this case encapsulation is achieved with the use of an abstract class and derivations. We make use of polymorphism. By encapsulating shapes, I can add new ones without changing the client program. Early promoters of OOP touted reuse of classes as being one of its big benefits. This reuse was usually achieved by creating classes and then deriving new classes based on these base classes. The sub classes were called specialized classes. This is a fair way of developing, but leads to issues.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Imagine you have a class called Pentagon to contain state, draw, undraw, and so on. Later you decide you also want a special Pentagon with a special border. The traditional approach would be to create a Pentagon with a special border class that is derived from Pentagon.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 This approach has a lot of problems. Some will become more obvious as we progress. Weak Cohesion: What happens if we have lots of borders? If each border is a separate class then related code is being divided up. Reduces reuse: What happens if I want to reuse the special border for other shapes? This solution does not allow that to occur. Doesn’t scale well: What happens if other things vary? Combinatoric explosion!

CS 350 – Software Design Expanding Our Horizons – Chapter 8 A better solution is to use inheritance to classify classes as things that behave the same way. Consider what should be variable in your design (not always easy) and encapsulate it. Many design patterns use encapsulation to create layers between objects. This enables the designed to change things on different sides of the layer without adversely affecting the other side. This promotes loose coupling between the sides.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Consider the traditional problem of creating classes that represent animals. Your requirements are: Each type of animal can have a different number of legs Each type of animal can have a different number of legs Animal objects must be able to remember and retrieve this information Animal objects must be able to remember and retrieve this information Each type of animal can have a different type of movement Each type of animal can have a different type of movement Animal objects must be able to move from place to place given a specified type of terrain Animal objects must be able to move from place to place given a specified type of terrain A typical approach to the number of legs is to have a data member containing this value and methods to set and get it. However, not all animals travel the same way. Some walk, some fly. Could a single variable capture this? Not likely. How about having two types of animals, both derived from the animal class. This is the traditional approach. You start with animal, then have mammals, reptiles, etc. and keep creating more and more specific animals till you have all species. This leads to a huge tree which does not promote reuse.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 The problem is exacerbated when many variations are present. It is better to have a data member that indicates the type of movement the object has.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 This should be nothing new. In true object-oriented languages, everything is an object. So having objects contain objects is nothing new.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Is Agile and Design Patterns the same? Design patterns use a “design up front” approach. Agile methods, like eXtreme programming, focuses on doing things in small steps and validating as you move forward. Agile programming requires code that is changeable, and patterns result in code that is flexible. So maybe it’s not that different. I do not necessarily agree with this. I think there are similarities, but differences as well. Agile often means that you start programming without knowing the complete requirements. This has little to do with using design patterns.

CS 350 – Software Design Expanding Our Horizons – Chapter 8 Good Rules for Good Design No Redundancy: Have only one place where a rule is implemented. Readability: If your code is understandable, quality improves as does cohesion. Testability: Your code should be testable.