software development - knox...

Object Oriented Design 1

Software Developmentand Professional Practice

Object-Oriented DesignPart the Third:

(in which we revisit several parts of the OOA&D process, culminating in some general design principles)

Intro to Development 2

Unless otherwise expressly stated, all original material of whatever nature created by John F. Dooley and included in this web site and any related pages, including the site's archives, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

A number of slides in this file contain figures and data from Head First Object-Oriented Analysis and Design, and are copyrighted by O’Reilly Media, Inc., 2007.

http://creativecommons.org/licenses/by-nc-sa/3.0/





Object-Oriented Design Principles

• Let’s review some general design principles that relate to pretty much all object-oriented designs….

Using proven OO design principles results in more maintainable, flexible, and extensible software.


Here’s a good list fromHFOOA&D (page 418)

We’ll talk about each onein turn.

(Look at Chapters, 3, 5, and 8 for these.)


OO Design Principle #1• Encapsulate what varies.

page 226


OO Design Principle #2

• Code to an interface rather than an implementation.

page 224

Object Oriented Design

Interface?

9


OO Design Principle #3• Each class in the implementation should have only

one reason to change.• meaning that you have high cohesion - the class

does one thing and everything in the class is related to that one thing.

• we’ll come back to this in a couple of principles

page 269



• Classes are about behavior and functionality.

• The reason you usually create a subclass is because the behavior of the subclass is different than the superclass.

page 241


Design Principle # 4.5

• Make your classes cohesive

• A cohesive class does one thing really well and does not try to do or be something else.

• The more cohesive each class is, the more cohesive the entire application is.

16


Summary of the first four principles + 1

• Well-designed software is easy to change and extend.

• Use basic OO principles like encapsulation and inheritance to make your design more flexible.

• Make each of your classes cohesive: each of your classes should focus on doing one thing really well.

• Always strive for higher cohesion .

17


OO Design Principle #5• The Open-Closed Principle

• Classes should be open for extension, but closed for modification.

page 377

The OCP is all about allowing change, but doing it without requiring you to modify existing code.


The OC(P)

19

InstrumentSpec is closed to modification but open to extension.



• The Don’t Repeat Yourself (DRY) Principle:

• Avoid duplicate code by abstracting out things that are common and placing them in a single location.

1. Abstract out the common code either into a separate method, or a separate class.

2. remove the code from other locations, and at the same time

3. replace it with the new method calls.

page 382


DRY is about having each piece of information and behavior in your system in a single, sensible place.

Dry is really about ONE requirement in ONE place.

21


How DRY I am...• DRY is about

• having one place where a requirement is implemented

• removing duplicate code into a single class

• making sure that that single class is the right place for it to be so that changes are easy and the place to make them obvious.

• so really, DRY applies to your requirements, architecture and design as well as your code - you want the system to be organized so that “there’s a place for everything and everything in it’s place.”

22


OO Design Principle #7• The Single Responsibility Principle (SRP):

• Every object in your system should have a single responsibility, and all the object’s services should be focused on carrying out that single responsibility.

page 390What other word does SRP remind you of?

You’ve implemented the Single Responsibility Principle correctly when each of your objects has only one reason to change.


So what the heck does this mean???

• Try this• Take a class diagram• Then for each method in the

class, write down

The Automobile ___________ itself.

24


• Does each line make sense?

• If not, maybe you need another class (or 4).

25


So that each class is responsible for a single behavior



• The Liskov Substitution Principle (LSP):• Subclasses must be substitutable for their base classes.

• (That is, this is about doing inheritance right; you must be able to substitute your subclass for the super class without things going horribly wrong.)

page 400

The LSP is all about well-designed inheritance. When you inherit from a super class, you must be able to substitute your sub-class for that super class without things going wrong.

Otherwise, you’ve used inheritance incorrectly!


An LSP Example

28

Say we’re designing a game board and we want to extend it to a 3-D board. (see HFOOA&D, Chapter 7.)

Is there anything wrong with the Board class that will complicate extending it to a 3-D representation?


What’s a Programmer to do?

29


LSP means not abusing inheritance

• In this example, the 3DBoard class can’t be substituted for the Board class

• So what do we do?

• What options are there besides inheritance?

30


Delegate!

• When you delegate responsibility to another class, you often create an association between the two classes.

• Association means that the classes are related to each other, often through an attribute, or a set of related methods. That’s what we’ll have.

31


So instead of using inheritance to extend the Board class, we’ll create a new 3DBoard class and delegate some of the responsiblities to the Board class via association.

In this case, we’re making a 3D Board as a collection of 2D Boards, letting the z-coordinate choose which 2D board to use.

32


Delegation is your friend...

• Yes, but association isn’t the only way to enforce the substitution principle....

33


It’s not?

• In the previous example, the 3DBoard class always uses instances of the Board class to do its work, and the behavior of the Board methods always stays the same. • That’s what delegation is all about.

• But, sometimes we want to have more than one behavior to choose from.

34


Compose your way to happiness...

• Say we’re continuing to design our board game...

• We’ve got Units (army guys, airplanes, etc), and

• Weapons that the Units will carry and use...(weapons are properties)

35


Composition• BUT

• Units can change weapons

• so we don’t want to be stuck with a single weapon type for a unit instance

• we want to be able to change weapons - i.e. to be able to choose between the available weapon types (sword, gun, club, mace, .50 cal, laser, phaser, Teddy Bear, etc)

• so we want our Units to be able to reference a whole family of behaviors - that’s composition!

36


Oh, and one more thing...

38


• In composition, the object composed of other behaviors owns those behaviors. When the object is destroyed, so are all of its behaviors.

• The behaviors in a composition do not exist outside of the composition itself.

39


Yes, but what if I want them to stick around?

• Well, then you can’t use composition!• Rats!

• What to use instead???

40


Aggregation: composition without the abrupt ending

41


So, to sum up...

44


So, back to the LSP...

• What do delegation, composition, and aggregation have to do with the LSP?

• The LSP is about when to create a subclass• when your subclass can substitute for the superclass.• it’s about well-mannered inheritance.

• delegation, composition, and aggregation are about what to do instead of using inheritance.

45


References• Sommerville, Ian, Software Engineering, 6th ed.,

Addision-Wesley, 2000, (Chapter 12).• McConnell, S., Code Complete, 2nd edition, Microsoft

Press, 2004, (Chapter 6).• Fowler, M., UML Distilled, 2nd edition, Addison-

Wesley, 2000, (Chapters 1 through 5).• Alhir, S., UML in a Nutshell, O’Reilly & Associates,

Inc., 1998, (Chapter 4) (but really not a good book).• and, of course McLaughlin, et. al. Head First OOA&D.

software development - knox...

Documents