What is the Decorator Design Pattern?

The Decorator pattern applies when there is a need to dynamically add as well as remove responsibilities to a class, and when the sub-classing would be impossible due to the large number of sub-classes that could result. Also, use it when you want the capabilities of inheritance with sub-classes, but you need to add functionality at run time.

Intent

• Attach additional responsibilities to an object dynamically.
• Decorators provide a flexible alternative rather than making many subclasses to extend functionality.
• Client-specified embellishment of a core object by recursively wrapping it.
• Wrapping a gift, putting it in a box, and wrapping the box.

Discussion

Say, you are working on a UI and you want to add borders and scroll bars to your windows. You could define the inheritance like… Window class interface, then you have concrete objects WindowWith_Scrollbar, WindowWith_Border etc..  This type of architecture creates a lot of subclasses and not much room for modularity.  It will be hard to change the concrete classes if you want to add some additional functions to them.

The Decorator pattern suggests giving the client the ability to choose what features they want.  There might be a problem of chaining features together to produce custom objects as well. The solution to such problem is to encapsulate the original object inside an abstract wrapper interface. Both the decorator objects and the core object will inherit from the abstract interface. Then the interface uses recursive composition to allow an unlimited number of decorator to be added to each core object.  One thing to note is that the interface must remain constant when successive layers are specified using the decorator pattern.

The decorator pattern hides the core components of the objects inside the decorator object. Trying to access the core object directly would be a problem.

UML Diagram

Example

One example is making a pizza ordering system. You can use the decorator pattern to implement a simple pizza ordering system by creating a pizza(component) and a plain pizza(Concrete Component) that is just the base or dough. Then the decoratorPizza(Decorator) which has the plain pizza and other functions. Lastly, the toppings(Concrete Decorators) for your pizza like: mozzarella, the sauce, pepperoni, etc.

In this example, you have an interface pizza and a plain dough. The decorator then adds the desired toppings to the pizza.

Conclusion

I chose this particular topic since we are creating a simple web app for scheduling classes. I thought that it was helpful since we might be adding pop up windows to our web app.

The Decorator Pattern is useful when you see yourself making something that is extensible and where you can interchangeably choose which components/functions you want on your object.  I think that with the decorator pattern, there is a lot of potential when using it. You could create something that has many functionality and is still easily changeable.

source: decorator pattern

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

What is the Decorator Design Pattern?

The Decorator pattern applies when there is a need to dynamically add as well as remove responsibilities to a class, and when the sub-classing would be impossible due to the large number of sub-classes that could result. Also, use it when you want the capabilities of inheritance with sub-classes, but you need to add functionality at run time.

Intent

• Attach additional responsibilities to an object dynamically.
• Decorators provide a flexible alternative rather than making many subclasses to extend functionality.
• Client-specified embellishment of a core object by recursively wrapping it.
• Wrapping a gift, putting it in a box, and wrapping the box.

Discussion

Say, you are working on a UI and you want to add borders and scroll bars to your windows. You could define the inheritance like… Window class interface, then you have concrete objects WindowWith_Scrollbar, WindowWith_Border etc..  This type of architecture creates a lot of subclasses and not much room for modularity.  It will be hard to change the concrete classes if you want to add some additional functions to them.

The Decorator pattern suggests giving the client the ability to choose what features they want.  There might be a problem of chaining features together to produce custom objects as well. The solution to such problem is to encapsulate the original object inside an abstract wrapper interface. Both the decorator objects and the core object will inherit from the abstract interface. Then the interface uses recursive composition to allow an unlimited number of decorator to be added to each core object.  One thing to note is that the interface must remain constant when successive layers are specified using the decorator pattern.

The decorator pattern hides the core components of the objects inside the decorator object. Trying to access the core object directly would be a problem.

UML Diagram

Example

One example is making a pizza ordering system. You can use the decorator pattern to implement a simple pizza ordering system by creating a pizza(component) and a plain pizza(Concrete Component) that is just the base or dough. Then the decoratorPizza(Decorator) which has the plain pizza and other functions. Lastly, the toppings(Concrete Decorators) for your pizza like: mozzarella, the sauce, pepperoni, etc.

