Basic Design Patterns

These are some notes from a java/c class I took 

• Creational- to do with object creation process
• Behavioral - to do with dynamic interaction between objects and classes
• Structural - to do with static composition and structures of classes and objects

• Java is object oriented, but sometimes we don't need to create objects, like when there is just a need for utilities. ie quicksort, so just make the constructor private and have static functions (utility design pattern)
• Model-view-controller (MVC)
  • view (browser) <->controller (asp/jsp server) <->model (db server) 
  • the view is the visible gui
  • the model is the hidden data
  • the controller brokers interactions between the view and model
  • doing this depends on how sophisticated program is and how much it will expand (in other words, don't do mvc if program is small)
• Dynamic class loading
  • "lazy loading" to save space
  • object is created for each class
  • BinaryOps.put(name,operator) //adds the class to the hash table in a key value pair fashion
  • Class.forName("minus").NewInstance //this is a class called Class and it will load the class called minus(bring it into memory)
  • Note that NewInstance creates the minus object
  • Using this hash table, in this fashion, is similar to polymorphism
• State design pattern (behavioral)
  • abstract class for any state : enter, exit, etc
  • all states are a subclass of this abstract class
  • The controller brokers all interactions between states and has a pointer to them
  • This allows an object to change its behavior when its internal state changes
  • This is a form of dynamic binding that is polymorphism
  • Each of these internal states are concrete states
  • The context is where state change request takes place; this is the object which contains the abstract class state object (through composition)
• Singleton (Creational)
  • Each class you want an object of has a private constructor, and implements a getInstance function which returns a new object
  • This ensures that only one object exists for each class
  • It provides a global point of access to this one object
  • The class has a variable of itself like this : private static ClearCalcState instance = null;
  • getInstance looks like this : public static getInstance(){ if (instance == null) {instance = new ClearCalcState();} else {} return instance;}
  • This is useful for a state design pattern
• Mediator design pattern
  • an object encapsulates the interaction of other objects
  • ex: all components in a dialog box notify a mediator of state changes. The mediator updates affected components
  • decouples interactions between objects to make design easier and it's easier to extend
• Iterator (Behavioral)
  • When considering making a linked list in java, you probably will create a class node within the linked list class, but do you make front ptr and node class public?
  • You might decide that it's better to have methods to traverse a list for printing out members as opposed to getting the front ptr directly
  • This is ok, but what if you need to nest loops, then it's probably better to create an iterator separate from the class
  • This iterator would have the next, hasnext methods of a linked list
  • The iterator can be an interface: interface iterator{ boolean hasnext(); object next(); void remove();}
  • If you have the iterator as an interface, then the collection class should return an Iterator object with the Iterator function call(which should be called Iterator); note that this interface implementing class is still separate from the data structure class
  • Benefits of this: support different types of collections for polymorphic traversals, and it abstracts the internal details of collections
• Visitor (behavioral)
  • visitor keeps track of what is visited
  • in an example: you have three different implementations of dfs (depth-first search)- one just prints the vertex it visited, one decrements a number with each visited vertex and the last one just counts the number of components (where a component is a group of nodes)
  • the drawback of putting all these dfs algorithms in one class is that the client may not need all those algorithms (in this case it may seem natural to put them in with the Graph class)
  • the ideal solution would be to create an abstract class called Visitor and have each algorithm be a subclass of it
  • the Visitor class would probably consist of constructor, isVisited, restart, visit, preaction, and postaction functions
  • you can also add special functions for each algorithm
  • the client actually depends on the Visitor class and doesn't have to know the details of any of its subclasses
• Template Method (behavioral)
  • this uses an abstract class with a template method and hooks
  • the hooks can be abstract methods or default methods
  • the actual template method is not abstract and is the single method that is called and it in turn calls the hooks
  • for this dfs example, you can define a dfs template method pattern, where an abstract class called Dfs is subclassed by each algorithm with minor code additions and overriding the hook methods as needed
• Observer(behavioral)
• this has to do with an observable event and multiple listeners that depend on that event
• you separate the observed from the observers, so you can notify objects listening without worrying about which objects and their details