OO Principles-Patterns in Software Engineering-Lecture 6 Slides-Computer Engineering, Slides of Software Engineering

Download OO Principles-Patterns in Software Engineering-Lecture 6 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity! Patterns in Software Engineering Lecturer: Raman Ramsin Lecture 6 OO Principles as Patterns: GRASP Department of Computer Engineering 1 Sharif University of Technology Patterns in Software Engineering – Lecture 6 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should be able to add new features to our system without having to modify our set of preexisting classes. One of the tenets of OCP is to reduce the coupling between classes to the abstract level. Instead of creating relationships between two concrete classes , we create relationships between a concrete class and an abstract class or an interface. Department of Computer Engineering 2 Sharif University of Technology Patterns in Software Engineering – Lecture 6 Interface Segregation Principle (ISP) Many specific interfaces are better than a single, general interface . Any interface we define should be highly cohesive. Department of Computer Engineering 5 Sharif University of Technology Patterns in Software Engineering – Lecture 6 Composite Reuse Principle (CRP) Favor polymorphic composition of objects over inheritance. One of the most catastrophic mistakes that contribute to the demise of an object-oriented system is to use inheritance as the primary reuse mechanism. Delegation can be a better alternative to Inheritance. Department of Computer Engineering 6 Sharif University of Technology Patterns in Software Engineering – Lecture 6 Principle of Least Knowledge (PLK) For an operation O on a class C only operations on the , following objects should be called: itself, its parameters, objects it creates, or its contained instance objects. Also called the Law of Demeter. The basic idea is to avoid calling any methods on an object where the reference to that object is obtained by calling a method on another object (Transitive Visibility). The primary benefit is that the calling method doesn’t need to understand the structural makeup of the object it’s invoking methods upon. Department of Computer Engineering 7 Sharif University of Technology Patterns in Software Engineering – Lecture 6 GRASP: Information Expert As a general principle of assigning responsibilities to objects, assign a responsibility to the information expert: i.e. the class that has the information necessary to fulfill the responsibility. Department of Computer Engineering 10 Sharif University of Technology Patterns in Software Engineering – Lecture 6 GRASP: Creator Assign class B the responsibility to create an instance of class A if one or more of the following is true: B aggregates A objects. B contains A objects . B records instances of A objects. B closely uses A objects. B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A). B is a creator of A objects. If more than one option applies, prefer a class B which aggregates or contains class A Department of Computer Engineering 11 Sharif University of Technology . Patterns in Software Engineering – Lecture 6 GRASP: Low Coupling Assign a responsibility so that coupling remains low. A class with high (or strong) coupling relies on many h l h l b d blot er c asses. Suc c asses may e un esira e; some suffer from the following problems: Changes in related classes force local changes . Harder to understand in isolation. Harder to reuse because its use requires the additional presence of the classes on which it is dependent. Department of Computer Engineering 12 Sharif University of Technology Patterns in Software Engineering – Lecture 6 GRASP: Polymorphism When related alternatives or behaviors vary by type (class), assign responsibility for the behavior — using polymorphic operations to the types for which the — behavior varies. Define the behavior in a common base class or, preferably, in an interface. Department of Computer Engineering 15 Sharif University of Technology Patterns in Software Engineering – Lecture 6 GRASP: Indirection Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. The intermediary creates an indirection between the other components. Beware of transitive visibility. Department of Computer Engineering 16 Sharif University of Technology Patterns in Software Engineering – Lecture 6 GRASP: Pure Fabrication Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept — something made up, to s ppo t high cohesion lo co pling and e seu r , w u , r u . Example: a class that is solely responsible for saving objects in some kind of persistent storage medium, such as a relational database; call it the PersistentStorage. This class is a Pure Fabrication — a figment of the imagination. Department of Computer Engineering 17 Sharif University of Technology Patterns in Software Engineering – Lecture 6 Design by Contract (DBC): Assertions Simple assertions belong to individual statements in a program, yet important DBC assertions are defined on classes: Per- method assertions: Precondition: A condition that must be true of the parameters of a method and/or data members – if the method is to behave correctly – PRIOR to running the code in the method. Postcondition: A condition that is true AFTER running the code in a method. Per-class assertions: Class Invariant: A condition that is true BEFORE and AFTER running the code in a method (except constructors and destructors). Department of Computer Engineering 20 Sharif University of Technology Patterns in Software Engineering – Lecture 6 Design by Contract (DBC): Contract Assertions in a class specify a contract between its instances and their clients. According to the contract a server promises to return lt ti f i th t diti if li t tresu s sa s y ng e pos con ons a c en reques s available services and provides input data satisfying the preconditions. Invariants must be satisfied before and after each service. Neither party to the contract (the clients/consumers and servers/suppliers) shall be allowed to rely on something else than that which is explicitly stated in the contract. Department of Computer Engineering 21 Sharif University of Technology Patterns in Software Engineering – Lecture 6 Design by Contract (DBC): Inheritance The class invariants of all ancestors must also be obeyed by all children; they can also be strengthened. Inherited preconditions may only be weakened. This means a new implementation may never restrict the i t d hi h li t ll i lid b dc rcums ances un er w c a c en ca s va eyon what has been specified by the ancestor. It may, however, relax the rules and also accept calls that would have been rejected by the ancestor. Inherited postconditions may only be strengthened. This means a new implementation must fulfil what the ancestors have undertaken to do, but may deliver more. "Children should not provide less or expect more than th i t " Department of Computer Engineering 22 Sharif University of Technology e r ances ors.