CS 370 Design Heuristics D R. M I C H A E L J. R E A L E F A L L

Transcription

1 CS 370 Design Heuristics D R. M I C H A E L J. R E A L E F A L L

2 Introduction Now we ll talk about ways of thinking about design Guidelines for trials in trial and errors

3 Major Design Heuristics

4 Major Design Heuristics Find real-world objects Form consistent abstractions Encapsulate implementation details Inherit when possible Hide secrets (information hiding) Identify areas likely to change Keep coupling loose Look for common design patterns

5 Find Real-World Objects Find real-world (or synthetic) objects you need By the book OOP approach Identify objects and attributes (methods and data) Especially think about data inside objects E.g., Employee class has a name, position, etc. Also consider methods (what the object can do) What can be done to each object? E.g., Employee s position could be changed What is each object allowed to do to other objects? Inheritance and containment relationships Visibility of attributes/methods Public vs. private Object s public interface Methods exposed to other classes

6 Form Consistent Abstractions Form consistent abstractions Abstraction = ability to engage in concept while safely ignoring some of the details E.g., house (without thinking about wood, glass, nails, etc.) Examples of software abstractions: Base classes Isolate what is common to a bunch of classes Class interfaces Don t have to worry about guts of functionality Function interfaces You can look at an object at a high level of detail.

7 Encapsulate Implementation Details Encapsulate implementation details Picks up where abstraction leaves off FURTHERMORE, you aren t allowed to look at an object any other level of detail E.g., can open/close door, BUT can t see what the door is made of (wood, steel, etc.)

8 Inherit When Possible Inherit when inheritance simplifies the design Works with abstraction Simplifies things because: Write general routines for all children E.g., all Door subclasses will have Open()/Close() Specific routines for subclasses E.g., WoodDoor returns true for Burnable() However, can also overcomplicate things Examples: Making base class and there s only one subclass Deep inheritance trees

9 Hide Secrets (Information Hiding) Hide secrets (information hiding) Black box design Things to hide: Inner workings (as much as possible) Data formats Attribute data types, files, etc. Areas likely to change Area with errors that needs to be walled off Changes to class methods/data: May affect class internally Should NOT affect class interface / behavior outside class

10 Barriers of Information Hiding Things that break Information Hiding Excessive distribution of information E.g., hardcoded 100 instead of MAX_EMPLOYEES Circular dependencies A calls B, B calls C, C calls A Avoid these where possible Global data (and to a lesser extent class data) Global data is problematic: Routines operate on globals BUT don t know other routines are as well Routines DO know other routines have messed with the globals but they don t exactly WHAT they did Class data less problematic: Only routines in class act on data Can be a problem if your class is excessively large

11 Information Hiding Summary Value of information hiding Proven to be effective in practice Has unique heuristic power (even beyond OO thinking) Promotes thinking about design issues that OO may not address Always ask What should I hide?

12 Identify Areas Likely to Change Procedure: Identify areas likely to change Separate items into classes, routines, etc. Design interface so change will not affect interface Common areas of change: Business rules Hardware dependencies Input/output Nonstandard language features Difficult design and construction areas Might have to do them again Status variables Usually good idea to avoid bool and use enumeration Data-size constraints Use MAX_EMPLOYEES, not 100

13 Loose Coupling Coupling = how tightly class/routine is related to other classes/routines Size = # of connections Smaller is better Visibility = how obvious connection is Passing data in parameter list good Modifying global data bad Flexibility = how easily you can change connections E.g., function that requires a class as a parameter (but it s only really using a tiny bit of that class) bad

14 Common Types of Coupling Common kinds of coupling: Simple-data-parameter Primitive data types passed through parameter lists Normal and acceptable Simple-object One object instantiates another Fine Object-parameter Object1 requires Object2 to pass it an Object3 Tighter needs Object2 to know about Object3 Semantic Uses knowledge of classes/routines inner workings Control flag passing based on assumptions of what will happen Global data Have to call Init() before Routine(), but know that Init() is called inside Routine() and ignore it Pass object, but only fill it in partially Module1 passes BaseObject to Module2. Module2 knows BaseObject is really DerivedObject, so Module2 casts it as such. Most insidious

15 Point of Loose Coupling Kind of abstraction write routine/class, then take it for granted Don t have to worry about inner workings

16 Look for Common Design Patterns Some pieces of problem may already have been solved Design patterns = time-tested patterns that can be applied to specific situations Ready-made abstraction Easier to discuss and communicate design Reduce errors Standardized way to solve certain problems Similar in concept to using a code library Gives you suggestions for design alternatives Go through list and see if any fit your problem

17 Problem with Design Patterns Don t want to force-fit a pattern Increases complexity Don t want to use a pattern just because you want to try it out Should fit the problem

18 Popular Design Patterns

19 Popular Design Patterns Design patterns fall into one of three categories: Creational Way to create objects while hiding creation logic Structural Class and object composition Behavior Communication between objects

