Graded Discussion Board for the course 'Software Engineering-I (CS504)' will be open on Tuesday 5th Aug, 2014 and it will be closed on Wednesday 6th Aug, 2014.
Does the design pattern play any important role in the development of quality applications by using structured and object oriented paradigm? Justify your answer with logical reasons.
Read the instructions carefully before sending your comments:
Design patterns are reusable solutions to problems that recur in many applications. A pattern serves as a guide for creating a “good” design. Patterns are based on sound common sense and the application of fundamental design principles. These are created by people who spot repeating themes across designs. The pattern solutions are typically described in terms of class and interaction diagrams. Examples of design patterns are expert pattern, creator pattern, controller pattern, etc.
In addition to provide the model of a good solution, design patterns include a clear specification of the problem, and also explain the circumstances in which the solution would and would not work. Thus, adesign pattern has four important parts:
• The problem
• The context in which the problem occurs
• The solution
• The context withinwhich the solution works
So, design pattern plays an important role!
structured and object oriented paradigm....
In Object Oriented design, the focus is on creating classes that can be used to construct "objects", which can be represented by nouns. Examples of classes in a typical CRM application might be 'Customer', 'Employee', 'Account', etc. The approach focuses on creating methods and properties for each object as a distinct thing in and of itself.
In structural paradigm , the focus is on actions, or subprocedures. Instead of thinking in terms of nouns to code it, you think in terms of actions, i.e. 'when I click this button, it does this, then it does this, then it does this, etc.' By its nature, OOP code is much easier to reuse, and much more portable than structured code,
It is according to the Statement.
The key purpose of design patterns is reuse of experience. When software developers build new systems they are not likely to invent a unique design. Probably they are, without knowing it, using techniques that has been used before but not documented. Instead of reinventing all their design they should be able to imitate already invented designs. This is where design patterns come in. A design pattern is a documented solution to a problem that has been proven to work in a certain design situation. This means that patterns can provide:
A more abstract design vocabulary will help developers communicate more efficient. Consider for instance the design pattern example (see page 4). Even if you have not noticed, it has extended your vocabulary and you are now able to refer a quite complex collection of classes and relationships as a “Composite". This also makes documenting and learning systems easier since we are able to use this more abstract vocabulary. Design patterns also provide means for designing and re-designing systems. Developing object-oriented systems is usually a process that starts with an analysis-phase that evolves into a design-phase. The analysis-phase results in a model that is re-worked during the design-phase to make an implementation model, which has to take into consideration additional details such as programming language, class libraries and so forth. In this design re-work you should be able to identify where a pattern could be applied and then adjust the model using the pattern as a guide that should lead you to an implementation.
There are two major kinds of purpose that design pattern approaches have:
The first constraint imposes that the choice of paradigm is fundamental. Each paradigm has its own design patterns. An imperative design pattern could address a similar problem as an object-oriented design pattern but it would present a solution described in procedures and functions. The paradigm also specifies the scope of patterns. An object-oriented pattern relies on programming language features such as inheritance and encapsulation which could be patterns in other paradigms 3.
I will not include design patterns from other paradigms in this classification mainly of two reasons: