JAWAHARLAL NEHRU TECHNOLOGICAL UNIVERSITY HYDERABAD B.Tech III Year DESIGN PATTERNS Previous Question Paper (January/February - 2021 - R16)

A Design Pattern is a proven, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished piece of code that can be transformed directly into an application, but rather a template or description of how to solve a problem that can be used in many different situations. Design patterns provide a shared vocabulary for developers, improve communication, and help in creating more flexible, maintainable, and robust software architectures.

The general template used to describe a design pattern typically includes the following essential sections:

• Pattern Name and Classification: A descriptive name that captures the essence of the pattern and its category (e.g., Creational, Structural, or Behavioral).
• Intent: A brief statement describing the problem and the design goal the pattern addresses.
• Also Known As: Other common names for the pattern, if any.
• Motivation: A scenario or problem description that illustrates the design issue and how the pattern solves it.
• Applicability: Situations in which the design pattern can be applied, including indicators of poor design that the pattern can fix.
• Structure: A graphical representation, usually using UML class diagrams, showing the classes and their relationships.
• Participants: The classes and objects participating in the design pattern and their responsibilities.
• Collaborations: How the participants interact to carry out their responsibilities.
• Consequences: The trade-offs, benefits, and liabilities of using the pattern.
• Implementation: Pitfalls, hints, or techniques to consider when implementing the pattern.
• Sample Code: Code fragments illustrating how the pattern is implemented in a programming language.
• Known Uses: Examples of the pattern found in real-world systems.
• Related Patterns: Other patterns that are closely related or often used in conjunction with this pattern.

Designing a document editor requires a structured approach to manage complex objects like text, graphics, and formatting. The step-by-step procedure involves the following phases:

1. Identify Abstractions: Define the core components of the document, such as characters, rows, columns, and graphics. Use the Composite pattern to represent the document structure as a hierarchy of objects, allowing individual elements and groups to be treated uniformly.
2. Specify Document Structure: Implement a recursive composition where a document is a collection of glyphs. Each glyph is an object that knows how to draw itself and calculate its extent.
3. Define Formatting: Use the Strategy pattern to encapsulate different formatting algorithms (e.g., line breaking, justification). This allows the editor to switch between formatting styles without modifying the document structure.
4. Embellish the User Interface: Apply the Decorator pattern to add borders, scrollbars, or shadows to glyphs dynamically without changing the base classes.
5. Support Multiple Look-and-Feel Standards: Use the Abstract Factory pattern to create UI components (buttons, menus) that adhere to different platform standards (e.g., Windows, Motif) while maintaining a consistent interface.
6. Handle User Operations: Employ the Command pattern to encapsulate user requests (e.g., cut, paste, format) as objects. This facilitates undo/redo functionality and command queuing.
7. Manage Spelling and Analysis: Utilize the Visitor pattern to perform operations across the document structure, such as spell checking or word counting, without adding these operations to the glyph classes themselves.

By applying these design patterns, the document editor achieves high modularity, extensibility, and maintainability. The separation of concerns between data representation, formatting logic, and user interaction ensures that the system can evolve to support new features without requiring significant refactoring.