CS504 Software Engineering - I GDB Solution, Spring 2014

Discussion Topic

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.

Answer:

Design patterns play many roles in the object-oriented development process: they provide a common vocabulary for design, they re-duce system complexity by naming and defining abstractions, they constitute a base of experience for building reusable software, and they act as building blocks from which more complex designs can be built. Design patterns can be considered reusable micro-architectures that contribute to overall system architecture. We describe how to express and organize design patterns and introduce a catalog of design patterns. We also describe our experience in applying design patterns to the design of object-oriented systems.

Answer:

1. Design patterns can speed up the development process by providing tested, proven development paradigms.

2. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.

3. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.

4. patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.

5. Design patterns are well-thought out solutions to programming problems. Many programmers have encountered these problems before, and have used these 'solutions' to remedy them. If you encounter these problems, why recreate a solution..

Answer:

Why are Design Patterns Important?

Short: They help us solve recurring design problems.
Note that : design patterns don’t solve the problem themselves, they help us solve the problem.

Detailed answers:

Communication, Learning and Enhanced Insight: Over the last decade design patterns have become part of every developer's vocabulary. This really helps in communication. One can easy tell another  developer on the team, “I’ve used Command pattern here” and the other developer understands

not just the design, but can also easily figure out the rationale behind it. Design Patterns really help in learning, esp. when you are new on a project. Also this helps in providing developers with better insight about parts of the application or 3rd party frameworks they use.

Decomposing System into Objects : The hard part about OO Design is finding the appropriate objects and decomposing a system. One has to think about encapsulation, granularity, dependencies, flexibility, performance, evolution, reusability and so on. They all influence decomposition, often in conflicting ways.

Design Patterns really helps identify less obvious abstractions. These objects are seldom found during analysis or even the early design, they’re discovered later in the course of making a design more flexible and reusable.

Determining Object Granularity: One thing I struggle a lot with is finding the right level of abstraction and granularity. Design patterns helps in coming up with objects with diiferent levels of granularity that makes sense.

Specifying Object Interface : Identifying the right interface and the relationship between various interface is not a one-shot activity. Usually it takes several iterations to identify the right composition of interfaces. Forget interfaces, most of the times, coming up with a method signature can also be quite

tricky. Design Patterns really helps in this area.

Specifying Object Implementation : How should we implement an Object? Given an interface there could be multiple concrete classes of that type, each one can have very diiferent implementations. Design Patterns provide guidance like Program to an interface (type) not an implementation (concrete class) which can result in really good OO code.

Ensuring right reuse mechanism : When to use Inheritance, when to use Composition, when to use Parameterized Types? Is delegation the right design decision in this context? There are various questions that comes to a programmer's mind when they are trying to design highly reusable and maintainable

code. Knowledge of design patterns can really come handy when making such decisions.

Relating run-time and compile time structures : An object oriented program’s run-time structure often bares little resembles to this code structure.

Sometimes looking at the code does not give us the insights into run-time structure. Knowledge of design patterns can make some of the hidden structure obvious.

Designing for change : We all know that lack of continuous refactoring and design that doesn’t take change into account risks major redesign in the future. Over the years we’ve also learnt that big upfront designs can’t standup against the constant change/additon of software requirements. We’ve leant

grouping elements with similar change life cycle together yields in far more flexible and extendable design. If we think some behavior or element of behavior is most likely to change, we try to abstract that behavior in one place. While we understand these concepts are important design patterns really make it possible to design such systems. Each design pattern lets some aspect of the system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.

Answer:

The purpose of design patterns

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

·         means for documenting and learning systems

·         means for designing or re-designing new systems

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:

·         frameworks related approaches

·         general approaches