How to Write Good API

 1– methods should do only one operation (only one function per method)

this enable -code reuse

-modularity

-sample for testing

2– keep method small

if method have to make more than function you can encapsulate them in object

3– defensive Programming check on expected arguments to method

Ex.- If not null

– should be string

– should be array

but not validation on argument it should isolated to another method

4- use design patterns if and only if scenario,logic require that

not use design patterns just for using them

5- All types have to be interfaces

-and if you need to add function for this type you can use wrapper(delegates)

-you can wrap you function in new object (use decorator)

6- keep method name descriptive

7- you have to use factory for creating objects

you have not create object of module into another one use factory for this

8- try to provide all information for client code

9- make logging information as a informative conversation (you can report those information later )

10- Anti-if else

you have not use if else ==>use factory to select between state of object

11- null object

1- avoid return null from method

2-at some cases you should use null object which implement interface and have empty

implementation for all method

Ex: you should not pass null to command ,state machine design pattern

12- Object or Variable

1- every thing could be object as long as has it’s behavior ,attribute ,flow to avoid the god class

2- it could be data object which encapsulate data

13- The definition of Done

mean task well documented,tested

Visitor Design pattern

the visitor design pattern is a way of separating an algorithm from an object structure it operates on. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. It is one way to easily follow the open/closed principle.

the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal

Continue reading Visitor Design pattern

strategy design pattern

public interface Sender {
  public boolean Send(NotificationBean notificationBean,List ... temp);
}

public abstract class sendEmailTemplate implements Sender {

	public abstract void preSend(NotificationBean notification,List ... temp);

	public abstract void PostSend();

	public abstract boolean TryToSend();

	public abstract boolean IsSent();

	public abstract boolean NotifyDB(boolean success);

	public boolean Send(NotificationBean notification,List ... temp) {
		preSend(notification,temp);
		if (TryToSend() && IsSent())
			PostSend();
		
		return IsSent();	
	}
}

public abstract class sendSmsTemplate implements Sender {

	public abstract void preSend(NotificationBean notification,List ... temp);

	public abstract void PostSend();

	public abstract boolean TryToSend();

	public abstract boolean IsSent();

	public abstract boolean NotifyDB(boolean success);

	public boolean Send(NotificationBean notification,List ... temp) {
		preSend(notification,temp);
		if (TryToSend() && IsSent())
			PostSend();
		
		return IsSent();	
	}
}

@Component
public class SMSSender extends sendSmsTemplate{

	@Override
	public void preSend(NotificationBean notification,List ... temp){
		
		System.out.println("presend action in send sms");
	}

	@Override
	public void PostSend() {
	
		System.out.println("postsend action in send sms");
	}

	@Override
	public boolean TryToSend() {
		
		return true;
	}

	@Override
	public boolean IsSent() {
		
		return true;
	}

	@Override
	public boolean NotifyDB(boolean success) {
		
		return false;
	}

}


@Component
public class EmailSender extends sendEmailTemplate {

	private String[] to, cc, bcc;
	boolean sent = false;
	private String subject, message;

	@Autowired
	public MailService mailService;
	@Autowired
	private NotificationBean NotificationBean;

	public EmailSender() {

	}

	@Override
	public void preSend(NotificationBean notification, List... temp) {

		// here i am within present of email sender
		// you are supposed to receive 3 lists
		// first one is to Destination list
		// first one is cc Destination list
		// first one is bcc Destination list

		/*
		 * for (List list : temp) { for (String string : list) {
		 * System.out.println(string); } }
		 */
		int counter = 0;

		for (List list : temp) {
			if (counter == 0)
				to = list.toArray(new String[0]);
			if (counter == 1)
				cc = list.toArray(new String[0]);
			if (counter == 2)
				bcc = list.toArray(new String[0]);
			counter++;
		}

		subject = notification.getNotification().getSubject();
		message = notification.getNotification().getMessage();

		setNotificationBean(notification);

	}

