Good ObjectOriented Design Principles of Good Design Lecture

Good Object-Oriented Design Principles of Good Design Lecture 1 Dr. Radu Marinescu 1

Good Object-Oriented Design From Journeyman to Master Pieces, Moves How to Play? Lecture 1 Criteria, Principles, Heuristics What is Good? Dr. Radu Marinescu Contextual Solutions How to Apply "Good"? 2

Good Object-Oriented Design Stages of Learning § Learn the Rules! 4 algorithms, data structures and languages of software 4 write programs, although not always good ones § Learn the Principles! 4 software design, programming paradigms with pros and cons 4 importance of cohesion, coupling, information hiding, dependency management § Learn the Patterns! 4 study the "design of masters" 4 Understand! Memorize! Apply! Lecture 1 Dr. Radu Marinescu 3

Good Object-Oriented Design Citing Robert Martin. . . ". . . But to truly master software design, one must study the designs of other masters. Deep within those designs are patterns that can be used in other designs. Those patterns must be understood, memorized, and applied repeatedly until they become second nature. " Lecture 1 Dr. Radu Marinescu 4

Good Object-Oriented Design Where Do We Stand ? § We know the Rules 4 1 -2 OO programming language (Java, C++) 4 some experience in writing programs (< 10 KLOC) § We heard about Principles 4 "Open-Closed"; "Liskov Substitution Principle" etc. 4 randomly applied some of them § We dream of becoming "design masters" but. . . § …we believe that writing good software is somehow "magic" 4 exclusively tailored for geniuses, "artists", gurus ; -) Lecture 1 Dr. Radu Marinescu 5

Good Object-Oriented Design A Roadmap § What is Good Design? 4 4 Goals of Design Key Concepts and Principles Criteria for Good Design Principles and Rules of Good Design § What is Good Object-Oriented Design? 4 Guidelines, Rules, Heuristics § How to Apply Good Design? 4 Design Patterns 4 Architectural Patterns (Styles) Lecture 1 Dr. Radu Marinescu 6

Good Object-Oriented Design Goals of Design § Decompose system into components 4 i. e. identify the software architecture § Describe component functionality 4 informally or formally § Determine relationships between components 4 identify component dependencies 4 determine inter-component communication mechanisms § Specify component interfaces 4 Interfaces should be well defined u Lecture 1 facilitates component testing and team communication Dr. Radu Marinescu 7

Good Object-Oriented Design What is Good Design? § The temptation of "correct design" 4 insurance against "design catastrophes" 4 design methods that guarantee the "correct design" A good design is one that balances trade-offs to minimize the total cost of the system over its entire lifetime […] a matter of avoiding those characteristics that lead to bad consequences. Coad & Jourdon There is no correct design! You must decide! § Need of criteria for evaluating a design § Need of principles and rules for creating good designs Lecture 1 Dr. Radu Marinescu 8

Good Object-Oriented Design Key Design Issues Main purpose - Manage software system complexity by. . . improving software quality factors. . . facilitate systematic reuse 1. Decomposition/Composition 2. Modularity 4 Why and How ? 4 What is a component? 4 Principles Lecture 1 4 Definition. Benefits 4 Criteria 4 Principles Dr. Radu Marinescu 9

Good Object-Oriented Design Decomposition WHY ? Handle complexity by splitting large problems into smaller problems, i. e. "divide and conquer" methodology 1. Select a piece of the problem 4 initially, the whole problem 2. Determine the components in this piece using a design paradigm 4 e. g. functional, structured, object-oriented, generic, etc. 3. Describe the components interactions 4. Repeat steps 1 through 3 until some termination criteria is met 4 e. g. , customer is satisfied, run out of money, etc. ; -) Lecture 1 Dr. Radu Marinescu 10

Good Object-Oriented Design A Component Is. . . §. . . a SW entity encapsulating the representation of an abstraction §. . . a vehicle for hiding at least one design decision §. . . a "work" assignment 4 for a programmer or group of programmers §. . . a unit of code that 4 has one (or more) name(s) 4 has identifiable boundaries 4 can be (re-)used by other components 4 encapsulates data 4 hides unnecessary details 4 can be separately compiled Lecture 1 Dr. Radu Marinescu 11

Good Object-Oriented Design Component Interface A component interface consists of several sections: § Exports 4 services provided to other components § Imports 4 services required from other components § Access Control 4 e. g. protected/private/public Lecture 1 Dr. Radu Marinescu 12

Good Object-Oriented Design Decomposition Principles P 1. Don't design components to correspond to execution steps 4 Since design decisions usually transcend execution time 4 [Parnas 72] P 2. Decompose so as to limit the effects of design decisions 4 Anything that spreads within the system will be expensive to change P 3. Components should be specified by all information needed to use the component 4 and nothing more! Lecture 1 Dr. Radu Marinescu 13

Good Object-Oriented Design Modularity § A modular system is one that's structured into identifiable abstractions called components 4 Components should possess well-specified abstract interfaces 4 Components should have high cohesion and low coupling A software construction method is modular if it helps designers produce software systems made of autonomous elements connected by a coherent, simple structure. B. Meyer Lecture 1 Dr. Radu Marinescu 14

