There are plenty of articles that explain what design patterns are, and how to implement them; the web doesn’t need yet another one of those articles! Instead, in this article, we will more discuss the when and why, rather than the which and how.
I’ll present different situations and use-cases for patterns, and will also provide short definitions to help those of you who are not so familiar with these specific patterns. Let’s get started.
October, 2012This article covers some of the various Agile Design Patterns, documented in Robert C. Martin’s books. These patterns are modern adaptations of the original design patterns defined and documented by The Gang of Four in 1994. Martin’s patterns present a much more recent take on the GoF’s patterns, and they work better with modern programming techniques and problems. In fact, about 15% of the original patterns were replaced with newer patterns, and the remaining patterns were slightly modernized.
The factory pattern was invented to help programmers organize the information related to object creation. Objects sometimes have lot of constructor parameters; other times, they must be populated with default information immediately after their creation. These objects should be created in factories, keeping all the information regarding their creation and initialization contained within a single place.
When Use a Factory Pattern when you find yourself writing code to gather information necessary to create objects.
Why: Factories help to contain the logic of object creation in a single place. They can also break dependencies to facilitate loose coupling and dependency injection to allow for better testing.
There are two frequently used patterns to retrieve information from a persistence layer or external data source.
This pattern defines a communication channel between a persistence solution and the business logic. For simpler applications, it can retrieve or recreate whole objects by itself, but object creation is the responsibility of factories in most complex applications. Gateways simply retrieve and persist raw data.
When: When you need to retrieve or persist information.
Why: It offers a simple public interface for complicated persistence operations. It also encapsulates persistence knowledge and decouples business logic from persistence logic.
In fact, the gateway pattern is just a particular implementation of another design pattern that we’ll discuss shortly: the adapter pattern.
There are times when you can not (or do not want to) expose the knowledge of the persistence layer to your business classes. The proxy pattern is a good way to fool your business classes into thinking they are using already existing objects.
When: You have to retrieve information from a persistence layer or external source, but don’t want your business logic to know this.
Why: To offer a non-intrusive approach to creating objects behind the scenes. It also opens the possibility to retrieve these object on the fly, lazily, and from different sources.
A proxy effectively implements the same interface as a real object and mimics its functionality. The business logic simply uses it as if it were a real object, but in fact, the proxy creates the object if one doesn’t exist.
The active object pattern also played a part in early multi-tasking systems.
Okay, okay. That great and all, but how can we find the objects that we need to create?
The repository pattern is very useful for implementing search methods and mini-query languages. It takes these queries and uses a gateway to obtain the data for a factory to produce the objects you need.
The repository pattern is different from the other patterns; it exists as part of Domain Driven Design (DDD), and is not included as part of Robert C. Martin’s book.
When: You need to create multiple objects based on search criteria, or when you need to save multiple objects to the persistence layer.
Why: To let clients that need specific objects to work with a common and well isolated query and persistence language. It removes even more creation-related code from the business logic.
But what if the repository cannot find the objects? One option would be to return a NULL value, but doing so has two side effects:
if(is_null($param)) return;) in your code.A better approach is to return a null object.
A null object implements the same interface of your other objects, but the object’s members return a neutral value. For example, a method that returns a string would return an empty string; another member returning a numeric value would return zero. This forces you to implement methods that do not return meaningful data, but you can use these objects without worrying about refused bequest or littering your code with null checks.
When: You frequently check for null or you have refused bequests.
Why: It can add clarity to your code and forces you to think more about the behavior of your objects.
It’s not unusual to call many methods on an object before it can do its job. There are situations when you must prepare an object after its creation before you can truly use it. This leads to code duplication when creating those objects in different places.
When: When you have to perform many operations to prepare objects for use.
Why: To move complexity from the consuming code to the creating code.
This sounds good, doesn’t it? In fact, it is quite useful in many situations. The command pattern is widely used for implementing transactions. If you add a simple undo() method to a command object, it can track all the undo transactions it performed and reverse them if necessary.
So now you have ten (or more) command objects, and you want them running concurrently. You can gather them into an active object.
The simple and interesting active object has only one responsibility: keep a list of command objects and run them.
When: Several similar objects have to execute with a single command.
Why: It forces clients to perform a single task and affect multiple objects.
An active object removes each command from its list after the command’s execution; meaning, you can execute the command only once. Some real world examples of an active object are:
Design patterns are here to solve problems.
buy() command on each product removes them from the cart.The active object pattern also played a part in early multi-tasking systems. Each object inside an active object would keep a reference to the active object. They would execute a portion of their jobs and then put themselves back into the queue. Even in today’s systems, you can use an active object to let other objects work while you wait for a response from another application.
I am positive that you’ve heard the big promise of object oriented programming: code reuse. Early adopters of OOP envisioned using universal libraries and classes in millions of different projects. Well, it never happened.
This pattern allows for the partial reuse of code. It’s practical with multiple algorithms which only slightly differ from one another.
When: Eliminate duplication in a simple way.
Why: There is duplication and flexibility is not a problem.
But flexibility is nice. What if I really need it?
When: Flexibility and reusability is more important than simplicity.
Why: Use it to implement big, interchangeable chunks of complicated logic, while keeping a common algorithm signature.
For example, you can create a generic Calculator and then use different ComputationStrategy objects to perform the calculations. This is a moderately used pattern, and it is most powerful when you have to define many conditional behaviors.
As projects grow, it becomes increasingly difficult for external users to access our application. That’s one reason to offer a well-defined entry point to the application or module in question. Other such reasons may include the desire to conceal the module’s internal workings and structure.
A facade is essentially an API – a nice and client-facing interface. When a client calls one of these nice methods, the facade delegates a series of calls to the classes it hides in order to provide the client with the required information or desired result.
When: To simplify your API or intentionally conceal inner business logic.
Why: You can control the API and the real implementations and logic independently.
Control is good, and many times you need to perform a task when something changes. Users have to be notified, red LEDs have to blink, an alarm has to sound… you get the idea.
The popular Laravel framework makes excellent use of the Facade Pattern.
A null object implements the same interface as your other objects.
The observer pattern offers an easy way to monitor objects and take actions when conditions change. There are two types of observer implementations:
When: To provide a notification system inside your business logic or to the outside world.
Why: The pattern offers a way to communicate events to any number of different objects.
Use cases for this pattern are email notifications, logging daemons, or messaging systems. Of course, in real life, there are countless other ways to use it.
The observer pattern can be extended with a mediator pattern. This pattern takes two objects as parameters. The mediator subscribes itself to the first parameter, and when a change happens to the observed object, the mediator decides what to do on the second object.
When: The affected objects can not know about the observed objects.
Why: To offer a hidden mechanism of affecting other objects in the system when one object changes.
Sometimes, you need special objects that are unique in your application, and you want to ensure that all consumers can see any change made to these objects. You also want to prevent creating multiple instances of such objects for certain reasons, like long initialization time or problems with concurrent actions to some third party libraries.
A singleton is an object having a private constructor and a public getInstance() method. This method ensures that only one instance of the object exists.
When: You need to achieve singularity and want a cross platform, lazily evaluated solution which also offers the possibility of creation through derivation.
Why: To offer a single point of access when needed.
Another approach to singularity is the monostate design pattern. This solution uses a trick offered by object oriented programming languages. It has dynamic public methods which get or set the values of static private variables. This, in turn, ensures that all instances of such classes share the same values.
When: Transparency, derivabitility, and polymorphism are preferred together with singularity.
Why: To hide from the users/clients the fact that the object offers singularity.
Pay special attention to singularity. It pollutes the global namespace and, in most cases, can be replaced with something better suited for that particular situation.
The repository pattern is quite useful for implementing search methods…
So you have a switch and a light. The switch can turn the light on and off, but, now, you’ve purchased a fan and want to use your old switch with it. That’s easy to accomplish in the physical world; take the switch, connect the wires, and viola.
Unfortunately, it’s not so easy in the programming world. You have a Switch class and a Light class. If your Switch uses the Light, how could it use the Fan?
Easy! Copy and paste the Switch, and change it to use the Fan. But that’s code duplication; it’s the equivalent of buying another switch for the fan. You could extend Switch to FanSwitch, and use that object instead. But what if you want to use a Button or RemoteControl, instead of a Switch?
This is the simplest pattern ever invented. It only uses an interface. That’s it, but there are several different implementations.
When: You need to connect objects and maintain flexibility.
Why: Because it is the simplest way to achieve flexibility, while respecting both the dependency inversion principle and the open close principle.
PHP is dynamically typed. This means that you can omit interfaces and use different objects in the same context – risking a refused bequest. However, PHP also allows for the definition of interfaces, and I recommend you use this great functionality to provide clarity to the intent of your source code.
But you already have a bunch of classes you want to talk to? Yes, of course. There are many libraries, third-party APIs, and other modules that one has to talk to, but this does not mean that our business logic has to know the details of such things.
The adapter pattern simply creates a correspondence between the business logic and something else. We have already seen such a pattern in action: the gateway pattern.
When: You need to create a connection with a pre-existing and potentially changing module, library, or API.
Why: To allow your business logic to rely only on the public methods the adapter offers, and permit changing the other side of the adapter easily.
If either of the above patterns don’t fit with your situation, then you could use…
This is a very complicated pattern. I personally do not like it because it is usually easier to take a different approach. But for those special cases, when other solutions fail, you can consider the bridge pattern.
When: The adapter pattern is not enough, and you change classes on both sides of the pipe.
Why: To offer increased flexibility at the cost of significant complexity.
Consider that you have a script with similar commands, and you want make a single call to run them. Wait! Didn’t we already see something like this earlier? The active object pattern?
Yes, yes we did. But this one is a bit different. It’s the composite pattern, and like the active object pattern, it keeps a list of objects. But calling a method on a composite object calls the same method on all of its objects without removing them from the list. The clients calling a method are thinking they are talking to a single object of that particular type, but in fact, their actions are applied to many, many objects of the same type.
When: You have to apply an action to several similar objects.
Why: To reduce duplication and simplify how similar objects are called.
Here’s an example: you have an application that is capable of creating and placing Orders. Assume you have three orders: $order1, $order2 and $order3. You could call place() on each of them, or you could contain those orders in a $compositeOrder object, and call its place() method. This, in turn, calls the place() method on all the contained Order objects.
Gateways only retrieve and persist raw data.
A finite state machine (FSM) is a model that has a finite number of discreet states. Implementing a FSM can be difficult, and the easiest way to do so involves the trusty switch statement. Each case statement represents a current state in the machine, and it knows how to activate the next state.
But we all know that switch...case statements are less desirable because they produce an unwanted high fan-out on our objects. So forget the switch...case statement, and instead consider the state pattern. The state pattern is composed of several objects: an object to coordinate things, an interface representing an abstract state, and then several implementations – one for each state. Each state knows which state comes after it, and the state can notify the coordinating object to set its new state to the next in line.
When: FSM-like logic is required to be implemented.
Why: To eliminate the problems of a switch...case statement, and to better encapsulate the meaning of each individual state.
A food dispenser could have a main class that has a reference to a state class. Possible state classes might be something like: WaitingForCoin, InsertedCoin, SelectedProduct, WaitingForConfirmation, DeliveringProduct, ReturningChange. Each state performs its job and creates the next state object to send to the coordinator class.
There are times when you deploy classes or modules throughout an application, and you can’t modify them without radically affecting the system. But, at the same time, you need to add new functionality that your users require.
The decorator pattern can aid in these situations. It is very simple: take existing functionality and add to it. This is accomplished by extending the original class and providing new functionality at run-time. Old clients continue to use the new object as they would an old one, and new clients will use both the old and new functionality.
When: You can’t change old classes, but you have to implement new behavior or state.
Why: It offers an unintrusive way of adding new functionality.
A simple example is printing data. You print some information to the user as plain text, but you also want to provide the ability to print in HTML. The decorator pattern is one such solution that lets you keep both functionality.
If your problem of extending functionality is different – say, you have a complex tree-like structure of objects, and you want to add functionality to many nodes at once – a simple iteration is not possible, but a visitor might be a viable solution. The downside, however, is that a visitor pattern implementation requires modification to the old class if it wasn’t designed to accept a visitor.
When: A decorator is not appropriate and some extra complexity is acceptable.
Why: To allow and organized approach to defining functionality for several objects but at the price of higher complexity.
Use design patterns to solve your problems, but only if they fit.
Design patterns help solve problems. As an implementation recommendation, never name your classes after the patterns. Instead, find the right names for the right abstractions. This helps you to better discern when you really need a pattern as opposed to just implementing one because you can.
Some may say that if you don’t name your class with the pattern’s name in it, then other developers will have a difficult time understanding your code. If it’s hard to recognize a pattern, then the problem is in the pattern’s implementation.
Use design patterns to solve your problems, but only if they fit. Do not abuse them. You’ll find that a more simple solution befits a little problem; whereas, you’ll discover that you need a pattern only after you implement a few other solutions.
If you’re new to design patterns, I hope that this article has given you some idea as to how patterns can be helpful in your applications. Thanks for reading!
]]>Page edited by Anna Sniadach
When incorporating files into Blackboard, remember (also remind students) not to use the following Illegal file name characters:
spaces in file names
\ (backslash)
/ (forward slash)
: (colon)
; (semi-colon)
* (asterisk)
? (question mark)
" (double quotes)
< (left angle bracket)
> (right angle bracket)
| (pipe)
% (percent)
, (comma)
# (pound or number)
$ (dollar)
! (exclamation)
+ (plus)
{ ( left bracket)
} ( right bracket)
& (ampersand)
[ ( left square bracket)
] ( right square bracket)
• (bullet)
' (apostrophe)
Was this helpful? Yes | No | Correct or Suggest an Article | Request Help
Dr. Hrabowski speaks at TED2013. Photo by TED2013.
It’s all too easy to take successes for granted, especially when you see them every day around campus. At UMBC, the concept of pushing students of all backgrounds and academic levels to succeed is such a part of campus culture, we sometimes forget that’s not necessarily standard practice at other schools.
So when UMBC President Dr. Freeman Hrabowski, III, challenged audiences at the TED2013 conference in California last month to set higher expectations for all students at all levels of education, we were delighted — but not at all surprised. During his session — which fell within a grouping of talks based around the idea “The Spark” — Hrabowski explained how setting high standards for all students lets many who might otherwise be left behind excel. Case in point, he told the group:
“What makes our story especially important is that we have learned so much from students who are typically not at the top of the academic ladder.”
Read the TED blog’s take on Dr. Hrabowski’s talk.
UMBC sets incredibly high standards for its students. Professors and students know it will take a lot of hard work, but the results speak volumes. Our students and alumni are better for being pushed. Dr. Hrabowski touches on a few such examples in his talk.
Just as we sometimes take successes for granted, it’s also easy for forget that without the financial backing of UMBC’s donors, our efforts would be futile. Thank you for believing in Dr. Hrabowski’s message, and for supporting UMBC’s students!
Page edited by Andrea Mocko
myUMBC usernames/user IDs cannot be changed at this time.
If you want to change your username because of harassment, stalking, or other such factors, contact abuse@umbc.edu to discuss the situation. If you're looking for an alternate email address, you should create an alias.
How do I create an email alias?
Was this helpful? Yes | No | Correct or Suggest an Article | Request Help
From the 2013 Legislative Testimony, Dr Freeman Hrabowski, III, UMBC President
Our campus community is working to address global warming every day. Through our research and academic programs, we are producing knowledge and a new generation of informed citizens and leaders to move Maryland and the nation toward dramatically reduced emissions of greenhouse gases. We are part of the American College & University Presidents’ Climate Commitment. Our Climate Change Task Force has developed an action plan and is actively implementing projects to reduce our carbon footprint on campus and beyond. Through climate change initiatives, the campus has reduced its net emissions by 13.3% over the past five years, a major reduction considering the 15% increase in enrollment and 2% increase in campus square footage during this time period. The additional square footage includes a LEED Gold Certified addition to Patapsco Residence Hall, complete with our campus’s first green roof, as well as Phase 1 of our new Performing Arts and Humanities Building built to LEED Silver standards.
As of 2012, 20% of UMBC’s electricity comes from renewable resources, utilizing our long-term contract with the University System of Maryland. A Chilled Water Optimization project significantly improves the efficiency of the Central Plant and cooling for most of the campus, reducing annual energy usage by 5,700,000 kWh and reducing annual Greenhouse Gas emissions by 3,100 metric tons eCO2. Relative to a baseline year of 2007, this represents a 7% reduction in electricity and 3.5% reduction in carbon footprint.
UMBC hired its first full-time Environmental Sustainability Coordinator in 2012, and the Student Government Association is funding five sustainability interns this year. Student participation in a new composting program and in Recyclemania, a 10-week national competition involving 400 colleges and universities, has boosted the campus’s recycling rate to 28%. The university has also made significant advances in green transportation initiatives, including optimizing UMBC transit service routes and schedules, a new carpooling policy, improved vanpooling and public transit options, and improvements to make the campus more bike- and pedestrian-friendly.
]]>One of the core courses for majors in UMBC’s Gender and Women’s Studies program is our Studies in Feminist Activism class, and it makes sense that we would ask all students to take this one. After all, our program is the result of steady and dedicated activists inside and outside the academy who insisted—and still do—that human knowledge demands that all voices, experiences, research questions, answers, and ideas be heard. Our students have started a blog exploring their own relationships to activism ... (continue reading)
]]>From the 2013 Legislative Testimony, Dr Freeman Hrabowski, III, UMBC President
According to the Higher Education Research & Development Survey, the campus ranks 18th nationally in environmental science research and development expenditures. We recently launched the Goddard Planetary Heliophysics Institute (GPHI) through a Cooperative Agreement with the NASA Goddard Space Flight Center (GSFC) in Greenbelt, Maryland. Based at GSFC, GPHI is a center for collaborative research in solar-planetary sciences linking researchers from UMBC, the University of Maryland, College Park, and American University. The Institute focuses on phenomena ranging from solar wind to sunspots, including the effects that weather on the Sun can have on Earth and our orbiting satellites.
The recent realignment of the former University of Maryland Biotechnology Institute faculty has brought many new scientific and technology-development assets to UMBC. Maryland Sustainable Mariculture (MSM), a spin-off company founded by UMBC marine biotechnology faculty, is currently negotiating with a group of international investors who plan to lease space at the Columbus Center in downtown Baltimore to model marine aquaculture in a public display. Plasmonix, a biotechnology start-up based on technologies licensed from the Institute of Fluorescence, recently received venture capital from the Governor’s “Invest Maryland Challenge” and is now located at bwtech@UMBC, our research and technology park. In addition, our core facilities in mass spectrometry, imaging, and high-performance computing support both faculty research and companies. We work aggressively to create multi-level partnerships that connect faculty and students with companies, agencies, foundations, and school systems – and these partnerships enable us to leverage State funds. For example, we have developed major research centers and other partnerships with support from NASA and from IBM, Lockheed Martin, Northrop Grumman, SAIC, Wyeth Pharmaceuticals, the Department of Defense, the National Security Agency (NSA), and other organizations. Other partnerships with Federal and State agencies have allowed us to leverage State funds and contribute to the policy arena in gerontology (through the Erickson School for Aging, Management, and Policy and the Center for Aging Studies), the environment (through our Center for Urban Environmental Research & Education – CUERE), health care (through our Hilltop Institute), and teacher education (through the Center for History Education, the Center for Excellence in STEM Education, and the Maryland Geographic Alliance).
]]>