Design concepts.

Problem statement – I am hoping that we all are very much familiar with text Editors (i.e., notepad++, text pad, MS word, etc.). The most important things we do there (apart from copy and pest things from one place to another place) undo and redo. Or for game lovers, many times we perform undo step to rollback our game in previous position. We wish our life could also give these two important command – undo and redo, but unfortunately, it is not there :(  Now the question is, how do we achieve tremendously helping two commands undo and redo? Background – So we have a requirement of storing an object. The question here is, w hat we have understood from OOAD designs; is do not assign any responsibility to any class. If that responsibility is not related to the class's core behavior.  For Instance doing undo and redo is not the core behavior of TextEditor class. So we would implement a class who perform undo and redo for TextEditor class. When we say store the o

Background -  When you want to restrict your class from creating more than one object at a time or when you have a requirement where you want to maintain a single session on web application, who will record all your activity, or a logger application (one logger for all sub modules), please use singleton design pattern. For example –      a.        When you do online shopping. Your global login get create and it remembers all item picked by you during your active session.      b.       We create single log file for any S/W application per day. It will help us to debug issues. It will be very messy if we create thousands of log file on each usages of different module/functionality. Debugging will become hell. We have plenty of examples where we use singleton design patter in our S/W. This is very easy, popular and useful design patter. We can also restrict the number of object to be initialized. For example, I would like to have only 7 objects to get created, any att

Background – First of all, let us understand the meaning of encapsulation. In design terminology, we call any module a box. It could be a black box, or a white box, or a gray box. Depending on its implementation. If you are very new in designing. Please read about the block box from this link.  Other modules should not have any access to any private implementation/logic of this module and vice versa. Let’s understand it through an example .   Praveen is an excellent cryptography programmer. And I am in need to implement cryptography in my module. There are two ways to implement cryptography here. First , I ask Praveen to show me how he writes cryptography code and learn from that and implement it on my own.  Second,  I tell Praveen to give me an executable (or library) implemented by him. So that I can use that library and complete my module. Here Praveen should not let me know how he write cryptography program. If he does so, I may implement it on my own and modify his c

If you have any requirement where a class has to share some of its information (not all). With an external system, or we can say a condition where we have to violate encapsulation. Then we will use two different methods to activate it –            1.        Implicit trusting – Share your class’s private information with an object which is created by your class only. Or object which can be created by your class in the future. For example, iterator design pattern . In many cases, we destroy the object once the job is done. So the life cycle of the object is in your hand. That's why we call it implicit trusting. As you have some kind of control over it, and you are the owner of that object. Destroy it whenever you feel the work gets completed.      2.        Explicit trusting – Share class’s private information with trusted object. Here object is not created by your class. But you have the prior knowledge of object which is requesting your class to know it's inte

Whenever there is a new requirement, or say functional change in your software system. Which has some behavior changes in your software. We achieve it through association or inheritance. There is no doubt that both have their own importance in design. But the question is, "W hich one to choose?"   Simple rule to pick one is – “If the cost of association is less than the cost of inheritance, then use association and vice versa.” OR “If new change is permanent and part of the core behavior of the existing system, then use inheritance, otherwise, use association.” Inheritance comes with a liability. As you have to increase your structure to accommodate some behavioral requirement. That structure will be part of your object always. Doesn’t matter if you are using it, or not using it; all the time, it will be part of your class.  For example – Banking and other industries hav e their own IT services. As all world has moved to IT. It is a permanent change t

Background - Please read the factory concept or skip if you have a good understanding of it. When you have a requirement to run your product on multiple operating systems (i.e., Windows, RedHat Linux, Mac, Solaris, HPUX, etc.), the only difference is how your object is getting created on different platforms. The business logic and look and feel of the product has to remain the same on all OS. You are creating the same set of objects but for different–different OS families. Here you have to handle the creation part as per OS, yes we are talking about a class whose core behavior is to create objects. Whenever you get such kind of situations where the same set of objects are getting created differently depending upon the family, they belong to. You shall start thinking about abstract factory design pattern. Abstract factory design pattern – It is A class-based design pattern (not object-based). Very important for any product where the designer is looking at portability as o

Background - Read-only background section of Factory method design pattern ( only first half ) for more clarity, before you continue with this article. First of all, what do you understand from word factory? Simple, where we create something. Like we build cars, bikes, PC, mobiles, etc., In factories. Same way, we create software objects in the factory. Factory concept is there to achieve creational flexibility. Factory is not only to create objects but to maintain the population of objects as well.  Why do I need a factory to create my object? There are many benefits of creating objects from the factory instead of from class itself.  Quality assurance - There will be many complex objects you will encounter in your project, which had many dependencies and cannot be created without having some dependent object in hand. If you give freedom to the developers. To create objects from wherever they want in the project, then who will guarantee the quality of a complex obje

Background - First, let me ask a simple question. Do you really think that "factory method design pattern comes because we had an issue with creating objects? Or it is only for creating objects? Or why we need a factory to create an object when we can create it through constructor? The answer is NO! Each class is capable of creating objects on its own. Through constructor (until and unless you have not put constructor in private).  Then why we need factory at all? Is there something like, without Factory method, I am not able to create my software? No, we can create objects without it, then why we are using it very extensively? Remember one thing, programming languages are very powerful . W e can build software without following any design principles. But then, it will be poor in some of these areas -  Maintainability. Extend-ability. Performance. Security. Robust. and many more... Developers have been developing software for quite a long time, along wit