Need of abstraction and Most commonly used practical design patterns in building key software systems

1.Introduction In this small article, I will try to explain briefly about design patterns briefly, and most practically used design patterns(patterns I have used), in building systems using java programming language. This article is divided into two parts first part introduces the subtle concepts of abstraction in contemporary object-oriented programming and also on how abstraction was acheived in procedural programming in earlier days, second part tries to illustrate most commonly used design patterns used in building system's and also illustrates how these design patterns address the issues in the earlier section. 2. Why do we need abstraction within our program's? Is abstraction within programs a new buzz word, introduced by the contemporary object oriented programming methodology?, the answer to the above question is NO. Abstraction was implicitly used in programming from the earlier days. We illustrate this from the following quote by Tanenbaum. "Seperate the policy from mechanism",Andrew.S.Tanenbaum in his book on "Operating system design concepts", when he tries to explain on how to implement security and scheduling components within the operating systems. Tanenbaum says that in building key software systems like the operating systems, which should be adaptable to various customizations (security/secheduling) at the run time. The implementors of these systems should program the system in such a way that the implementation is not aware of the runtime customization, this allows the users to have multiple security policies which use the same underlying mechanism, implemented within the operating system. Tanenbaum is implicitly provoking the need of abstraction in building key software systems. So let me ask the question, Why do you think these people want to use abstraction?. The answer to this question is "REUSE, DONT RE-INVENT THE WHEEL" (yep Iam shouting). In the above scenario you are reusing the operating systems security mechanism, when ever you add a new security policy to the system. Let me further make you realize the need of abstraction in building systems. Suppose as a programmer you have been asked to build a 'HTTP Server', later after some time you were asked to build a 'SMTP Server'. So what do you do? start building the 'SMTP Server' right from scratch? as a dumb programmer or as an average intelligent programmer would you like to use some of the stuff from your earlier code?, I think you may want to stick to the latter. Now how do you proceed further?. Would you like to copy the code from the earlier program and try to change the protocol handling stuff to realize the 'SMTP Server'?. Yes this may seem a workaround for small programs. As an intelligent programmer this might seem very odd way of doing things (reusing). So you start finding a workaround on how to acheive this in an elegant manner. Ok you are not the first programmer who is asking this question. Great programmers have been asking this kind of questions to themselves from past several years. This question which the programmers had asked themselves had a revolution on how we write programs to build complex systems. So if you wanted to reuse the existing 'HTTP Server' logic, then you should have written the 'HTTP Server', In such a way that it can be reused. ie you should change the way you write code, and analyze the system. You should try to separate the generic logic within in the programs from specific logic to accomplish a particular task. In this case of 'HTTP Server' and 'SMTP Server', the logic which handles the clients requests ( while(Wait_For_Client){ fork_a_thread_to_handle_the_request; OR Use_thread_from_thread_pool; dispatch_request_to_worker_thread; }). The latter logic is common for both 'HTTP Server' and 'SMTP Server'. In order to reuse the above logic, we should make sure that the logic is not aware of what server it is (ie.. the logic should be unaware of whether its processing HTTP or SMTP. So while writing the server code we should seperate application specific stuff from generic stuff. In the contemporary object-oriented methodology we call this separate the interface from the implementation. In the next post I will, expand on this and design patterns. Let me know if this is motivating to learn about the intricacies of abstraction.