	@Override
	public void PostSend() {

		System.out.println("postsend action in send email");
	}

	@Override
	public boolean TryToSend() {
		SimpleMailMessage email = new SimpleMailMessage();

		email.setTo(to);
		email.setBcc(bcc);
		email.setCc(cc);
		email.setText(message);
		email.setSubject(subject);

		try {
			mailService.send("lorddisk@yahoo.com", to, cc, bcc, subject,
					message, getNotificationBean());
			System.out.println("Email has been sent ");
			sent = true;
		} catch (Exception e) {
			sent = false;
		}

		return sent;
	}

	@Override
	public boolean IsSent() {

		return sent;
	}

	@Override
	public boolean NotifyDB(boolean success) {

		return false;
	}

	public String[] getTo() {
		return to;
	}

	public void setTo(String[] to) {
		this.to = to;
	}

	public String[] getCc() {
		return cc;
	}

	public void setCc(String[] cc) {
		this.cc = cc;
	}

	public String[] getBcc() {
		return bcc;
	}

	public void setBcc(String[] bcc) {
		this.bcc = bcc;
	}

	public boolean isSent() {
		return sent;
	}

	public void setSent(boolean sent) {
		this.sent = sent;
	}

	public String getSubject() {
		return subject;
	}

	public void setSubject(String subject) {
		this.subject = subject;
	}

	public String getMessage() {
		return message;
	}

	public void setMessage(String message) {
		this.message = message;
	}

	public MailService getMailService() {
		return mailService;
	}

	public void setMailService(MailService mailService) {
		this.mailService = mailService;
	}

	public void setNotificationBean(NotificationBean notificationBean) {
		NotificationBean = notificationBean;
	}

	public NotificationBean getNotificationBean() {
		return NotificationBean;
	}

}


@Component
public  class senderFactory {
	@Autowired
	public EmailSender emailsender;
	@Autowired
	public SMSSender smsSender;

	public  Sender getSender(DestinationTypes destinationTypes) {
		Sender s = null;
		if (destinationTypes == destinationTypes.Email)
			s= emailsender;
		else if (destinationTypes == destinationTypes.MOBILENUMBER)
			s=  smsSender;
		return s;
	}

	public EmailSender getEmailsender() {
		return emailsender;
	}

	public void setEmailsender(EmailSender emailsender) {
		this.emailsender = emailsender;
	}

	public SMSSender getSmsSender() {
		return smsSender;
	}

	public void setSmsSender(SMSSender smsSender) {
		this.smsSender = smsSender;
	}
}


public enum DestinationTypes {
	Email(1),
	MOBILENUMBER(2),
	IP(3),
	URL(4);
	private int type;
	DestinationTypes(int type)
	{
		this.type=type;
	}
	
	public void setType(int type) {
		this.type = type;
	}

	public int getType() {
		return type;
	}
	
}


Abstract Factory Design Pattern

1-This pattern is one level of abstraction higher than factory pattern.
2-the abstract factory returns the factory of classes. Like Factory pattern
returned one of the several sub-classes, this returns such factory which later will return one of the sub-classes.
3-we need to get the specification of various parts of a computer based on which work the computer will be used for.

public abstract class Computer {
//abstract factory class every method is factory method
	public abstract Parts getRAM();

	public abstract Parts getProcessor();

	public abstract Parts getMonitor();

	public static Computer getComputer(String computerType) {
		Computer comp = null;
		if (computerType.equals("PC"))
			comp = new PC();
		else if (computerType.equals("Workstation"))
			comp = new Workstation();
		else if (computerType.equals("Server"))
			comp = new Server();

		return comp;
	}
}
----------------------------------------------------------

public class Parts {
	public String specification;

	public Parts(String specification) {
		this.specification = specification;
	}

