Introduction to Object Oriented Programming. (Hebrew University, CS / Spring 2012 )

Transcription

1 Introduction to Object Oriented Programming (Hebrew University, CS / Spring 2012 )

2 Overview There are many important Object Oriented Design (OOD) principles Today we'll focus on several basic principles closely related to design-patterns: Modularity The Open-Closed principle The Single-Choice principle Program to an interface and not an implementation Reuse mechanisms: Class Inheritance vs. Object Composition OOP Lecture cs huji

3 Modularity A Modular design results in a software that can be broken down to several individual units, denoted modules Modularity is a desired property of software design Modular programs have several benefits Easy to maintain (debug, update) Allow breaking a complex problem into easier sub-problems Allow to easily divide the project into several team members or groups OOP Lecture cs huji

4 Modularity A design method which is modular should satisfy 5 fundamental requirements: Decomposability Composability Understandability Continuity Protection OOP Lecture cs huji

5 Decomposability Decomposability A software construction method satisfies Modular Decomposability if it: Decomposes a software problem into a small number of less complex sub-problems These sub-problems are connected by a simple structure, and independent enough to allow further work to proceed separately on each of them OOP Lecture cs huji

6 Decomposability A corollary of decomposability is division of labor A decomposed system is easier to distribute among different people or groups A good example: Top-Down Design A typical counter-example: a software system that includes a global initialization module (why?) OOP Lecture cs huji

7 Composability Composability A method satisfies Modular Composability if it produces software elements which may be freely combined with each other to produce new systems Possibly in an environment quite different from the one in which they were initially developed OOP Lecture cs huji

8 Composability Elements should be sufficiently autonomous Composability is directly connected with the goal of reusability Design software elements performing well-defined tasks and usable in widely different contexts Examples: Software libraries (or packages) OOP Lecture cs huji

9 Composability Vs. Decomposability Composability and decomposability are independent. In fact, these criteria are often at odds Top-down design, for example, which we saw as a technique favoring decomposability, tends to produce modules that are not easy to combine with modules coming from other sources OOP Lecture cs huji

10 Understandability Understandability A software design favors Modular Understandability if it produces software in which a human reader can understand each module without having to know anything about the others At worst, by having to examine only a few of the others The importance of this criterion follows from its influence on the maintenance process This is not the same as readability OOP Lecture cs huji

11 Modular Continuity Continuity A method satisfies Modular Continuity if, in the software architectures that it yields, a small change in a problem specification will trigger a change in just one module, or a small number of modules The term continuity is drawn from an analogy with the notion of a continuous function in mathematical analysis OOP Lecture cs huji

12 Modular Protection Modular Protection A method satisfies Modular Protection if the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst only propagate to a few neighboring modules The underlying issue, that of failures and runtime errors, is central to software engineering The criterion does not address the avoidance or correction of errors, but the aspect that is directly relevant to modularity: their propagation i.e. Exception handling OOP Lecture cs huji

13 The Open-Closed principle Software Entities (Classes, Modules, Functions, etc.) should be open for extension but closed for modification (Meyer, 1988) A single change to a program a cascade of changes to dependent modules bad design The program becomes fragile, rigid and un-reusable Violation of the Continuity principle The open-closed principle attacks this by stating that you should design modules that never change Requirements change extend the modules by adding new code, not by changing old code that already works! OOP Lecture cs huji

14 The Open-Closed principle Modules that conform to the open-closed principle have two primary attributes: They are Open for Extension : the behavior of the module can be extended; we can make the module behave in new and different ways as the requirements of the application change They are Closed for Modification : the source code of such a module is inviolate. No one is allowed to change it OOP Lecture cs huji

15 The Open-Closed principle Shape example We have an application that must be able to draw circles and squares on a standard GUI The circles and squares are drawn in a particular order The program traverses and draws a list of circles and squares in a given order Possible solutions: Procedural solution define a class for each type and use it when drawing OOP solution using an abstract class shape OOP Lecture cs huji