20 Creational: Factory Method Factory Method Makes classes derived from a base class Hides instantiation logic public class ShapeFactory { //use getshape method to get object of type shape public Shape getshape(string shapetype){ if(shapetype == null){ return null; if(shapetype.equalsignorecase("circle")){ return new Circle(); else if(shapetype.equalsignorecase("rectangle")){ return new Rectangle(); else if(shapetype.equalsignorecase("square")){ return new Square(); return null;

21 Creational: Abstract Factory Abstract Factory Effectively a factory of factories Do not need to specify concrete classes public abstract class AbstractFactory { abstract Color getcolor(string color); abstract Shape getshape(string shape) ; public class ShapeFactory extends AbstractFactory {... public class ColorFactory extends AbstractFactory {... public class FactoryProducer { public static AbstractFactory getfactory(string choice){ if(choice.equalsignorecase("shape")){ return new ShapeFactory(); else if(choice.equalsignorecase("color")){ return new ColorFactory(); return null; AbstractFactory shapefactory = FactoryProducer.getFactory("SHAPE");

22 Creational: Singleton Singleton Only one instance of this class in the application Can be accessed without explicitly instantiating it public class SingleObject { //create an object of SingleObject private static SingleObject instance = new SingleObject(); //make the constructor private so that this class cannot be //instantiated private SingleObject(){ //Get the only object available public static SingleObject getinstance(){ return instance; public void showmessage(){ System.out.println("Hello World!");

23 Structural: Adapter Adapter Converts the interface of a class to a different interface public class MediaAdapter implements MediaPlayer { AdvancedMediaPlayer advancedmusicplayer; public MediaAdapter(String audiotype){ if(audiotype.equalsignorecase("vlc") ){ advancedmusicplayer = new VlcPlayer(); else if (audiotype.equalsignorecase("mp4")){ advancedmusicplayer = new public void play(string audiotype, String filename) { if(audiotype.equalsignorecase("vlc")){ advancedmusicplayer.playvlc(filename); else if(audiotype.equalsignorecase("mp4")){ advancedmusicplayer.playmp4(filename);

24 Structural: Bridge Bridge Builds an interface and an implementation in such a way that either can vary without the other varying public interface DrawAPI { public void drawcircle(int radius, int x, int y);... Shape redcircle = new Circle(100,100, 10, new RedCircle()); Shape greencircle = new Circle(100,100, 10, new GreenCircle()); redcircle.draw(); greencircle.draw();

25 Structural: Composite Composite When we need to treat a group of objects as a single object Creates a tree structure

26 Structural: Decorator Decorator Add new functionality to an existing class without altering its structure Wrapper around existing classes Keeps class method signatures intact public abstract class ShapeDecorator implements Shape { protected Shape decoratedshape; public ShapeDecorator(Shape decoratedshape){ this.decoratedshape = decoratedshape; public void draw(){ decoratedshape.draw(); public class RedShapeDecorator extends ShapeDecorator { public RedShapeDecorator(Shape decoratedshape) { public void draw() { decoratedshape.draw(); setredborder(decoratedshape); private void setredborder(shape decoratedshape){ System.out.println("Border Color: Red");

27 Structural: Facade Facade Provides consistent interface to code that wouldn t otherwise offer a consistent interface Single class with simplified methods that delegates calls to existing classes public class ShapeMaker { private Shape circle; private Shape rectangle; private Shape square; public ShapeMaker() { circle = new Circle(); rectangle = new Rectangle(); square = new Square(); public void drawcircle(){ circle.draw(); public void drawrectangle(){ rectangle.draw(); public void drawsquare(){ square.draw();

28 Behavior: Iterator Iterator Way to access the elements of a collection object in sequential manner without any need to know its underlying representation NameRepository namesrepository = new NameRepository(); for(iterator iter = namesrepository.getiterator(); iter.hasnext();){ String name = (String)iter.next(); System.out.println("Name : " + name);

29 Behavior: Observer Observer Keeps multiple objects in sync with one another by making an object responsible for notifying the set of related objects about changes to any member of the set

30 Behavior: Strategy Strategy Defines a set of algorithms/behaviors that are dynamically interchangeable with each other I.e., can change behavior at run-time public class Context { private Strategy strategy; public Context(Strategy strategy){ this.strategy = strategy; public int executestrategy(int num1, int num2){ return strategy.dooperation(num1, num2);

31 Behavior: Template Template Defines structure of an algorithm but leaves some of the detailed implementation to subclasses public abstract class Game { abstract void initialize(); abstract void startplay(); abstract void endplay(); //template method public final void play(){ //initialize the game initialize(); //start game startplay(); //end game endplay();

32 Other Useful Design Heuristics

33 Other Useful Design Heuristics Aim for strong cohesion Classes/routines should have a well-defined central purpose Build hierarchies Class hierarchies, routine hierarchies, etc. Formalize class contracts Pre-conditions and post-conditions Asserts Assign responsibilities What is each object responsible for? Similar but broader question than, What does each object hide?

34 Other Useful Design Heuristics Design for test In particular, design interfaces thinking about how you would test classes/subsystems/routines Avoid failure Think about how things might fail (and how to prevent it) Choose binding time consciously Binding time = time a specific value is bound to a variable Earlier simpler, but less flexible

35 Other Useful Design Heuristics Make central points of control The Principle of One Right Place Even a named constant (e.g., MAX_EMPLOYEES) centralizes control Consider using brute force A brute force solution that works better than elegant solution that doesn t Draw a diagram Doesn t have to formal helps you focus your ideas and thoughts Keep your design modular Try to design things with the black box idea in mind

36 References Design patterns: gn_pattern_overview.htm