The Observer Is a Well-Known Design Pattern - Research Paper Example

?DESIGN PATTERNS Design Patterns Affiliation The Observer Pattern The Observer is a well-known design pattern in which a listof objects depending on an object (which is also acknowledged as a subject) is maintained. In this scenario, the observer is the object which depends on the subject. Additionally, this subject automatically informs all the objects (observers) regarding any changes made to the state. In order to inform other objects or observers regarding something attractive taking place, a subject distributes an announcement or message to the observers that exist on the list of the subject. This notification can encompass particular information and facts regarding the topic of the notification. However, the subject can eliminate any of the observers from the list when there is no need for a specific observer to be informed regarding these events or changes with respect to the matter they are registered with the subject. They are used when there is need maintaining constancy and reliability between connected objects while not affecting coupling characteristics of classes. For instance, these patterns can be used when an object needs to be able to inform other objects without having suppositions on the subject of those objects. Moreover, the observer pattern consists of the following elements (Osmani, 2012): Subject: This component is responsible for managing the operation related to observers, such as facilitating, eliminating, or adding observers into the list (Osmani, 2012). Observer: This component is responsible for offering an up to date interface for observers that need to be informed regarding any change (Osmani, 2012). Concrete Subject: This component is responsible for managing transmission and notifications to objects regarding changes to state. It also maintains the state of ConcreteObservers (Osmani, 2012). ConcreteObserver: This component is responsible for establishing and maintaining a reference to the ConcreteSubject. In addition, it also implements a modern interface for the observer to make sure that state is compatible with the subject (Osmani, 2012). Advantages The observer patterns allow software development teams to think effectively about the associations among various elements of software application (Osmani, 2012; Toal, 2012). These patterns also allow software engineers to recognize what application layers have straight associations which could be alternatively replaced with a set of observers and subjects. In this scenario, these patterns can be effectively employed for splitting a software application into a number of smaller, more freely joined components with the purpose of improving code maintenance as well as competency for re-use (Osmani, 2012; Sud, 2013). These patterns are useful for establishing and maintaining a one-to-many dependency between objects (Marakana Inc., 2013). These patterns provide an excellent communication mechanism for instance, when there is a change in the state all the related objects are notified automatically (Marakana Inc., 2013) Disadvantages As discussed above, these patterns support for decoupling however by decoupling various objects, it can frequently turn out to be hard to get assurance that specific components of a software application are working as they are expected to do (Osmani, 2012; Pierry, 2013). It is believed that in these patterns subscribers are relatively unaware of the subsistence of each other as well as are sightless to the price of switching publishers. Hence, because of this dynamic association between objects, it is difficult to track the update dependence (Osmani, 2012; Sud, 2013). 2. The Factory Pattern The Factory pattern is also one of the most important creational patterns, which is concerned with the concept of developing objects. However, it differentiates with other patterns of the base of a property and that is it doesn't openly require software engineers to make use of use of a constructor. On the other hand, a Factory provides software engineers with a broad interface for developing objects. In this scenario, software engineers can state the type of factory object they want to create. This pattern is mainly used when there is need to create an object process that is comparatively complicated for instance, the creation of an object that completely depends on application configuration or dynamic factors (Osmani, 2012). Advantages The Factory pattern can be helpful in a number of situations such as: When the development process of an object or software component is very complex When software development team wants to create diverse instances of objects relying on the environment they are working in (Osmani, 2012). This pattern is very useful when software development team is working with a number of small objects or software modules that have the similar characteristics (Osmani, 2012). These patterns provide a common interface for developing an object (Marakana Inc., 2013). Defer the real development to subclasses (Marakana Inc., 2013). This pattern restricts the knowledge of concrete instances (Marakana Inc., 2013). This is very useful when customers are unable to foresee the class of objects to generate (Marakana Inc., 2013) Disadvantages When this pattern is implemented for the resolution of the wrong type of problem, it can cause a needlessly complexity to a software application (Osmani, 2012). In view of the fact that the process of creating an object is appropriately abstracted within an interface, which can also cause a variety of issues when conducting unit testing. However, it depends on the fact how complex this process can be (Osmani, 2012). 3. The Adapter Pattern The Adapter pattern is used to interpret an interface for a class or an object into an interface that is consistent with a particular system. Basically, Adapters are used to facilitate classes or objects to work together. However, it can be a serious challenge because of their mismatched interfaces. In addition, the Adapter works by interpreting calls to its interface into calls to the actual interface as well as the code necessary to attain this is typically fairly negligible (Osmani, 2012; Pierry, 2013). Advantages: The Adapter class itself wraps an Adaptee, interpreting all calls initiated by the client into the suitable sequence and format of calls (Pierry, 2013). The Adapter is used to adapt the interface of a class or object into another interface that can be used by a client (Marakana Inc., 2013; Sud, 2013). The Adapter facilitates different objects and classes to work together regardless of their incompatible interfaces (Marakana Inc., 2013; Sud, 2013). They are mainly useful in development to glue elements jointly, in particular when 3rd party libraries and components are employed (Marakana Inc., 2013; Sud, 2013). Disadvantages: There can be serious challenges because of mismatched interfaces used in this translation process (Osmani, 2012). This transformation can be time-consuming because it takes a lot of time in translating the one interface into another (Osmani, 2012). References Marakana Inc. (2013). Java Fundamentals Tutorial : Design Patterns. Retrieved June 03, 2013, from http://marakana.com/bookshelf/java_fundamentals_tutorial/design_patterns.html Osmani, A. (2012). Learning JavaScript Design Patterns. Retrieved May 31, 2013, from A book by Addy Osmani: Volume 1.5.2: http://addyosmani.com/resources/essentialjsdesignpatterns/book/ Pierry, R. (2013). Discover the Design Patterns You're Already Using in the .NET Framework. Retrieved June 03, 2013, from http://msdn.microsoft.com/en-us/magazine/cc188707.aspx#S4 Sud, A. (2013). Design Patterns. Retrieved June 02, 2013, from http://wwwx.cs.unc.edu/~sud/courses/204/patterns.html#Adapter Toal, R. (2012). Design Patterns. Retrieved June 03, 2013, from http://cs.lmu.edu/~ray/notes/designpatterns/ Read More