P4L5 Design Principles

Design Guidelines e Design CAN'T resly be taught, but has to be learned through experience o Offered severa ways to learn from the experience of others l e Design principles are informal guidelines Design Quality » One of severa ways of gauging the quality of designs e Utimate validation of design is to build the program and have its users report their satisfaction o Can buld 8 prototype or conduct design reviews e Various metrics can compute actudl numbers assessing the quality \ « Least expensive but conceivably most valuable

Design Guidelines Coupling e also caled 8 design principle or design heuristics » Extent to which 3 module is dependent on other modules * an ipformal piece of e Coupling of your advice about the . modules should be low in structure of 8 design order to make it easier to maintain them o téke the form of * invented by Larry k do's and don'ts Constantine Cohesion Orthogonality . o Extent to which the features of a o Extent to which 8 module has 8 system can be varied independently single purpose i gie purp e Enhance the orthogonality of your system in order to « Cohesion shoud be high g:/aa'fgblfgotrg i?Spfli‘cgr;?s in order to enhance understandability and o Clarifies system promote reuse descriptions and support automatic generation e Developed by David l e Invented b.y Larry McGovern and Christopher Constantine Date

Catalog e Give the principle's name, author, definition and implications of its use e Only guidelines and not hard-and-fast rules Liskov Substitution Principle e Barbara Liskov e Subclass instances should satisfy . parent-class constraints e Implies that child class instances should obey parent class invariants \ and method contracts

Law of Demeter e Karl Lieberherr e Suggests limits on the classes that can be referred to by 8 given method o Limits the objects that can be referred to e Reduces coupling, but sometimes requires extra wrapper classes Hollywood Principle e Donald Wallace o Frameworks consist of a set of abstract classes together with rules for the ways that therr concrete subclasses may interact » Suggests that calls should be made from the framework to the client classes e also caled inversion of control \ « "Don't cal us; we'l cal you"

Imagine you have designed the following classes: class Motor { public void run() { /*run algorithm...*/ } } class FancyMotor { public void run() { /* run fancy algorithm... */ } } class Robot { // complex Robot class Motor motor; X public void boot () { motor.run() ; } Interface Segregation Principle e Robert Martin e Suggests that clients depend on an interface to a part of the large class's features » Note the relationship of this principle to role-based design o Class interfaces shoud be broken into small pieces corresponding to single use case Assume the Robot class is very complex, and now we have to change it to include 8 new FancyMotor, Making this change wil be difficut with the current design because it violates which design principle? Substitution Principle Law of Demeter Hollywood Principle Dependency Inversion Principle Open-Closed Principle

Reuse Equivalency Principles e Robert Martin e The granule of reuse should be the granule of release e Release highly cohesive code units e Java package e Converse of this principle is the Common Reuse Principle Common Closure Principle e Robert Martin » Regardess of the level of granularity we are forced to use, group the related elements into 8 common release unit » In Java, this woud typicaly be a8 package o Classes that change together, should be released together

Acyclic Dependency Principle e Robert Martin o Dependencies between packages must not form cycles e Should be able to permute the rows and columns of the DSM o Component only depends on other components beneath it e Violation of this property would lead to 8 system that is difficult to maintain and understand Sfabili'ty e Robert Martin e A module is hard to change if 3 lot of other modules depend on it » Stable Dependency Principle suggest that you should depend in the direction of stability No package should be dependent on packages that are more likely to change than it e Martin's Stable Abstraction Principle e Easy to extend

Bad Smells » Kent Beck and Martin Fowler popularized the notion of refactoring in the 1990’s e Move some design activities into the actual implementation phase of development o Reduce rework in situations with rapidly changing requirements e Code situations that are suggestive of design problems » Fowler’s book recognize dozens of bad smells besign Heuristics - Riel e Do not change the state of an object without going through its public interface N * Means that 8 method in a8 class cannot change an instance variable without caling the setter e Users of a class must be dependent on its public interface, but a class should not be dependent on its users » Distribute system inteligence horizontally as uniformly as possible Distribute system inteligence vertically down narrow and deep containment hierarchies

Intentionality e Most abstract o Design software in such 3 way that intent is manifest and locadlized in the code o Supports traceability, validation, and maintainability. e Improve intentionality by appropriate use of cohesion and naming conventions James Gosling was the author of the Java programming language. At a Java Users Group meeting he was asked: "f you could do Java over 3gain, what would you change?" He replied: "'d leave out classes" Which of the principles or heuristics that have been mentioned in this lesson supports this idea? Mark al that apply: Liskov Substitution Principle Interface Segregation Principle Stable Abstraction Principle Riel: Inheritance should be used only to model 3 generdlization hierarchy X]PX]XI1><

Summary e A catalog of design principles is too abstract to be immediately useful e By being made aware of these principles you wil be sensitized to problematic situation when they arise * Then look up the relevant principle and its suggested solutions