In this example, you have an interface pizza and a plain dough. The decorator then adds the desired toppings to the pizza.

Conclusion

I chose this particular topic since we are creating a simple web app for scheduling classes. I thought that it was helpful since we might be adding pop up windows to our web app.

The Decorator Pattern is useful when you see yourself making something that is extensible and where you can interchangeably choose which components/functions you want on your object.  I think that with the decorator pattern, there is a lot of potential when using it. You could create something that has many functionality and is still easily changeable.

source: decorator pattern

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

The Observer Pattern is an example of a behavioral pattern. In object oriented programming, which most of the application nowadays are built of, you cannot talk about it without considering the state of objects. Object oriented programming is all about object interactions. There are cases where objects needs to be informed about the changes of other objects are often. If you want to have a good design, you would want to have to decouple the objects as much as possible for modularity. The observer pattern might be the best pattern for that job.

The Observer Pattern can be used whenever a “subject” needs to be observed by the concrete objects.

Intent:

• Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

How to Implement Observer Pattern:

• Observable – interface or abstract class defining the operations for attaching and de-attaching observers to the client. In the GOF book this class/interface is known as Subject.
• ConcreteObservable – concrete Observable class. It maintain the state of the object and when a change in the state occurs it notifies the attached Observers.
• Observer – interface or abstract class defining the operations to be used to notify this object.
• ConcreteObserver concrete Observer implementations

It is pretty simple how it works. After creating your subject class, it will then instantiate your ConcreteObservable class and set the states of the objects. Then the Observer class checks if there are any update or notifications from the subject and then update is  called on to the ConcreteObservers.

The observer pattern is used when:

• the changes in one object also happens in other objects without keeping the object tightly coupled.
• or when our design needs to be enhanced in the future with new observers with minimal changes.

Common example of Observer Pattern:

• Model View Controller Pattern – the observer pattern is used in the model view controller(MVC) architectural pattern. In MVC the observer pattern is used to decouple the model from the view. View represents the Observer and the model is the Observable object.

Observer Pattern in UML Diagram:

I selected this topic because I have read many articles and tutorials about this subject, and since I was making a tutorial about it, I might as well write about it in this blog.

The observer pattern is an exceptional pattern to learn in object oriented design in my opinion. Since, most of the programs written these days are object oriented, it is a good resource to know that when you have a one-to-many dependency between objects, it is useful to use the observer pattern. You can use this pattern to create a notification system for your application.

Reference:

Observer Pattern by OODesign

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Builder Design Pattern is an example of a creational pattern. Creational design patterns solves the problem/complexity of object creation in a design by somehow controlling the objects creation.

Builder design pattern is used to create objects that are made from a bunch of other objects. You use the builder design pattern when you want to build an object made out of other objects. Use it when you want the creation of these parts to be independent from the parent object. Hide creation of the parts from the client. Only the builder knows the specifics of the object and nobody else.

Intent of Builder design pattern.

• To separate the construction of a complex object from its parent object so that the same construction process can be created differently in representations.
• Create one of several targets

In a builder design pattern, we have the “director” which invokes the “builder” services as it interprets the external format. The “builder” then creates the object each time it is called. Then, when the product is finished, the client retrieves the results from the “builder”.

Example:

Say the client wants a new remote for your TV, but you know that you’ve already made a remote before and the client wants the same thing but calls it the “remoteX”. You can use your old remote object to pass it in a director to create remoteX by passing it to the remote builder without changing anything from the old remote set up.

Other Useful things to consider:

• Builder can use one of the other patterns to implement which components get built. i.e Abstract Factory, Builder, and Prototype can use Singleton for implementation.
• Builder focuses on constructing the complex object step by step.
• Builder often builds a Composite.

The builder design pattern is really helpful when you are creating objects that are made out of other objects. Just like creating a menu, most menus have a drink, appetizers, and a dessert associated with the meal. You can also use other patterns to implement which components will be built.

I selected this topic because it is one of the main design patterns that is discussed in the Gang Of Four book. It is also pretty simple to understand. The builder design pattern is also a good pattern to have under your belt, since it seems like in the real world we are creating the same objects and upgrading it much more often than creating a new one.