	public String getSpecification() {
		return specification;
	}
}
-----------------------------------------------------------
public class PC extends Computer{

	
	public Parts getRAM() {
	return new Parts("512 MB");
	}

	
	public Parts getProcessor() {
	return new Parts("Celeron");
	}

	
	public Parts getMonitor() {
		return new Parts("15 inches");
	}

}
-----------------------------------------------------------
public class Server extends Computer{


	public Parts getRAM() {
	return new Parts("4 GB");
	}

	public Parts getProcessor() {
	return new Parts("Intel P 4");
	}

	
	public Parts getMonitor() {
	return new Parts("17 inches");
	}

}
----------------------------------------------------
public class Workstation extends Computer {

	public Parts getRAM() {
		return new Parts("1 GB");
	}

	public Parts getProcessor() {
		return new Parts("Intel P 3");
	}

	public Parts getMonitor() {
		return new Parts("19 inches");
	}

}
---------------------------------------------------------
-----------------------------------------------------
public static void main(String[] args) {
		

		Computer computer = Computer.getComputer("Server");
		System.out.println("Monitor: "+ computer.getMonitor().getSpecification());
		System.out.println("RAM: " + computer.getRAM().getSpecification());
		System.out.println("Processor: "+ computer.getProcessor().getSpecification());
	}

Factory Design Pattern

if we have a super class and n sub-classes, and based on data provided, we have to return
the object of one of the sub-classes, we use a factory pattern.

Example: Let’s suppose an application asks for entering the name and sex of a person.
If the sex is Male (M), it displays welcome message saying Hello Mr. <Name> and if the sex is Female (F),
it displays message saying Hello Ms <Name>.

a getPerson which will return the welcome message depending on the data provided.

public class Person {
// name string
public String name;
// gender : M or F
private String gender;
public String getName() {
        return name;
 }
public String getGender() {
return gender;
}
public static Person getPerson(String name, String gender) {
if (gender.equals("M"))
  return new Male(name);
else if (gender.equals("F"))
  return new Female(name);
else
  return null;
}
}
----------------------------------------------------------------
public class Male extends Person {
public Male(String fullName) {
System.out.println("Hello Mr. " + fullName);
}
}
---------------------------------------------------------------
public class Female extends Person {
public Female(String fullNname) {
System.out.println("Hello Ms. " + fullNname);
}
}
--------------------------------------------------------------
public static void main(String args[]) {

Person.getPerson("ali", "M");
Person.getPerson("sara", "F");
}

Design Pattern

Introduction

Instead of defining what is design pattern lets define what we mean by design and what we mean by pattern. According to me design is blue print or sketch of something so it can be defined as creation of something in mind. Moving to pattern, we can define it as guideline, or something that repeats. Now the definition of design pattern becomes creating something in mind that repeats or in other words capturing design ideas as a “pattern” to the problems.

Some problem patterns happen over and over again in a given context and Design Pattern provides a core of the solution in such a way that you can use the core solution every time but implementation should and may vary and the main reason behind that is we have the core solution and not the exact solution. We can discuss an example here about database normalization. Normalization is a pattern (Core solution to database design) but what level of normalization you need (exact solution) depends on your requirement and context.

In this article I will be discussing the following Design patterns ( or common problems and there common solutions which are time tested and have worked when applied).

I will not be defining the design patterns because you can always find them in any standard book but I will be dealing with the actual use and examples of them. To understand the article in a better I would suggest you first download the demo project. To see any sample you make the project as the StartUp project and compile the project and execute it. The solution is build using Microsoft Visual Studio 2005. I have purposely used the abstract classes over interface so the class diagram of the samples looks exactly similar to one suggested by gang of four. If you find a class whose Name is IClassName please don’t get upset but its done purposefully to make the class diagrams. In the article I have tried to use as many pictures as possible because “A picture is worth a thousand words”

Creational Patterns

Abstract Factory

– Do we need to create families of objects.

Factory method takes care of one product where as the abstract factory Pattern provides a way to encapsulate a family of products.

Typically the class diagram looks like

Example

We have a requirement where we need to create control library and the same library supports multiple platforms but the client code should not be changed if we import from one operating system to the other. The solution is

