Software Design Patterns

GRASP (General Responsibility Assignment Software Patterns) consists of 9 fundamental principles for assigning responsibilities to classes in object-oriented design. These patterns include Controller, Creator, Information Expert, Low Coupling, High Cohesion, Polymorphism, Protected Variations, Pure Fabrication, and Indirection. They provide foundational guidance for object-oriented design.

The Gang-of-Four (GoF) patterns are a collection of 23 classic design patterns documented in the book 'Design Patterns: Elements of Reusable Object-Oriented Software' by Gamma, Helm, Johnson, and Vlissides. These patterns are categorized into creational (5), structural (7), and behavioral (11) patterns, providing a foundation for reusable object-oriented design solutions.

GoF (Gang of Four) patterns are organized into three fundamental categories: Creational patterns handle object creation mechanisms, Structural patterns deal with class and object composition, and Behavioral patterns manage communication between objects. Option B correctly identifies these categories despite a minor spelling error.

The Adapter pattern allows incompatible interfaces to work together by converting one interface into another. This supports the Low Coupling GRASP pattern (by reducing direct dependencies) and Polymorphism (by allowing objects to be treated uniformly through a common interface). High Cohesion is not directly supported by Adapter.

The Composite pattern's key concept is representing part-whole hierarchies of objects, allowing clients to treat individual objects and compositions uniformly. This enables tree structures of objects where a parent node can have multiple children. Option A correctly captures this hierarchical representation concept.

The Facade pattern provides a simplified interface to a complex subsystem, hiding its complexity from clients. This reduces coupling and makes the subsystem easier to use. Option C correctly states this purpose. Options A and B incorrectly reference the Adapter pattern.

The Pure Fabrication pattern is a GRASP pattern that creates an artificial class to support high cohesion and low coupling when no existing domain class is appropriate. It helps assign responsibilities that don't naturally fit into domain objects. Option B correctly captures this concept.

GRASP (General Responsibility Assignment Software Patterns) patterns provide fundamental principles for assigning responsibilities to objects during object-oriented design. They are guiding principles rather than concrete solutions or general concepts. Option B correctly identifies their role as guiding principles.

The Polymorphism pattern in GRASP deals with handling variation and alternatives by assigning responsibility to varying behaviors to the types that need them. It determines how a system should handle conditional variations using polymorphic operations rather than explicit conditional logic. Option C correctly identifies this.

The Indirection pattern supports low coupling and reusability by assigning responsibility to an intermediate object that mediates between other components. This avoids direct coupling between components, making the system more flexible and reusable. Option D correctly captures both benefits.

The Information Expert pattern is a GRASP principle that guides responsibility assignment by stating that a responsibility should be assigned to the information expert - the class that has the information necessary to fulfill it. Option D correctly identifies it as providing guiding principles for assigning responsibilities.

The State Pattern allows an object to alter its behavior when its internal state changes, appearing as if the object changes its class. The object delegates state-specific behavior to different state objects, and the current state determines how the object responds to operations. Option C correctly identifies that an object's state determines its response to operations, which is the essence of the State Pattern. Options A and B discuss persistence concerns unrelated to the State Pattern.

The MVC Pattern promotes loose coupling between the Model (data and business logic), View (presentation), and Controller (input handling). This separation allows new clients to be integrated by creating new views and controllers that work with existing models, or by extending models with new business logic while reusing views and controllers. Option A correctly identifies this separation as enabling easy integration. Option B is wrong because hard-coding client-specific logic in the controller violates MVC principles. Option C incorrectly suggests the pattern anticipates future clients. Option D describes controller-model relationships but not the integration benefit.

The Model-View separation principle ensures that business logic (Model) is independent from presentation logic (View), allowing changes to the UI without affecting business rules and vice versa. This separation enhances maintainability, testability, and reusability. Option B correctly identifies independence of business logic as a key benefit. Option A incorrectly suggests space is the concern. Option C misidentifies testing as the primary purpose, though separation does facilitate testing. Option D incorrectly refers to performance role definition rather than separation benefits.

This question tests understanding of MVC relationships. Options A, B, and C all describe genuine MVC concepts: A acknowledges the pattern introduces more classes due to separation, B correctly states views access data through models, and C accurately states application logic should not reside in UI methods. Option D claims Model-View separation minimizes interface changes' impact on the controller layer, which is misleading. Model-View separation primarily isolates business logic from presentation. The controller layer sits between them and handles input, but the principle specifically addresses decoupling Model from View, not interface-to-controller relationships.

The Representing Objects as Tables persistence pattern maps each persistent object class to a corresponding database table, with object attributes mapping to table columns. This direct mapping enables straightforward persistence of object-oriented data to relational databases. Option B correctly states the pattern defines a table for each persistent object class. Option A describes the PersistenceFacade pattern. Option C refers to identity mapping, which is a related but distinct concept. Option D describes materialization, another related pattern.

The PersistenceFacade pattern provides a simplified, unified interface to a complex persistence subsystem, hiding the complexity of various persistence mechanisms behind a single API. Clients interact with the facade rather than directly with individual persistence components. Option A correctly identifies the facade's purpose of providing a uniform interface. Option B describes the Factory pattern or creation responsibilities. Option C refers to materialization patterns. Option D describes caching responsibilities, which are not the facade's primary role.

The Observer pattern (also called Publish-Subscribe) defines a one-to-many dependency between objects, so that when one object changes state, all its dependents are notified and updated automatically. Publishers (subjects) maintain a list of subscribers (observers) and notify them of state changes. Option C correctly identifies this as the publish-subscribe model and notes that events can have zero subscribers (publishing is independent of subscription). Option A incorrectly limits notification to a single class. Option B incorrectly suggests Observer merges data and display into one entity, when it actually separates them. Option D is incorrect since option C is valid.