Design patterns can save your day

Last month I was working on inventory control system with my team members. We were developing it using “weighted average” inventory method on SRS prepared BA’s. After few week of development requirements change as no surprise. The management want to develop it’s using both “weighted average” and “first in first out(FIFO)” methods.

So we discussed how to change our design for these new requirements. We were using spring as MVC framework and JPA for ORM. It is client (Java Swing) server application using RMI. After few hours of discussion we decided to write InventoryManagerDao interface and two implementation class called InventoryManagerFifoDaoImpl and InventoryManagerWavgDaoImpl.(Initially we decided to write abstract class but these two inventory methods(FIFO and weighted average) does not have any common methods) 

Our design looks like this

This design looks fine for us. But we had another problem with this design.When we were using this design we have to check which inventory method initially configured. We have to check it using if condition and get the appropriate inventory manager object from few areas (Sales Invoice, GRN, Returns…). It is code duplication. So we decided to give this object creation responsibility to some other class called InventoryHandle.

Now design looks like this.

This design looks maintainable and extensible. Few days later we found that this is almost a design pattern. It is a Factory method pattern.

 

I have read Head First Design Patterns ebook once and I knew few design patterns. But I did not memorize it. We need to know how to apply design pattern with real scenarios. So I decide to follow these design patterns seriously and try to understand and memorize (of course how to apply). Because design patterns can save our day.