The client uses the GuiFactory to get the required factory of the supported operating system and calls the same Show Method. Now depending on the platform we change the factory but the client implementation remains the same. If support for new operating system is to be added we need the new factory and the exact implementation of the buttons and without changing the existing code we can support the new platform.

Builder

– Do we need to create object in several steps.

Builds a class based on requirements where Director asks the builder to build each of the parts. Mainly the builder pattern is not used independently but other patterns may have builder pattern as a part where they create the complicated objects using the builder.

Typically the class diagram looks like

Example

Who is what?

Waiter is Director
PizzaBuilder is Builder
CheesePizzaBuilder and MixedPizzaBuilder are Concretebuilder
Pizza is product

When Waiter (Director) is asked to serve it creates the Pizza (Product) using the PizzaBuilder.

Another example could be Maze which is a complicated object build from walls and rooms.

Factory

– Do we need to have derived classes figure out what to instantiate and decouple client from instantiated class.

Client uses the factory to create products and its the factory which decides when the actual product is needed for instantiation. This way client decouples the instance and can be saved from some of the crucial operations of object copy if the type of object may change after creation.

Typically the class diagram looks like

Example

Who is what?

ComputerFactory (Creator)
ConcreteComputerFactory (ConcreteCreator)
Processor (Product)
ConcreteProcessor (ConcreteProduct)

When the GetProcessor of ComputerFactory is called its the ConcreteComputerFactory creates the ConcreteProcessor and the creation of ConcreteProcessor is delayed till we call the GetProcessor() function.

Another good example could be logging, where we create the instance of the logger factory but instantiate the logger class when actual logging is done.

Prototype

– Do we have too many classes to instantiate / or is the object creation a cumbersome process.

Mainly we don’t create the objects of a class directly but clone the existing object and change the state of the object as needed. The main application of such pattern is when the object creation is costly. As an example we have a database class the constructor sets up the database for the class. Now for each new user logging to the system once the system is up we don’t setup the database but just clone the first object and change the user specific details like user name / password to validate the user.

Typically the class diagram looks like

Example

I would not explain here who is what because its pretty much evident.

Singleton

– Do we need to limit the no of objects of a class.

Ensures only one (n = 1..n) instance. The pattern explains how you can achieve the singleton class. It says to have the constructor as private and have a static method to access the instance of the class using that method.

Typically the class diagram looks like

Example

I would not explain here who is what because its pretty much evident.

Structural Patterns

Adapter

– Do we have the right stuff but wrong interface.

We use the adapter design pattern where the requirements is to convert between one interface to another. Adapter pattern is never implemented when designing a new system but with the changing requirements we have deferring interfaces then adapter comes into picture.

Typically the class diagram looks like

Example

We have used some library where we have Add function which takes two integer and provides the sum of them. Now when upgrading the libray we find that the library has changed the Add function such that it takes 2 floating point number. Now one option could be to change all the client code where we have used the Add method or other option is to have an Adapter.

CalcAdapter calls the necessary library function after making the necessary changes (in our example conversion between the data types)

Bridge

– Do we have one variation using another variation in a varying way.

Decouple an abstraction from its implementation so that two can vary independently. In strategy pattern we decouple the behavior but in Bridge we decouple the abstraction.

Typically the class diagram looks like

Example

In Abstract Factory we discussed about the problem of creating a control library for various operating system. Now creating the library from the scratch is never a good idea and so we may need to use some of the existing infrastructure or library available. We may use the XWindow toolkit or MacWindow toolkit as the base depending on the user platform and toolkit available.

The DrawRect actually uses the DrawLine function which actually is dependent on the type of implementation and we seperate the implementation from the abstraction and have a link ( or bridge ) between the two.

Composite

– Do we have units and groups and want to treat them the same way.

Compose the objects in a tree structure where individual objects as well as the composed objects behave uniformly. Composed objects delegates the requests to the individual leaf objects.

