CSC/ECE 517 Fall 2010/ch7 7c DF: Difference between revisions
No edit summary |
|||
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
'''Pure Fabrication pattern''' | ='''Pure Fabrication pattern'''= | ||
== Introduction == | == Introduction == | ||
The [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] design patterns suggest methods in which the responsibilities of a system can be distributed amongst classes. One of these is the pure fabrication principle, which guides the creation of classes that are not directly represented within a system's problem domain. Pure fabrication indicates that such extra classes should be created when there are responsibilities that do not fit well within any objects. By fabricating these extra classes, the designer is able to maintain a higher level of cohesiveness with less coupling than would be the case if the responsibilities were relegated only to the classes directly related to the problem domain. | The [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] design patterns suggest methods in which the responsibilities of a system can be distributed amongst classes. One of these is the pure fabrication principle, which guides the creation of classes that are not directly represented within a system's problem domain. Pure fabrication indicates that such extra classes should be created when there are responsibilities that do not fit well within any objects. By fabricating these extra classes, the designer is able to maintain a higher level of cohesiveness with less coupling than would be the case if the responsibilities were relegated only to the classes directly related to the problem domain. | ||
== Role in Doman Driven Design == | == Role in Doman Driven Design == | ||
The process of [http://en.wikipedia.org/wiki/Domain-driven_design domain driven design] heavily utilitizes the principles of pure fabrication. It is a process for system design which focuses on the core model of the problem domain. Domain-driven design results in a hierarchy of abstractions, the highest level of which are aggregate elements. Each aggregation represents a top-level component in the problem domain and is manipulated by a set of services. These services implement responsibilities required by the system; however, they are distrinct from the model aggregations derived from the problem domain. As such, they are implementations of the pure fabrication pattern which are created during the design of the system to maintain high cohesion of the domain's aggregations while minimizing coupling between them. | |||
<center> [[Image:Domainservices.png]] </center> | <center> [[Image:Domainservices.png]] </center> | ||
The figure above represents a simple set of model aggregates and services that could form part of | The figure above represents a simple set of model aggregates and services that could form part of a shopping system after it has been through a domain-driven design process. In this situation, customers and orders are the basic aggregates required by the problem domain. Each of these classes is responsible only for storing and managing data specifically contained within themselves. The application is able to perform all desired actions by invoking services on the relevant aggregate data models. Unlike aggregates, these services were created during the design process utilizing pure fabrication specifically to allow the aggregates to be highly cohesive and all but eliminate coupling between them. | ||
== Usage == | == Usage == | ||
| Line 14: | Line 14: | ||
=== Model/View/Controller === | === Model/View/Controller === | ||
One of the most common uses of the pure fabrication pattern is in the model/view/controller ([http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller MVC]) architecture. In this situation, both the model and the view are typically extracted directly from the system requirements which define both what needs to be processed by the system and how it should be displayed to the user. The system requirements also specify what actions the need to be implemented; however, the actual organization of such actions is left up to the system designer. As | One of the most common uses of the pure fabrication pattern is in the model/view/controller ([http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller MVC]) architecture. In this situation, both the model and the view are typically extracted directly from the system requirements which define both what needs to be processed by the system and how it should be displayed to the user. The system requirements also specify what actions the need to be implemented; however, the actual organization of such actions is left up to the system designer. As suggested by the pure fabrication principle, the actions are extracted into seperate controller classes. A simple MVC architecture for the interactions between two users can be seen below. | ||
<center> [[Image:MVC_PureFabrication.png]] </center | <center> [[Image:MVC_PureFabrication.png]] </center> | ||
In this example, users may view other user's profiles to see their personal information as well as the message most recently recieved from them. The UserData class encapsulates data residing in the model while the ProfileDisplay class handles the intricacies involved in the view. The actions available in the system are edit, message, and ignore, none of which fit cohesively into either the model or the view. Thus, the pure fabrication principle is applied to create a seperate controller class responsible for implementing each of the possible actions. This results a new class created solely for the purpose of maintaining higher cohesion and lower coupling among the model and view. | |||
=== Factory === | === Factory === | ||
The [http://en.wikipedia.org/wiki/ | The [http://en.wikipedia.org/wiki/Factory_pattern Factory] design pattern is another common occurence in systems design which makes use of the pure fabrication principle. In this pattern, a common factory class is used to create objects of the appropriate type. While the objects created by a factory are concepts in the problem domain, the factory itself exists only to abstract the process of object creation. This increases cohesion in the objects by allowing them to focus on their core functionality and reduces unneccessary coupling with services that need to create them. | ||
== Summary == | == Summary == | ||
| Line 29: | Line 31: | ||
[http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design - Wikipedia] | [http://en.wikipedia.org/wiki/Domain-driven_design Domain Driven Design - Wikipedia] | ||
[http://en.wikipedia.org/wiki/ | [http://en.wikipedia.org/wiki/Factory_pattern Factory Pattern - Wikipedia] | ||
[http://www.mindspring.com/~mgrand/pattern_synopses2.htm Grand, Mark. ''Preview of Patterns in Java Volume 2''] | [http://www.mindspring.com/~mgrand/pattern_synopses2.htm Grand, Mark. ''Preview of Patterns in Java Volume 2''] | ||
Latest revision as of 04:45, 8 December 2010
Pure Fabrication pattern
Introduction
The GRASP design patterns suggest methods in which the responsibilities of a system can be distributed amongst classes. One of these is the pure fabrication principle, which guides the creation of classes that are not directly represented within a system's problem domain. Pure fabrication indicates that such extra classes should be created when there are responsibilities that do not fit well within any objects. By fabricating these extra classes, the designer is able to maintain a higher level of cohesiveness with less coupling than would be the case if the responsibilities were relegated only to the classes directly related to the problem domain.
Role in Doman Driven Design
The process of domain driven design heavily utilitizes the principles of pure fabrication. It is a process for system design which focuses on the core model of the problem domain. Domain-driven design results in a hierarchy of abstractions, the highest level of which are aggregate elements. Each aggregation represents a top-level component in the problem domain and is manipulated by a set of services. These services implement responsibilities required by the system; however, they are distrinct from the model aggregations derived from the problem domain. As such, they are implementations of the pure fabrication pattern which are created during the design of the system to maintain high cohesion of the domain's aggregations while minimizing coupling between them.
The figure above represents a simple set of model aggregates and services that could form part of a shopping system after it has been through a domain-driven design process. In this situation, customers and orders are the basic aggregates required by the problem domain. Each of these classes is responsible only for storing and managing data specifically contained within themselves. The application is able to perform all desired actions by invoking services on the relevant aggregate data models. Unlike aggregates, these services were created during the design process utilizing pure fabrication specifically to allow the aggregates to be highly cohesive and all but eliminate coupling between them.
Usage
As a general guiding principle for software design, the influence of pure fabrication can be seen in many design patterns. Most notably, the MVC and Factory patterns deal with the explicit creation of classes intended to decouple a system's design while improving its cohesiveness.
Model/View/Controller
One of the most common uses of the pure fabrication pattern is in the model/view/controller (MVC) architecture. In this situation, both the model and the view are typically extracted directly from the system requirements which define both what needs to be processed by the system and how it should be displayed to the user. The system requirements also specify what actions the need to be implemented; however, the actual organization of such actions is left up to the system designer. As suggested by the pure fabrication principle, the actions are extracted into seperate controller classes. A simple MVC architecture for the interactions between two users can be seen below.
In this example, users may view other user's profiles to see their personal information as well as the message most recently recieved from them. The UserData class encapsulates data residing in the model while the ProfileDisplay class handles the intricacies involved in the view. The actions available in the system are edit, message, and ignore, none of which fit cohesively into either the model or the view. Thus, the pure fabrication principle is applied to create a seperate controller class responsible for implementing each of the possible actions. This results a new class created solely for the purpose of maintaining higher cohesion and lower coupling among the model and view.
Factory
The Factory design pattern is another common occurence in systems design which makes use of the pure fabrication principle. In this pattern, a common factory class is used to create objects of the appropriate type. While the objects created by a factory are concepts in the problem domain, the factory itself exists only to abstract the process of object creation. This increases cohesion in the objects by allowing them to focus on their core functionality and reduces unneccessary coupling with services that need to create them.
Summary
As one of the nine GRASP concepts, pure fabrication is sometimes referred to as a design pattern. However, it is really more of a general design principle due to the fact that it offers guidance on when it is appropriate to create new classes solely for the purpose of improving the overall system design. The influence of pure fabrication is seen in various widely used design patterns and implementations to create well designed, reliable, and reusable services across a variety of applications.
References
Arsanjani, Ali. Service-Oriented Modeling and Architecture. IBM Developer Works. Nov 2004
Domain Driven Design - Wikipedia
Grand, Mark. Preview of Patterns in Java Volume 2
Haywood, Dan. An Introduction to Dmaon-Driven Design. Methods and Tools. 2009