Software Development

Transcription

1 Software Development and Professional Practice Object-Oriented Design Part the Third: (in which we revisit several parts of the OOA&D process, culminating in some general design principles) Object Oriented Design 1

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., Intro to Development 2

3 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. Object Oriented Design 3

4 Here s a good list from HFOOA&D (page 418) We ll talk about each one in turn. (Look at Chapters, 3, 5, and 8 for these.) Object Oriented Design 4

5 OO Design Principle #1 Encapsulate what varies. page 226 Object Oriented Design 5

6 Object Oriented Design 6

7 Object Oriented Design 7

8 OO Design Principle #2 Code to an interface rather than an implementation. page 224 Object Oriented Design 8

9 Interface? Object Oriented Design 9

10 Object Oriented Design 10

11 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 Object Oriented Design 11

12 Object Oriented Design 12

13 OO Design Principle #4 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 Object Oriented Design 13

14 Object Oriented Design 14

15 Object Oriented Design 15

16 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. Object Oriented Design 16

17 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. Object Oriented Design 17

18 OO Design Principle #5 The Open-Closed Principle Classes should be open for extension, but closed for modification. The OCP is all about allowing change, but doing it without requiring you to modify existing code. page 377 Object Oriented Design 18

19 The OC(P) InstrumentSpec is closed to modification but open to extension. Object Oriented Design 19

20 OO Design Principle #6 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 Object Oriented Design 20

21 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. Object Oriented Design 21

22 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. Object Oriented Design 22

23 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. You ve implemented the Single Responsibility Principle correctly when each of your objects has only one reason to change. page 390 What other word does SRP remind you of? Object Oriented Design 23

24 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. Object Oriented Design 24

25 Does each line make sense? If not, maybe you need another class (or 4). Object Oriented Design 25

26 So that each class is responsible for a single behavior Object Oriented Design 26

27 OO Design Principle #8 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.) 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! page 400 Object Oriented Design 27

28 An LSP Example 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? Object Oriented Design 28

29 What s a Programmer to do? Object Oriented Design 29

30 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? Object Oriented Design 30

31 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. Object Oriented Design 31

32 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. Object Oriented Design 32

33 Delegation is your friend... Yes, but association isn t the only way to enforce the substitution principle... Object Oriented Design 33

34 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. Object Oriented Design 34

35 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) Object Oriented Design 35

36 BUT Composition 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! Object Oriented Design 36

37 Object Oriented Design 37

38 Oh, and one more thing... Object Oriented Design 38

39 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. Object Oriented Design 39

40 Yes, but what if I want them to stick around? Well, then you can t use composition! Rats! What to use instead??? Object Oriented Design 40

41 Aggregation: composition without the abrupt ending Object Oriented Design 41

42 Object Oriented Design 42

43 Object Oriented Design 43

44 So, to sum up... Object Oriented Design 44

45 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. Object Oriented Design 45

46 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. Object Oriented Design 46