Typically the class diagram looks like

Example

We have some simple graphics and have some graphics which are composed of these simple graphics and as a client both should behave uniformly.

Folder browsing could be other example where from the client’s point of view its an operation on the folder tree irrespective of its folder ( composite object ) or file ( leaf object ).

Decorator

– Do we need multiple additional functions we may need to apply, but which and how many we add varies, without sub classing.

Attach additional responsibilities to an object dynamically. It has the capability of performing some additional operations before or after the basic operation.

Typically the class diagram looks like

Example

Say we have a FileReaderclass where the file can be read based on the combination of applying any of the formulas like it could be

  • Zipped.
  • Encrypted.
  • Zipped and encrypted.
  • encrypted then zipped and ecrypted again.

The solution is Decorator pattern where we apply the options based on the requirement.

Code: CSharp
FileReader file = new FileReader();
// Zip the File
ZipReader zip = new ZipReader(file);
// Encrypt the zip file
EncryptedReader enc = newEncryptedReader(zip);enc.Read();
Code: CSharp
FileReader file = new FileReader();
// Encrypt the file
enc = new EncryptedReader(file);
// Zip the encrypted file
zip = newZipReader(enc);zip.Read();

We can apply any combination as and when needed and also new methods of encryption is very simple. Just add the new class as sibling of EncryptedReader

Facade

– Do we want simplify, beautify or OO-fy an existing class or subsystem.

When client is decoupled from the system using an inter mediator its called facade. Facade behaves as a door to subsystem and provides a single interface to complex interface in the subsystem. Here a point to note is that the subsystem should not have a dependency on the FACADE and if thats the case then the facade is a part of the sub-system and it should move into the sub-system and we should have a new facade class.

Also Facade is not the only entry point to the sub-system but is a convenient point of communication to the subsystem and client can always have the direct access to the subsystem.

This methods helps in developing the subsystem independently without affecting the clients using them.

Typically the class diagram looks like

Example

We have a Car System creation where the car is created based on the complex subsystems like wheel, steering, chassis, body …

Flyweight

– Do we have too many part objects.

Any objects state can be classified into two types of data that it can store one is intrinsic (static and independent of object) and one is extrinsic (non-static and depend on the state of the object) then flyweight pattern can be applied. The design pattern is useful when we have large no of objects which can be grouped once the extrinsic state is removed and it uses de-encapsulation to split the objects.

Typically the class diagram looks like

Example

We have some shape objects and the shape objects are really costly and so we can have the shape object split itself such that some data which is independent of the state of the object is kept in the object and other data is provided externally. Say in our shape object how the shape is drawn is same but where the shape is drawn is dependent on the state of the object and so the print method should know where to print which is extrinsic and should be supplied.

Proxy

– Do we need to optionally add some new functionality to something that already exists. Do we need to control how an object is accessed.

It provides a placeholder for another objects and the proxy object gives the impression to the client that actual request is handled by the proxy but it just delegates the request to the real subject.

Typically the class diagram looks like

Example

Say we have a system setup where we send and receive data over the network. Now due to some security reasons data are encrypted and so now they need to be decrypted before processing and so now we are in trouble because all the client code needs to be changed to decrypt the data or we may need to change the stable library code which use to send/recieve the data. Now the solution could be to have the proxy which will do the additional responsibility given to the system and then send the data using the well tested system in place.

We should be using the proxy system where we think we may need to add some additional responsibilities later.

Behavioral Patterns

Chain of Responsibility

– Do we have diff. objects that can do the job but we do not want the client object know which is actually going to do it.

Avoid coupling the sender of a request to its reciever by giving more than one object a chance to handle the request. Helps in reducing the coupling though they are chained, but does not know about other objects apart fron the fact that they derive from the common interface.

Best example could be Context help where the each help component tries to perform the request and when fail they pass the request in the chain to other members.

Typically the class diagram looks like

Example