16 Shape Example Procedural Solution void drawallshapes(shape[] list) { for (int i=0; i<list.length; i++) { Shape s = list[i]; int type = gettype(s); switch (type){ case SQUARE: drawsquare((square)s); break; case CIRCLE: drawcircle((circle)s); break; } } } OOP Lecture cs huji

17 Procedural Solution What's Wrong Here? The function drawallshapes() does not conform to the open-close principle since it is not closed against new kinds of shapes If we wanted to extend this function to draw a list of shapes that included triangles, we would have to modify it This program is only a simple example The switch statement in drawallshapes() could be repeated over and over again in various functions, each one doing something a little different Adding a new shape means hunting for every such switch statement and adding the new shape OOP Lecture cs huji

18 public class Shape { } The Shape Example OOP Solution public abstract void draw(); public class Square extends Shape { } public void draw(){..} public class Circle extends Shape { } public void draw(){..} void DrawAllShapes(Shape[] list) { } for (Shape currshape : list) currshape.draw(); OOP Lecture cs huji

19 OOP Solution Advantages Extending the behavior of the drawallshapes() function to draw a new kind of shape, is done by adding a new derivative of the Shape class drawallshapes() does not need to change drawallshapes() conforms to the open-closed principle. Its behavior can be extended without modifying it OOP Lecture cs huji

20 The Open-Closed Principle Related Concepts Make all Member Variables Private (Encapsulation) A program s public methods (it s API) rarely changes In contrast, members are considered part of the internal structure Changing them is considered a legitimate change in the software When the members of a class change, every method that depends upon those variables must be changed No function that depends upon a variable can be closed with respect to that variable Instead of forcing one method to change, we are forcing multiple methods Alternatives to using public members are usually inexpensive OOP Lecture cs huji

21 The Open-Closed Principle Related Concepts Run-Time Type Information (RTTI) is Dangerous Another very common proscription is the one against dynamic casts using, for example, the instanceof operator OOP Lecture cs huji

22 The Single-Choice Principle Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list By doing this, we prepare the scene for later changes: If variants are added, we will only have to update the module which has the information the point of single choice All others, in particular its clients, will be able to continue their business as usual This principle interacts with the open-closed principle: if we must have some exhaustive list of our options, keep it in one place, so that this is the only place the needs to be changed upon updates OOP Lecture cs huji

23 The Shape Example OOP Solution Shape[] loadallshapes(string[] list) { } Shape[] shapes = new Shape[list.length]; for (int i = 0 ; i < list.length ; ++i) { } if (list[i].equals( Square )) { shapes[i] = new Square(); } else if (list[i].equals( Circle )) { } return shapes; shapes[i] = new Circle(); One method must know all the options. It cannot be closed for changes OOP Lecture cs huji

24 The Shape Example OOP Solution void drawallshapes(shape[] list) { } for (Shape currshape : list) currshape.draw(); void deleteallshapes(shape[] list) { for (Shape currshape : list) currshape.delete(); }. All other methods don t need to know the options. They are closed to changes OOP Lecture cs huji

25 Program to an Interface and not an Implementation Using inheritance or interfaces allows us to define a family of classes which share their API Clients remain unaware of the specific type of objects they use Allows to replace implementation details without affecting the clients This greatly reduces implementation dependencies between subsystems OOP Lecture cs huji

26 Reuse Mechanisms Inheritance vs. Composition What is the right way to build reusable software? The two most common techniques for reusing functionality are inheritance and object composition (class) Inheritance Define an implementation of one class in terms of another's Called white-box reuse since the internals of the parent are visible to its subclasses OOP Lecture cs huji

27 Reuse Mechanisms Inheritance public class B { } protected void foo() { } public class A extends B { } Now, A got the foo() method for free and can use it OOP Lecture cs huji

28 Reuse Mechanisms Inheritance vs. Composition Object Composition An alternative to class inheritance New functionality is obtained by assembling (or composing) objects to get more complex functionality Requires that objects being composed have well defined interfaces Called black-box reuse because no internal details of objects are visible. Objects appear only as black boxes OOP Lecture cs huji