Good Object-Oriented Design Benefits of Modularity facilitates software quality factors, e. g. : 4 Extensibility u well-defined, abstract interfaces 4 Reusability u low-coupling, high-cohesion 4 Portability u hide machine dependencies Modularity is important for good design since it 4 Enhances for separation of concerns 4 Enables developers to reduce overall system complexity via decentralized software architectures 4 Increases scalability by supporting independent and concurrent development by multiple personnel Lecture 1 Dr. Radu Marinescu 15

Good Object-Oriented Design Meyer's Five Criteria for Evaluating Modularity § Decomposability 4 Are larger components decomposed into smaller components? § Composability 4 Are larger components composed from smaller components? § Understandability 4 Are components separately understandable? § Continuity 4 Do small changes to the specification affect a localized and limited number of components? § Protection 4 Are the effects of run-time abnormalities confined to a small number of related components? Lecture 1 Dr. Radu Marinescu 16

Good Object-Oriented Design 1. Decomposability § Decompose problem into smaller sub-problems that can be solved separately 4 Goal: Division of Labor u keep dependencies explicit and minimal 4 Example: Top-Down Design 4 Counter-example: Initialisation Module u Lecture 1 initialize everything for everybody Dr. Radu Marinescu 17

Good Object-Oriented Design 2. Composability § Freely combine modules to produce new systems 4 Reusability in different environments components 4 Example: Math libraries; UNIX command & pipes 4 Counter-example: use of prepocessors Lecture 1 Dr. Radu Marinescu 18

Good Object-Oriented Design Composability and Decomposability The second [precept I devised for myself ] was to divide each of the difficulties which I would examine into as many parcels as it would be possible and required to solve it better. The third was to drive my thoughts in due order, beginning with these objects most simple and easiest to know, and climbing little by little, so to speak by degrees, up to the knowledge of the most composite ones; and assuming some order even between those which do not naturally precede one another. Rene Decartes Lecture 1 Dr. Radu Marinescu 19

Good Object-Oriented Design 3. Understandability § Individual modules understandable by human reader 4 Counter-example: Sequential Dependencies (A | B | C) u Lecture 1 contextual significance of modules Dr. Radu Marinescu 20

Good Object-Oriented Design 4. Continuity § Small change in requirements results in: 4 changes in only a few modules 4 does not affect the architecture 4 Example: Symbolic Constants 4 Counter-Example: data-driven design Lecture 1 Dr. Radu Marinescu 21

Good Object-Oriented Design 5. Protection § Effects of an abnormal run-time condition is confined to a few modules 4 Example: Validating input at source 4 Counter-example: Undisciplined exceptions Lecture 1 Dr. Radu Marinescu 22

Good Object-Oriented Design Meyer's Five Rules of Modularity § Direct Mapping 4 consistent relation between problem model and solution structure § Few Interfaces 4 Every component should communicate with as few others as possible § Small Interfaces 4 If any two components communicate at all, they should exchange as little information as possible § Explicit Interfaces 4 Whenever two components A and B communicate, this must be obvious from the text of A or B or both § Information Hiding Lecture 1 Dr. Radu Marinescu 23

Good Object-Oriented Design 1. Direct Mapping § Keep the structure of the solution compatible with the structure of the modeled problem domain 4 clear mapping (correspondence) between the two Impact on: § Continuity 4 easier to assess and limit the impact of change § Decomposability 4 decomposition in the problem domain model as a good starting point for the decomposition of the software Lecture 1 Dr. Radu Marinescu 24

Good Object-Oriented Design 2. Few Interfaces § Every module should communicate with as few others as possible 4 rather n-1 than n(n-1)/ 2 4 Continuity, Protection, Understandability, Composability centralized Lecture 1 anarchic Dr. Radu Marinescu distributed 25

Good Object-Oriented Design 3. Small Interfaces § If two modules communicate, they should exchange as little information as possible 4 limited "bandwidth" of communication 4 Continuity and Protection 4. Explicit Interfaces § Whenever two modules A and B communicate, this must be obvious from the text of A or B or both. 4 Decomposability and Composability 4 Continuity, Understandability Lecture 1 Dr. Radu Marinescu 26

Good Object-Oriented Design 4. Explicit Interfaces (2) § The issue of indirect coupling 4 data sharing Module A Module B modifies accesses Data Item x Lecture 1 Dr. Radu Marinescu 27

Good Object-Oriented Design Rule 2 – Rule 3 Rephrased § Few Interfaces: “Don’t talk to many!” § Small Interfaces: “Don’t talk a lot!” § Explicit Interfaces: “Talk loud and in public! Don’t whisper!” Lecture 1 Dr. Radu Marinescu 28

Good Object-Oriented Design 5. Information Hiding Motivation: design decisions that are subject to change should be hidden behind abstract interfaces, i. e. components 4 Components should communicate only through well-defined interfaces 4 Each component is specified by as little information as possible u remember Schmidt’s decomposition principles! § Continuity: If internal details change, client components should be minimally affected 4 not even recompiling or linking Information hiding is one means to enhance abstraction! Lecture 1 Dr. Radu Marinescu 29

Good Object-Oriented Design Abstraction vs. Information Hiding Lecture 1 Dr. Radu Marinescu 30

Good Object-Oriented Design Coming Next. . . § What is Good Object-Oriented Design? 4 The Object-Oriented. . . Hype 4 Mapping of Criteria and Rules to OO Design 4 Principles of OO Design (R. Martin) 4 Design Heuristics (A. J. Riel) Lecture 1 Dr. Radu Marinescu 31