In the banking system where cheque’s for clearing is approved by the person but if the cheque amount is beyond certain limit, the approving responsibility moves the person higher in authority in the bank.

Windows messaging system works in the similar method where the messages are processed by the controls if the point likes with the bounds of the control or goes to the parent.

Command

– Do we need to decouple request from handler.

Encapsulate requests for service from an object inside other object(s) and manipulate requests. Command objects are mainly helpful in undo/redo operation where the previous state can be saved for reloading or even the necessary command(s) can be stored in stack for the same.

Typically the class diagram looks like

Example

Say we have designed an image editor and user can have the option of opening file from various ways like menu, tool bar, double click on a file in the explorer. The solution is the command pattern where the FileOpen command is associated in the viewer itself and when the command executes the file is shown in the viewer.

The other example could be the operations on the images.

Interpreter

As the name suggest it interpret your expression. Some expressions are atomic and some complex which are made up of atomic and it interprets the atomic and complex expressions uniformly. It mainly uses in the compilers / parsers / Macro expansions.

I have not provided any sample because this one is not that often used just for completeness of the article have mentioned the pattern here.

Iterator

– Do we want to separate collection from client that’s using.

Provide a way to access the elements of an aggregate objects sequentially without exposing its representation. We can make the client independent on the movement of the cursors like forward traversal / backward traversal as well as the internal implementation of the list.

Typically the class diagram looks like

Example

I would not explain here who is what because its pretty much evident and nowadays any modern language supports this and so you could use the foreach loop. In C-Sharp if you would like to have a class that will be a list you need to use the IEnumerator and IEnumerable interfaces and then it will support the foreach loop.

List should implement IEnumerable and the Iterator should implement IEnumerator.

Mediator

– Do we have a lot of coupling in who must talk to whom.

Define objects in the subsystem where the set of objects interact. This pattern is much similar to the Facade but in facade the sub-system knows nothing about the Facade but here the sub-system communicate through the mediator and the client also communicate through the mediator. Mediator hides the complicated communication in the subsystem where as facade sub-system classes are open to the client as well, So Facade is an optional point of communication where as Mediator is only point of communication to the subsystem.

Typically the class diagram looks like

Example

Now don’t blame me if for the third time I take the example of the control library where we have a dialog and some controls over the dialog. The controls can be interacted through the DialogMediator. Now if the siblings of the Dialog would like to interact they do so through the DialogMediator because its the DialogMediator who has the information about the rest of the sub-system

Memento

Delegate some activity to some other class like some helper classes to do the job.

The memento pattern is used to encapsulate the current state of an object in a memento object in order to be able to restore the object state later without exposing the internal representation of the object to the outside world. The memento pattern is useful when you have an object which you would to take a “snapshot” of so that at a later time you could use the snapshot to restore it to its original state, such as an undo or rollback operation.

Typically the class diagram looks like

Example

Suppose you have a an object which stores form information and you would like to allow the user to make changes in the form and then if they make a mistake later you can put back in the original form values. Well, you could serialize the form object and then un-serialize it later but this is obviously messy and not a good solution. Another possible solution would be to have an outside object use the form’s accessors methods to pull out what you need to save the state but this causes high coupling between the class saving the state and the form; any changes in the form would require changes in the other class. We need something that will allow you to save the state and restore it later without having to get involved in the details. This is where the memento pattern comes in.

Observer

– Do various entities need to know about events that have occurred? How to keep dependent object up-to-date.

When we have one to many dependency between objects so when the object changes, its dependents are notified of the update automatically. The best example is something like Excel with data in one cells and we have multiple charts which gets updated when there is change in the data. This design pattern is more useful if we have one sided broadcast communication and is useful when we have one to many relationship.

Typically the class diagram looks like

Example

When any data is changed in the XMLDoc object it calls the Notify Method of the base class which has the list of the active observers attached to the XMLDoc and calls the Update method of all the view of the data.

State

– Do we have a system with lots of states where keeping track of code for differrent states is difficult.

