Posts

Showing posts from January, 2016

Non-virtual interface idiom (NVI)

In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post cleanups/conditions,

Function overloading is not polymorphism.

Image
Introduction Polymorphism in programing language is to implement an essential non-functional requirement called flexibility. Client should not get affected by any behavioral changes in S/W done by any developer. Many book and articles says that function overloading is a type of polymorphism. Some report says that function overloading is a compile-time polymorphism. If you go by the definition of polymorphism, it says “many forms under one name.” Now see function overloading closely. The name of the function is the same, but the signature of functions are different. Can we call a function by knowing just its name? The answer is no. We have to have a knowledge of its full significance. For example –                                      1.        Int Add(int firstNumber, int secondNumber);                        2.        Float Add(float firstNumber, float secondNumber);                        3.        Double Add(double firstNumber, double secondNumber);          

Mediator design pattern.

Image
Background – This design pattern shows a path and encourage us to find new problem statements (or opportunities) and a simple way to solve them. Solution of a huge problem, for example, how one node in an extensive system is going to talk to another node of the existing system? Shadi.com may be a very classic example of mediator design pattern. Imagine a time before Shadi.com. Or any other matrimonial website. All parents, who desperately want their kids to get married, may like to talk to so many different people (or say, like to see many options). For example, if 100 people are of the same caste (of both gender). And can pair, then it will take factorial 100 (!100) combinations. They can pair ( plus they should be having the address of all other families, to connect and match pairs). Because it is a very tedious job. People quit searching after they reach 10 or 15 options. B ut they don’t want their kid to choose someone of his/her own choice; In India :P. Well, this is a di