I really think that learning the main or fundamental design patterns is beneficial when creating an application. It just always seem to pop up. Like for our final project, we were thinking of building a class schedule maker, but you can also make the class schedule maker just a regular schedule maker say for appointments or meetings.

https://sourcemaking.com/design_patterns/builder

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

In today’s blog, I will be discussing about a design pattern called the Command Design Pattern.

What is a Command Design Pattern?

Command Design Pattern is a behavioral design pattern in which an object is used to represent and encapsulate all the information needed to perform an action or trigger and event at a later time.

How does it work?

The requests are wrapped as commands and passed to invoker object. The invoker object then looks for the appropriate object which can handle this command and gives the command to the corresponding object that will execute this command. The base class contains an execute() method that simply calls the action on the reciever.

A command class includes some of the following: an object, the method to be applied to the object, and the arguments to be passed when the method is applied.

Command Design Pattern allows you to store lists of code that is executed at a later time or many times. Client do not know what the encapsulated objects are, they just call the Command to run when execute is called.  An object called the Invoker transfers this command to another object called the receiver to execute the right code.

How to Implement the Command Pattern?

First of, you have to create an interface that acts as a command.  Command object knows about the receiver and invokes a method of the receiver.

Second, create your objects(client) that will serve as requests.  The client decides which receiver objects it assigns to the command objects, and which commands it assigns to the invoker.

Third, create concrete command classes(also known as the receiver) that implements the command interface which will do the actual work when the execute() method in command is called.

Lastly, create an invoker object to identify which object will execute which command based on the type of command.  The invoker object does not know anything about the concrete command, it only knows the command interface.

I selected this post because I wanted to learn more about different patterns that is not covered in class. This post shows you what the Command Pattern is and how it works. It also shows you the different steps and an example code on how to use the command design. The diagram above is from the post.

The Command Pattern seems to be very useful when you found yourself using code that looks like:

if (…..)

do();

else if(……)

do();

else if(……)

do();

else if

……..

I think Command pattern is very useful when you are creating an interface where objects are waiting to be executed, just like the menu interface.

https://www.tutorialspoint.com/design_pattern/command_pattern.htm

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

For this blog, I am choosing one from Uncle Bob’s website, the Clean Coder Blog. Almost all of Uncle Bob’s blog are set up like a conversation. Uncle Bob writes questions that the readers might ask, and also answer them for the readers. It is really fun to read his blogs, it is usually short, and might answer some of your questions and give you more insight on the topic that he is writes about.

In his blog called “A Little About Patterns”, Uncle Bob talked a little bit about Design Patterns. In this blog, there were a lot of questions about why we still use Design Patterns that were made from the 90’s. It was mainly about the Design Patterns by the GOF(Gang of Four) book that was made popular in 1995. In the blog, Uncle Bob asked if the “person” could name a design pattern. He then pointed out the book GOF. The person then replied ” But isn’t that kind of old now and outdated?”. Uncle Bob then responded with “Indeed there are many newer books on the topic, and some are quite good; but none are quite so impactful and insightful as the original.”

Throughout the blog, Uncle Bob was just proving that, even though the GOF book was written 20 years ago, it still stands as the best book. He noted that “The Design Patterns book is one of the most important books, if not THE most important book, written about software within the last 20 years. In fact, the fundamentals of software have changed very little in the last four decades.” This just tells us that, even though it might seem like these designs are old, they are still the fundamental of Design Patterns.

Uncle Bob then said that most of the idea of the newer frameworks are old. That they are just Design Patterns. Then he gave this “person” the meaning of a design pattern. “A Design Pattern is a named canonical form for a combination of software structures and procedures that have proven to be useful over the years.”

The blog introduces a couple of newer Design Patterns like Model-View-Controller(MVC) which is a software architectural pattern for implementing user interfaces on computers, and how you can just say this is dependency injection and everybody will understand it in a way.

I chose this blog because it talked about design patterns and how the fundamentals which we are learning in class even if they were written from 20 years ago, are still the very core of Design Patterns. I think that to learn the proper way of using Design Patterns, we should learn about its fundamentals first.

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.