Allow the object to alter it behavior when its internal state change.

Typically the class diagram looks like

Example

We have a Printer system where we have the following states for the printer and based on the actions taken in particular state, the state of the printer changes accordingly.

Instead of having the state defined in the printer itself we keep the state of the printer into separate object and separate the responsibilities. “Have objects for state.”

Strategy

– Do we have a varying rule or algorithm.

Define a family of algorithms, encapsulate each one and make them interchangeable. It allows us to change the algorithm independently with out changing the client using it. It converts the generalization of the template method to composition or aggregation.

It has various uses like it allows the algorithm to vary frequently and is a very good alternate solution to sub-classing.

Typically the class diagram looks like

Example

We have a payment system where we have an Invoice class where we calculate the total of the amount payable but the requirement is such the amount calculation depends on the type of customer and discount offer. Also over the time the offers / discount may differ and may need to change the offer at run-time. The solution is

Now if have some special offer coming for the season sale all we need to do is add a new class derived from NetPayable and then add the necessary calculation logic in that class and this way we can have the new algorithm added dynamically.

Template Method

– Do we have a skeleton of the algorithm and want to leave upto the sub classes how each step behaves.

Define the skeleton of the algorithm in an operation and deferring the exact implementations of the steps of the algorithms to its subclasses. Template method uses the HR policy of “we will call you” which means the exact implementations of the algorithm will be called by the base class.

Typically the class diagram looks like

Example

Printing algorithm for various types of documents where the algorithm is fixed of printing the header then body and at last the footer which is defined in the base class the exactly how the headers are printed is defined in the supported document classes.

Visitor

– Do we have new tasks that we will need to apply to our existing classes.

Represent an operation to be performed on the element of an object and helps you add new methods to existing hierarchy without affecting the existing hierarchy. This also de-encapsulate where we break the class so that some future functionality can be added but it has the disadvantage that concrete elements cannot be added without changing the interface. Use of the pattern should be done if you have the concrete elements fixed but you may need to add the new functionality to the existing object.

Typically the class diagram looks like

Example

We have the number of objects supported in the drawing system fixed but we need to add the depth in the way the object does it operations like scale or drawing of the object. We could have the same class do both the job but we need some specialist in the field doing the job. A mathematician is good at doing the scaling but not at drawing or vice versa and so here we use the visitor pattern.

Accept method actually calls the correct implementation based on the visitor passed, so its the client who tells if he needs to draw or scale.

GOLDEN RULE(s) of design pattern

  1. Client should always call the abstraction (interface) and not the exact implementation.
  2. Future changes should not impact the existing system.
  3. Change always what is changing.
  4. Have loose coupling
    • Inheritance ( Very coupled )
    • Composition
    • Aggregation
    • Association
    • Dependency
    • Realization ( Least couple )

Strategy Design Pattern

Lets say your in the military and are charged with defending a country. A top general tells you that you need to design a computer system that will activate the military when an invasion happens. You might begin to layout your code like this:

public abstract class Military
{
    public void defend()
    {
        System.out.println("The military is defending!");
    }
}
public class Army extends Military
{
}
public class Defender
{
    public static void main(String[] args)
    {
        Army army = new Army();
        army.defend();
    }
}

This works pretty well to begin with. Assuming the enemy always invades via land since the Army is primarily land based. What happens when the enemy is doing an airborne assault or coming from the sea? It would be handy to have the Air Force take out the enemy airborne aircraft and the Navy to take out the enemy ships before they hit your shores. Your design is modified like so:

For the Army:

public class Army extends Military
{
    public void defend()
    {
        System.out.println("The Army is defending on land!");
    }
}

For the Navy:

public class Navy extends Military
{
    public void defend()
    {
        System.out.println("The Navy is defending on the high seas!");
    }
}
public class AirForce extends Military
{
    public void defend()
    {
        System.out.println("The Air Force is defending the skies!");
    }
}

You implement this as such:

