ME.Dev

In this post and coming posts, you will get inside scoop on patterns and OOP .  Patterns have great deal to say about OOP and about how to improve your object-oriented experience. Sometimes objects doesn't fit together as they should, a class may have changed, or an object turns out to be too difficult to work with. We will introduce you a rescue by converting two design pattern, Adapter Pattern and Facade Pattern . The Adapter Pattern: It lets you adapt what an object or class has to offer so that another object or class can make use of it. It lets you adapt what an object or class exposes to what another object or class expects. Adapter pattern lets you fix the interface between objects and classes without to modify the objects or classes directly. It lets you convert the interface of a class into another interface the clients expects. Adapter pattern lets classes work togthter that couldn't otherwise because of incompatible interfaces. Although the official de...

This post will talk about another pattern is all about restricting object creation like Singleton Pattern , but this time it gives the rest of your code the feeling of multiple objects. Flyweight Pattern : It is called flyweight because instead of having to work with many massive, individuals objects, you reduce them to a smaller set of more generic objects, that can be configured at runtime to look like more plentiful, massive objects. Each massive object consumes system resources, by extracting what is generic from those massive objects and relying on runtime configuration to mimic those massive objects, you save the system resources. You take all the specialized contents out of the massive objects to create flyweight objects. When you do that, you end up with more-generic objects, and you can reduce the number you need - possibly down to just one - which can be configured as need at run time to mimic the larger set of more massive objects. The Flyweight pattern must use sh...

In the previous post  we explained chain of responsibility pattern, this post we will be about taking control of the number of objects you have floating around in your code.There are two pattern, Singleton Pattern and Flyweight Pattern . Singleton Pattern: It is all about making sure that you can instantiate only one object of a particular class, if you don't use a pattern like this one,the new operator just keeps on creating more and more objects of the same class. Using singleton pattern make sure you only have one object, no matter how many times someone's code tries to create more objects. You use it when you want to either restrict resource use, or when you have a sensitive objects whose data shouldn't be accessed by multiple instances. Also you can use it when you want to restrict the number of objects created because you want to share the data in those objects and you don't want to create multiple objects, which might confuse access to that data. Creatin...

In previous post we  discovered one of design patterns that keep your object  know when something has happened and passing a notification to an observer, Observer Pattern, this post will explore another one. Chain Of Responsibility Pattern like observer pattern it lets you notify objects of change, but this time, the objects are connected in a chain, in series. The notification goes from one object to the next until an object is found that can handle the notification. This pattern is all about connecting objects in a chain of notification; as a notification travels down the chain, it is handled by the first object that is set up to deal with the particular notification. This pattern should " Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. " You use this pattern when not all your observers are created equa...

We talked about Factory pattern in previous post  ,in this post we will discover one of design patterns that keep your object  know when something has happened and passing a notification to an observer. Actually there is two design pattern do this job, Observer Pattern and Chain of Responsibilities pattern . Observer Pattern : It lets several observer objects be notified when a subject object is changed in some way, each observer registers with the subject and when a change occurs the subject notifies them all in parallel (yes at the same time). The observer design pattern should " define a one-to-many dependency between objects so that when one object changes state, all its dependants are notified and updated automatically  ". You should consider the observer design pattern when you have an object that can cause events to occur - events that you want other objects to know about. Instead of writing everything in one monolithic class, consider ...