Design Patterns – Factory Method



The Factory Method as defined: “Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses“. The main point of using this design pattern is to use an interface to hide the class and use an abstract factory method (from an inherited abstract or concrete class) to create composition of the actual class.

Download the source sample: here

Basically, I created a schedule object that will generate a family schedule. We have an interface class to impose the factory method. Then an Abstract Class to hide the actual initialization of the derived class.
if looked carefully. We can see that once we initialize the Concrete Class – it calls the Abstract Class constructor that defers the process of constructing to the createSchedule() method. This brings more security to our code in terms of the creation of the concrete class, we can use this pattern to create objects that has commonality in terms of its composition (common interface / abstract class).

Design Patterns – Abstract Factory


By Definition, Abstract Factory is “Provide an interface for creating families of related or dependent objects without specifying their concrete classes.“. This simply means that this design pattern is made to hide the actual derived class and create a new layer (or wrapper) that will create the actual instance of this classes. The groupings of classes will be based on their relationship and commonality among its features.

I create a Java code that will showcase the design patterns benefit. The example I made is based on a real world scenario where person types are created for the factory business that needs them.

Download the code: here

 

Checking at the code. The PeopleFactory is an abstract “wrapper” class created to host the creation of Person Objects. As seen, the PeopleFactory provides the layer of security as it hides the actual class implementation / initialization.

My Cent: Abstract Factory do protect the actual implementation / derived class by encapsulating from the other layers of the application. Yet It does have one disadvantage in terms of flexibility: Its made of an abstract class. As every developer should know, abstract class are also extensions of derived class – inheritance of a derived class. OOP only supports single inheritance and that makes the actual factory class not flexible enough.

What do you think is the best replacement for an Abstract class in this case?

EJB – Architectural Patterns – Session Facade


Session Facade – The most commonly used of all EJB Design Pattern. This Design Pattern is almost mandatory for all EJB Application.

This approach is somehow the most generic form of design consideration, its basically putting another layer of service abstraction on the model side that will handle client request. The abstracted layer is formed to support the application’s use case scenario. How about an example of a bank withdraw and transfer use case:

The user tries to withdraw money from Account 1 and Transfer money to Account 2.

Sequence Diagram without Session Facade on the Model Layer:

This seem to be a fine process right? We’re actually calling the model from the controller.

Well, MVC really is a good thing to consider, the overall picture suggest that we are actually seperating each layers concern – view for the presentation, controller for the servlets, model for database transactions.

Yet that’s just 50% of the actual architecture problem we solved. How about considering: Network overhead? poor concurrency? tight coupling? reusability? maintainbility? development practice? How will these problems affect the users transaction?

Network Overhead problem: We are actually calling each functionality from the model one at a time on the servlet level (client side), we are passing data through the network each time a person logs in with a valid credentials). You called more than 1 functionality over the network for a use case, now what if I have 5000 users simultaneously logs in?

Poor Concurrency Problem: What if one of the processes / transactions from the servlet broke down? What if the network was out right in the middle of the process?

Tight coupling Problem: The servlet is actually calling the bean, what if there are changes to the bean in the future? We might need to change client as well if these happens right? – and that’s not good.

Reusability Problem: What if a future functionality needs the user validation process? How do we re-use the existing functionality?

Maintainability Problem: Since we put all our model calls on the servlet, we need to implement a transaction API on it (commit and rollback process). Would it be much more easier if we implement a new layer for this so that we can tweak them without affecting business cases on the client side?

Development Practice Problem: Sure we did put the model calls on the servlet, yet the actual business logic is still in the controller, thus development roles (jsp/servlet and ejb developers) separation will not be as easy as it could be.

MVC alone will just give you the overall separation for each layers, yet that only solves coupling between layers (and possibly not so losely). We still need to improve our architectural structure to solve recurring problems (above) on Enterprise Application Development.

Session Facade solves these problems by creating a new layer of abstraction in-between the Controller and Model, to wrap business cases and hide actual implementation calls. This process will clearly separate our client from the model.

Sequence Diagram with BankTeller SessionBean (Facade).

Obviously, Enterprise Software applications has different business process and rules to support. Using Session Facade approach, developers can wrap functionalities from use cases and create Session Beans to support each (Maybe, investment fund or loan services?).

Alright, so what did putting another layer yield’s to our application development? Obviously:

Lower Network Overhead: Since we are now just throwing one request for multiple process, we actually minimized the network overhead.

Concurrency: Since we are calling the bean only once, concurrency issues will be minimized. Transactions will now be placed on an independent layer thus can be more controlled and contained.

Low Coupling: We have separated the client from the model by putting another layer in between. this gives flexbility to the application when a large functionality will be implemented.

Re-usability: Since we wrap a certain process in a Session Facade, we can re-use that facade for future functionalities.

Maintainability: Separation brings maintainability across layers, its far more easier to maintain a layered application since developers can clearly see the overall picture.

The Session Facade is a mandatory design pattern in EJB development. Its the most basic form of enterprise software development pattern that will clearly solve many recurring issues. The separation obviously is the key to its long standing approach and the concept of “one request for multiple process” clearly helps Networking Overhead issues.

Reference: EJB Design Patterns by Floyd Marinescu