public class Defender
{
    public static void main(String[] args)
    {
        Army army = new Army();
        army.defend();
        Navy navy = new Navy();
        navy.defend();
        AirForce airForce = new AirForce();
        airForce.defend();
    }
}

You see the following results:

The Army is defending on land!
The Navy is defending the high seas!
The Air Force is defending the skies!

Problem solved huh? Not quite… You are quickly reminded by a Navy Admiral that the Navy is also responsible for defending under the water was well as the surface. The Air Force General tells you that they are also responsible for defending threats in outer space. You could modify your code like this for the Navy to start with:

public class Navy extends Military
{
    public void defend()
    {
        System.out.println("The Navy surface fleet is defending the high seas!");
        System.out.println("The Navy submarines are defending under high seas!");
    }
}

The problem is you need to make changes to all the classes to clearly define who defends what, etc. not to mention there might be new branches of the military created as technology changes, etc. The Navy always has at least one ship on the ocean but perhaps the submarine fleet is docked and not always defending since this is a poor country and only has perhaps one submarine. You should maybe use the Strategy Design Pattern to save yourself additional future work and additional maintenance, etc. Lets redesign this!

First we know that each branch of the military for your country has a primary function, to “defend”. Lets take that and move this into it’s own interface like so:

public interface Defend
{
    public void defend();
}

Lets make sure each branch has their primary objective clearly defined (ie: The Air Force primarily will have threats in the skies right now, not space).

Lets add a few classes to handle defending:

public class DefendOnTheOcean implements Defend
{
    @Override
    public void defend()
    {
        System.out.println("We are defending the high seas!");
    }
}
public class DefendUnderTheOcean implements Defend
{
    @Override
    public void defend()
    {
        System.out.println("We are defending under the high seas!");
    }
}
public class DefendTheLand implements Defend
{
    @Override
    public void defend()
    {
        System.out.println("We are defending the land!");
    }
}
public class DefendTheSkies implements Defend
{
    @Override
    public void defend()
    {
        System.out.println("We are defending the skies!");
    }
}
public class DefendSpace implements Defend
{
    @Override
    public void defend()
    {
        System.out.println("We are defending space!");
    }
}

Modify the Military class:

public abstract class Military
{
    private Defend defend;
    public void setTheDefender(Defend defend)
    {
        this.defend = defend;
    }
    public void defend()
    {
        this.defend.defend();
    }
}

Now modify the Army, Air Force and Navy classes:

// Army
public class Army extends Military
{
    public Army()
    {
        setTheDefender(new DefendTheLand());
    }
}
// Navy
public class Navy extends Military
{
    public Navy()
    {
        setTheDefender(new DefendOnTheOcean());
    }
}
// Air Force
public class AirForce extends Military
{
    public AirForce()
    {
        setTheDefender(new DefendTheSkies());
    }
}

Test out the new structure:

public class Defender
{
    public static void main(String[] args)
    {
        Army army = new Army();
        army.defend();
        Navy navy = new Navy();
        navy.defend();
        navy.setTheDefender(new DefendUnderTheOcean());
        navy.defend();
        AirForce airForce = new AirForce();
        airForce.defend();
    }
}

The out output is:

We are defending the land!
We are defending the high seas!
We are defending under the high seas!
We are defending the skies!

Now if the Air Force gets a threat from space we can do this:

public class Defender
{
    public static void main(String[] args)
    {
        AirForce airForce = new AirForce();
        airForce.setTheDefender(new DefendSpace());
        airForce.defend();
    }
}

We see this:

We are defending space!

Lets say now I create a new branch of the military that has responsibilities that can be in the skies, land, or the 4th dimension (their primary domain). We can do this:

public class Defender
{
    public static void main(String[] args)
    {
        UberElite uberElite = new UberElite();
        uberElite.defend();
        uberElite.setTheDefender(new DefendSpace());
        uberElite.defend();
    }
}

Result:

We are defending the 4th dimension!
We are defending space!