29 Reuse Mechanisms Composition public class B { } public void foo() { } public class A { private B b; } public A(B b) { } this.b = b; Now, A can use the foo() code by calling b.foo() OOP Lecture cs huji

30 Inheritance Pros of inheritance: Straightforward to use (supported by the programming language): enables polymorphism Defined statically at compile time Easier to modify the implementation being reused by overriding Cons of inheritance: An implementation cannot be changed at runtime Breaks encapsulation a subclass is exposed to details of the parent's implementation (protected members/methods) Subclass implementation is bound to parent implementation Any change in the parent forces the subclass to change A class can only extend a single parent-class OOP Lecture cs huji

31 Object Composition Pros of object composition: Defined dynamically at runtime Encapsulation is not broken and therefore any object can be replaced at runtime by another as long as it has the same type Substantially fewer implementation dependencies Helps keep each class encapsulated and focused on one task A class may compose as many objects as it wants Cons of object composition: A composition based design has more objects (if fewer classes) No support for polymorphism The system's behavior will depend on their interrelationships instead of being defined in one class OOP Lecture cs huji

32 Reuse Mechanisms Inheritance vs. Composition Use inheritance when: A is inherently a B A dog is an animal Use object composition when: You mainly want to reuse code When it makes more sense to extend A by another class C If you only need polymorphism (but an A is not a B), use object composition + interfaces Inheritance and object composition work together OOP Lecture cs huji

33 So far Among most important OOP design principles Modularity Open-closed Single-choice Program to an interface and not an implementation Class Inheritance vs. Object Composition OOP Lecture cs huji

34 Design Patterns Properties Reminder Describes a proven approach to dealing with a common situation in programming/design Suggests what to do to obtain an elegant, modifiable, extensible, flexible & reusable module Shows, at design time, how to avoid problems that may occur much later Is independent of specific contexts or languages OOP Lecture cs huji

35 Design Patterns Types The different design patterns can be (roughly) divided into 3 different categories Creational patterns These patterns deal with creating objects (instantiation) For example: Factory Structural patterns These patterns deal with the objects structure (composition) For example: Decorator Behavioral patterns These pattern handle the objects behavior (communication between objects) For example: Iterator OOP Lecture cs huji

36 Delegation Delegation is a way of making composition as powerful for reuse as inheritance In delegation, two objects are involved in handling a request: a receiving object delegates operations to its delegate This is analogous to subclasses deferring requests to parent classes (how?) A structural pattern OOP Lecture cs huji

37 Delegation public class B { } public void foo() { } public class A { private B b; public A(B b) { this.b = b; } public void foo() { b.foo(); } A delegates its foo() requests to b A can also perform additional actions in foo() } OOP Lecture cs huji

38 Delegation Question: Should Window be a Rectangle or have a Rectangle? Answer: It should have a rectangle The window class might reuse the behavior of Rectangle, by keeping a Rectangle instance variable and delegating Rectangle-specific behavior to it OOP Lecture cs huji

39 Delegation Main advantage easy to compose behaviors at runtime and to change the way they are composed Example: easy to make the window circular, by replacing the Rectangle instance with a Circle instance Disadvantages: Dynamic, highly parameterized software is harder to understand than static software (like composition in general) Some runtime inefficiencies In summary: a good design choice when it simplifies more than it complicates! OOP Lecture cs huji

40 Decorator Design Pattern Reminder In order to enhance functionality of class A (InputStream): Build class B (BufferedInputStream) that Extends A (shares its API) Composes an object of type A Constructor of B receives an object of type A and remembers it B forwards all requests (= delegates) to the A component and may perform additional actions before or after forwarding Is not a data source by itself, but uses A as a data source The transparency allows the decorators to be nested recursively, thereby allowing an unlimited number combinations! OOP Lecture cs huji

41 To Summarize Let A,B be 2 classes A Composes B if A holds an instance of B (as a member or a local variable) A Delegates B if A composes B and forwards requests to the composed instance (of type B) s methods A Decorates B if A delegates B and extends B OOP Lecture cs huji

