CSC/ECE 517 Summer 2008/wiki3 1 PF

Pure fabrication

Sometimes it is a good idea to introduce into a system an object that has no counterpart in the real world. This is called the pure fabrication pattern. Find examples of pure fabrication, and weave them into a narrative that can teach programmers when it is helpful and when it is not helpful to fabricate objects.

Introduction

Programming all code by a design pattern can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, Pure Fabrication is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability.

Why pure fabrication?

We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

• Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

• Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

• The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

How would you classify it

Pure Fabrication is classified as one of the nine GRASP Patterns that help aid developers in assigning responsibilities to objects in your web applications and winform applications. Factories are very similar to pure fabrication; they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develop code for short term. Following patterns can help make your code more reusable and readable but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

Suggestion of where to use pure fabrication

Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

• Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are a large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task; therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

Where not to use pure fabrication

1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

Conclusion

Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create high cohesion and low coupling. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

External links

• Grasp Pattern
• Over-Architecting Via Pure Fabrication
• Grasp OOD
• GRASP Pure Fabrication
• the case for High Cohesion and low coupling
• Pattern oriented software development
• Pure Fabrication Notes
• Object Oriented Analysis and Logical design
• Software Pattern Synopses
• Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

Back to the assignment page