“A pattern is a description of a common problem and provides likely solutions within a given context, Software Design.”
-whm
A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns. In addition to this, patterns allow developers to communicate using well-known, well-understood names for software interactions.
In order to achieve flexibility, design patterns usually introduce additional abstract levels, which in some cases may complicate the resulting designs and hurt application performance.
It is easier to understand design patterns when being exposed to an example…
In this example we’ll use a structural pattern most commonly referred to as a wrapper but may also be referenced to as an adapter. A wrapper/adapter for this sake we’ll use the term wrapper lets classes work together that could not otherwise because of incompatible interfaces. For instance, you have two alarm clocks, you want to retrieve the time from Clock2 but the user is only used to the method exposed by the Clock1 interface, which Clock2 implementation does not provide. This is a prime example where a wrapper could be implemented.
/**
* Inherits interface of Clock1, the interface the user is used to communicating with
* It adapts Clock2 interface into that of Clock1
*/
public class TimeAdapter extends Clock1{
private Clock2 clock;
public TimeAdapter(Clock2 clock){
this.clock = clock;
}
public String getTime(){
return clock. getTimeNow();
}
}
/**
* Clock1 interface user is used to communicating with
*/
public Clock1 class{
public String getTime(){
return sensor1.time()*100;
}
}
/**
* Clock2 interface user is not used to communicating with
*/
public Clock2 class{
public String getTimeNow(){
return sensor.usb0.getCurrent.time();
}
}
Another technique that could have been used would be to make developers implement a common interface, though it is unlikely that pre-existing code repository will have this. An adapter exposes the members of a particular class in an invariant manner, helping to increase code readability, though it increases the time required on a development project.
Extra reading: http://userpages.umb...Adapter-2pp.pdf
This post has been edited by foofo: 28 February 2012 - 10:57 AM

New Topic/Question
This topic is locked



MultiQuote







|