Write in detail about Design Patterns?
Design Patterns
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.
Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative scopes. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns. In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which in some cases may complicate the resulting designs and hurt application performance.
By definition, a pattern must be programmed anew into each application that uses it. Since some authors see this as a step backward from software reuse as provided by components, researchers have worked to turn patterns into components. Meyer and Arnout claim a two-thirds success rate in componentizing the best-known patterns.
Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.
Structure
Design patterns are composed of several sections. Of particular interest are the Structure, Participants, and Collaboration sections. These sections describe a design motif: a prototypical micro-architecture that developers copy and adapt to their particular designs to solve the recurrent problem described by the design pattern. A micro-architecture is a set of program constituents (e.g., classes, methods...) and their relationships. Developers use the design pattern by introducing in their designs this prototypical micro-architecture, which means that micro-architectures in their designs will have structure and organization similar to the chosen design motif.
In addition, 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.
Domain specific patterns
Efforts have also been made to codify design patterns in particular domains, including use of existing design patterns as well as domain specific design patterns. Examples include User Interface design patterns, Information Visualization and web design.
The Pattern Languages of Programming Conference (annual, 1994—) proceedings include many examples of domain specific patterns.
Classification
Design Patterns originally grouped design patterns into the categories Creational Patterns, Structural Patterns, and Behavioral Patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern which may be applied at the architecture level of the software such as the Model-View-Controller pattern
2: Explain Design Patterns in Smalltalk MVC.?
The Model/View/Controller (MVC) triad of classes is used to build use interfaces in Smalltalk-80. Looking at the design patterns inside MVC should help you see the meaning of the term pattern.
MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before MVC, user interface designs tended to lump these objects together. MVC decouples them to increase flexibility and reuse.
MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model’s data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it.
Another feature of MVC is that views can be nested. For example, a control panel of buttons might be implemented as a complex view containing nested button views. The user interface for an object inspector can consist of nested views that may be reused in a debugger. MVC supports nested views with the Composite View class, a subclass of View. Composite View objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views.
Again, we could think of this as a design that lets us treat a composite view just like we treat one of its components. But the design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. It lets you create a class hierarchy in which some subclasses define primitive objects (e.g. button) and other classes define composite objects (Composite View) that assemble the primitives into more complex objects.
MVC also lets change the way a view responds to user input without changing its visual presentation. You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. MVC encapsulates the response mechanism in a Controller object. There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one.
A view uses an instance of a Controller subclass to implement a particular response strategy, to implement a different strategy, simply replace the instance with a different kind of controller. It’s even possible to change a view’s controller at run-time to let the view change the way it responds to user input. For example, a view can be disabled so that it doesn’t accept input by giving it a controller that ignores input events.
The View-Controller relationship is an example of the Strategy design pattern. A Strategy is an object that represents an algorithm. It’s useful when you want to replace the algorithm either statically or dynamically, when you have a lot of variants of the algorithm, or when the algorithm has complex data structures that you want to encapsulate.
MVC uses other design patterns, such as Factory Method to specify the default controller class for a view and Decorator t add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns
3: Explain about t Encapsulating Implementation Dependencies in supporting multiple window systems in designing a document editor?
Encapsulating Implementation Dependencies
The Window class encapsulates the things windows tend to do across window systems:
§ They provide operation for drawing basic geometric shapes.
§ They can iconify and deiconify themselves.
§ They can resize themselves.
§ The can (re)draw their contents ion demand, for example, when they are deiconified or when an overlapped and obscured portion of their screen shapes is exposed.
The Window class must span the functionality of windows from different window systems. Lets considered two extreme philosophies:
1. Intersection of functionalities: The window class interface provides only functionality that’s common to all window systems. The problem with this approach is that our window interface points up being only as powerful as the least capable windows system. We cannot take advantage of more advanced features even if most windows systems support them.
2. Union of functionality: Create an interface that incorporates the capabilities of all existing systems. The trouble here is that the resulting interface may well be huge and incoherent. Besides, we will have tio change it anytime a vendor revises it’s window system interface.
Neither extreme is a viable solution, so our design will fall somewhere between the two. The window class will provide a convenient interface that supports the most popular windowing features. Because Lexi will deal with this class directly, the window class must also support the things Lexi knows about, namely, glyphs. That means Window’s interface must include a basic set of graphics operations that lets glyphs draw themselves in the window. The below table gives a sampling of the operations in the window class interface.
Responsibility Operations
Window Management Virtual void Redraw ( )
Virtual void Raise ( )
Virtual void Lower ( )
Virtual void Iconify ( )
Virtual void Deiconify ( )
. . .
Graphics Virtual void DrawLine (…)
Virtual void DrawRect (…)
Virtual void DrawPolygon (…)
Virtual void DrawText (…)
. . .
Window is an abstract class. Concrete subclasses of window support the different kinds of windows that users deal with. For example, application windows, icons, and warning dialogs are all windows, but they have somewhat different behaviors. So we can define subclasses like Application Window, Icon Window, and Dialog Window to capture these differences. The resulting class hierarchy gives applications like Lexi, a uniform and intuitive windowing abstraction, one that does not depend on any particular
Note that we have defined a window interface for Lexi to work with, where does the real platform-specific window come in? If we’re not implementing our own window system, then at some point our window abstraction must be implemented in terms of what the target window system provides. So where does that implementation live.
One approach is to implement multiple versions of the window class and its subclasses, one version each for each windowing platform. We’d have to choose the version to use when we build Lexi for a given platform. But imagine the maintenance headaches we would have keeping track of multiple classes, all named ‘Window’ but each implemented on a different window system. Alternatively, we could create implementation-specific subclasses of each class in the window hierarchy and end up with another subclass explosion problem like the one we have when trying to add embellishments. Both of these alternatives have another drawback: neither gives us the flexibility to change the window system we use after we have compiled the program. So we will have to keep several different executables around as well.
If we encapsulate a window system’s functionality in an object, then we can implement our window class and subclasses in terms of that object’s interface. Moreover if that interface can serve all the window systems we are interested in, then we wont have to change window or any of its subclasses to support different window systems. We can configure window objects to the window systems we want simply by passing them the right window system- encapsulating object. We can even configure the window at a run time.
4: Discuss about design problems in Lexi’s design.?
Below are the seven problems in Lexi’s design:
§ Document structure: The choice of internal representation for the document affects nearly every aspect of Lexi’s design. All editing, formatting, displaying, and textual analysis will require traversing the representation. The way we organize this information will impact the design of the rest of the application.
§ Formatting: How does Lexi actually arrange text and graphics into lines and columns? What objects are responsible for carrying out different formatting policies? How do these policies interact with the document’s internal representation?
§ Embedding the user interface: Lexi’s user interface includes scroll bars, borders, and drop shadows that embellish the WYSIWYG document interface. Such embellishments are likely to change as Lexi’s user interface evolves. Hence it is important to be able to add and remove embellishments without affecting the rest of the application.
§ Supporting multiple look-and-feel standards: Lexi should adapt easily to different look-and-feel standards such as Motif and Presentation Manager (PM) without major modification.
§ Supporting multiple window systems: Different look-and-feel standards are usually implemented on different window systems. Lexi’s design should be as independent of the window system as possible.
§ User operations: Users control Lexi through various user interfaces, including buttons and pull-down menus. The functionality behind these interfaces is scattered throughout the objects in the application. The challenge here is to provide a uniform mechanism both for accessing this scattered functionality and for undoing its effects.
Spelling checking and hyphenation: How does Lexi support analytical operations such as checking for misspelled words and determining hyphenation points? How can we minimize the number of classes we have to modify to add a new analytical operation?
5: Write a brief note on template method behavioral pattern.?
Template method behavioral pattern
The Template Design Pattern is perhaps one of the most widely used and useful design patterns. It is used to set up the outline or skeleton of an algorithm, leaving the details to specific implementations later. This way, subclasses can override parts of the algorithm without changing its overall structure.
This is particularly useful for separating the variant and the invariant behavior, minimizing the amount of code to be written. The invariant behavior is placed in the abstract class (template) and then any subclasses that inherit it can override the abstract methods and implement the specifics needed in that context. In the body of Template Method () (see UML diagram below), there are calls to operation1 () and operation2 (). What it is that operation1 () and operation2 () do are defined by the subclasses which override them.
A common example of this is when writing a program that will handle data using various sorting algorithms. The Abstract Class would have a method called Sort () (analogous to Template Method () -- the invariant behavior) which when called, would use the helper methods in the class, which are specified by any class that inherits from it. The helper methods in this case might be compare () (compares two objects and returns the one that is "higher") and sort Pass () (performs one iteration of a particular sorting algorithm) The interesting thing is that the usual control structure of object calls and relations is reversed. It is the parent class that calls the method in the subclass, a behavior which Richard E. Sweet refers to as the "Hollywood Principle" -- "Don't call us, we'll call you." The Template Design Pattern is of particular use in the Factory Design Pattern
Design Patterns
A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.
Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative scopes. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns. In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which in some cases may complicate the resulting designs and hurt application performance.
By definition, a pattern must be programmed anew into each application that uses it. Since some authors see this as a step backward from software reuse as provided by components, researchers have worked to turn patterns into components. Meyer and Arnout claim a two-thirds success rate in componentizing the best-known patterns.
Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.
Structure
Design patterns are composed of several sections. Of particular interest are the Structure, Participants, and Collaboration sections. These sections describe a design motif: a prototypical micro-architecture that developers copy and adapt to their particular designs to solve the recurrent problem described by the design pattern. A micro-architecture is a set of program constituents (e.g., classes, methods...) and their relationships. Developers use the design pattern by introducing in their designs this prototypical micro-architecture, which means that micro-architectures in their designs will have structure and organization similar to the chosen design motif.
In addition, 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.
Domain specific patterns
Efforts have also been made to codify design patterns in particular domains, including use of existing design patterns as well as domain specific design patterns. Examples include User Interface design patterns, Information Visualization and web design.
The Pattern Languages of Programming Conference (annual, 1994—) proceedings include many examples of domain specific patterns.
Classification
Design Patterns originally grouped design patterns into the categories Creational Patterns, Structural Patterns, and Behavioral Patterns, and described them using the concepts of delegation, aggregation, and consultation. For further background on object-oriented design, see coupling and cohesion. For further background on object-oriented programming, see inheritance, interface, and polymorphism. Another classification has also introduced the notion of architectural design pattern which may be applied at the architecture level of the software such as the Model-View-Controller pattern
2: Explain Design Patterns in Smalltalk MVC.?
The Model/View/Controller (MVC) triad of classes is used to build use interfaces in Smalltalk-80. Looking at the design patterns inside MVC should help you see the meaning of the term pattern.
MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before MVC, user interface designs tended to lump these objects together. MVC decouples them to increase flexibility and reuse.
MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model’s data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it.
Another feature of MVC is that views can be nested. For example, a control panel of buttons might be implemented as a complex view containing nested button views. The user interface for an object inspector can consist of nested views that may be reused in a debugger. MVC supports nested views with the Composite View class, a subclass of View. Composite View objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views.
Again, we could think of this as a design that lets us treat a composite view just like we treat one of its components. But the design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. It lets you create a class hierarchy in which some subclasses define primitive objects (e.g. button) and other classes define composite objects (Composite View) that assemble the primitives into more complex objects.
MVC also lets change the way a view responds to user input without changing its visual presentation. You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. MVC encapsulates the response mechanism in a Controller object. There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one.
A view uses an instance of a Controller subclass to implement a particular response strategy, to implement a different strategy, simply replace the instance with a different kind of controller. It’s even possible to change a view’s controller at run-time to let the view change the way it responds to user input. For example, a view can be disabled so that it doesn’t accept input by giving it a controller that ignores input events.
The View-Controller relationship is an example of the Strategy design pattern. A Strategy is an object that represents an algorithm. It’s useful when you want to replace the algorithm either statically or dynamically, when you have a lot of variants of the algorithm, or when the algorithm has complex data structures that you want to encapsulate.
MVC uses other design patterns, such as Factory Method to specify the default controller class for a view and Decorator t add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns
3: Explain about t Encapsulating Implementation Dependencies in supporting multiple window systems in designing a document editor?
Encapsulating Implementation Dependencies
The Window class encapsulates the things windows tend to do across window systems:
§ They provide operation for drawing basic geometric shapes.
§ They can iconify and deiconify themselves.
§ They can resize themselves.
§ The can (re)draw their contents ion demand, for example, when they are deiconified or when an overlapped and obscured portion of their screen shapes is exposed.
The Window class must span the functionality of windows from different window systems. Lets considered two extreme philosophies:
1. Intersection of functionalities: The window class interface provides only functionality that’s common to all window systems. The problem with this approach is that our window interface points up being only as powerful as the least capable windows system. We cannot take advantage of more advanced features even if most windows systems support them.
2. Union of functionality: Create an interface that incorporates the capabilities of all existing systems. The trouble here is that the resulting interface may well be huge and incoherent. Besides, we will have tio change it anytime a vendor revises it’s window system interface.
Neither extreme is a viable solution, so our design will fall somewhere between the two. The window class will provide a convenient interface that supports the most popular windowing features. Because Lexi will deal with this class directly, the window class must also support the things Lexi knows about, namely, glyphs. That means Window’s interface must include a basic set of graphics operations that lets glyphs draw themselves in the window. The below table gives a sampling of the operations in the window class interface.
Responsibility Operations
Window Management Virtual void Redraw ( )
Virtual void Raise ( )
Virtual void Lower ( )
Virtual void Iconify ( )
Virtual void Deiconify ( )
. . .
Graphics Virtual void DrawLine (…)
Virtual void DrawRect (…)
Virtual void DrawPolygon (…)
Virtual void DrawText (…)
. . .
Window is an abstract class. Concrete subclasses of window support the different kinds of windows that users deal with. For example, application windows, icons, and warning dialogs are all windows, but they have somewhat different behaviors. So we can define subclasses like Application Window, Icon Window, and Dialog Window to capture these differences. The resulting class hierarchy gives applications like Lexi, a uniform and intuitive windowing abstraction, one that does not depend on any particular
Note that we have defined a window interface for Lexi to work with, where does the real platform-specific window come in? If we’re not implementing our own window system, then at some point our window abstraction must be implemented in terms of what the target window system provides. So where does that implementation live.
One approach is to implement multiple versions of the window class and its subclasses, one version each for each windowing platform. We’d have to choose the version to use when we build Lexi for a given platform. But imagine the maintenance headaches we would have keeping track of multiple classes, all named ‘Window’ but each implemented on a different window system. Alternatively, we could create implementation-specific subclasses of each class in the window hierarchy and end up with another subclass explosion problem like the one we have when trying to add embellishments. Both of these alternatives have another drawback: neither gives us the flexibility to change the window system we use after we have compiled the program. So we will have to keep several different executables around as well.
If we encapsulate a window system’s functionality in an object, then we can implement our window class and subclasses in terms of that object’s interface. Moreover if that interface can serve all the window systems we are interested in, then we wont have to change window or any of its subclasses to support different window systems. We can configure window objects to the window systems we want simply by passing them the right window system- encapsulating object. We can even configure the window at a run time.
4: Discuss about design problems in Lexi’s design.?
Below are the seven problems in Lexi’s design:
§ Document structure: The choice of internal representation for the document affects nearly every aspect of Lexi’s design. All editing, formatting, displaying, and textual analysis will require traversing the representation. The way we organize this information will impact the design of the rest of the application.
§ Formatting: How does Lexi actually arrange text and graphics into lines and columns? What objects are responsible for carrying out different formatting policies? How do these policies interact with the document’s internal representation?
§ Embedding the user interface: Lexi’s user interface includes scroll bars, borders, and drop shadows that embellish the WYSIWYG document interface. Such embellishments are likely to change as Lexi’s user interface evolves. Hence it is important to be able to add and remove embellishments without affecting the rest of the application.
§ Supporting multiple look-and-feel standards: Lexi should adapt easily to different look-and-feel standards such as Motif and Presentation Manager (PM) without major modification.
§ Supporting multiple window systems: Different look-and-feel standards are usually implemented on different window systems. Lexi’s design should be as independent of the window system as possible.
§ User operations: Users control Lexi through various user interfaces, including buttons and pull-down menus. The functionality behind these interfaces is scattered throughout the objects in the application. The challenge here is to provide a uniform mechanism both for accessing this scattered functionality and for undoing its effects.
Spelling checking and hyphenation: How does Lexi support analytical operations such as checking for misspelled words and determining hyphenation points? How can we minimize the number of classes we have to modify to add a new analytical operation?
5: Write a brief note on template method behavioral pattern.?
Template method behavioral pattern
The Template Design Pattern is perhaps one of the most widely used and useful design patterns. It is used to set up the outline or skeleton of an algorithm, leaving the details to specific implementations later. This way, subclasses can override parts of the algorithm without changing its overall structure.
This is particularly useful for separating the variant and the invariant behavior, minimizing the amount of code to be written. The invariant behavior is placed in the abstract class (template) and then any subclasses that inherit it can override the abstract methods and implement the specifics needed in that context. In the body of Template Method () (see UML diagram below), there are calls to operation1 () and operation2 (). What it is that operation1 () and operation2 () do are defined by the subclasses which override them.
A common example of this is when writing a program that will handle data using various sorting algorithms. The Abstract Class would have a method called Sort () (analogous to Template Method () -- the invariant behavior) which when called, would use the helper methods in the class, which are specified by any class that inherits from it. The helper methods in this case might be compare () (compares two objects and returns the one that is "higher") and sort Pass () (performs one iteration of a particular sorting algorithm) The interesting thing is that the usual control structure of object calls and relations is reversed. It is the parent class that calls the method in the subclass, a behavior which Richard E. Sweet refers to as the "Hollywood Principle" -- "Don't call us, we'll call you." The Template Design Pattern is of particular use in the Factory Design Pattern