42 The Strategy Pattern Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it A behavioral pattern OOP Lecture cs huji

43 Strategy Pattern Applicability Use the Strategy pattern whenever: There exist different variants of an algorithm An algorithm uses data that clients shouldn't know about. Use this pattern to avoid exposing complex, algorithmspecific data structures A class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class Relates to the single-choice principal OOP Lecture cs huji

44 Strategy Example A class wants to decide at run-time what algorithm it should use to sort an array. Many different sort algorithms are already available Solution: Encapsulate the different sort algorithms using the Strategy pattern! class SomeCollection { } private Comparable[] _contents; private SortStrategy _sorter; public void sortcontents() { } _sorter.sort(_contents);. interface SortStrategy { void sort(comparable[] a) ; } class Quicksort implements SortStrategy { public void sort(comparable[] a) { } } OOP Lecture cs huji

45 Pros and Cons of Strategy Pros Provides an alternative to subclassing the main class to get a variety of algorithms or behaviors Eliminates large conditional statements Provides a choice of implementations for the same behavior Cons Increases the number of objects Each algorithm must use the same Strategy interface OOP Lecture cs huji

46 Factory Patterns A factory is an object used to create other objects A factory has methods for creating the objects it supports These methods may receive parameters which define the type and properties of the created object Factories are used in situations where deciding which object to create is a complex task The factory may create the object dynamically, return it from some object pool, do complex initialization, etc. Many creational design patterns implement this concept OOP Lecture cs huji

47 The Singleton Pattern Intent Ensure a class only has exactly one instance, and provide a global point of access to it Motivation If we want a single instance of a class to exist in the system We want just one window manager, or just one factory for a family of products We need to have that one instance easily accessible Additional instances of the class cannot be created A creational pattern, which implements the factory concept OOP Lecture cs huji

48 Implementing Singletons Use a static variable to the single instance of the class Make the constructor private Instance creation is done using the static instance() method This method always returns a reference to the same single static object This way only one instance at most is created OOP Lecture cs huji

49 Implementing Singletons class Singleton { private static Singleton single = null; private Singleton () { } public static Singleton instance() { if (single==null) { single = new Singleton(); } } } return single; OOP Lecture cs huji

50 Singleton and Subclassing Using a single private constructor makes it impossible to subclass This isn t such a big problem, as in many cases subclassing singletons is not a good idea In order to allow inheritance, make the constructor protected But then clients who extend the class can create many instances, which breaks the pattern OOP Lecture cs huji

51 So far A few new design patterns Delegation Decorator Strategy The Factory concept Singleton OOP Lecture cs huji

52 Ex3 Input Example a############################ #############_############## ############# ############# #_########### ############ #_########### ########### #_######### ########## # ##### # ####### # ## # ##### # # #### # # # ### # # ### ### # # ## # # ## # # ## # # ### # # ### # # #### # # # ##### # #### ######## # ######## ########## #_############ ############ #_############_############# absolutist:one who advocates absolutism absolver:someone who grants absolution absorbency:the property of being absorbent absorption:the mental state of being preoccupied by something abstemiousness:moderation in eating and drinking abstention:the trait of abstaining (especially from alcohol) abuja:capital of Nigeria in the center of the country abulia:a loss of will power academe:the academic world academia:the academic world academic:an educator who works at a college or university acarina:mites and ticks acarine:mite or tick acariosis:infestation with itch mites acaryote:a cell without a nucleus (as an erythrocyte) acceleration:(physics) a rate of change of velocity acceptation:acceptance as true or valid accessory:a supplementary component acetyl:the organic group of acetic acid (CH3CO-) OOP Lecture cs huji

53 Ex3 Output Example OOP Lecture cs huji

54 Ex3 goals Working with supplied code & inter faces, including generics code [lecture 5] Implementing DFS (depth-first search) [DAST lectures] Working with java collections including Hash & Tree implementations [lecture 6] Using design patterns: you are advised to use the Strategy pattern [lecture 7] OOP Lecture cs huji