A couple of days ago JANE CHANDLER my unit co-ordinator came around to give us a lecture basically about the course work: informing us of what was required to do and submit.
The course work is made up of five tasks of which i am to do four. Each task calls for separate and different or unique approach which are all related to patterns. However with a choice of doing four i have decided to pick up those i consider more developmental to my knowledge and understanding of patterns.
Task one requires designining a small prototype application which creates, stores and ammends cutomers records which should have not more than a customer class and an Array of customers. USing the Strategy, Decorator and Adapter patterns i should provide three different adaptations to my application which will enable the user to view the customer records in a variety of ways like length of time they have been customers, alphabetically , by amount of money spent, as continuos plain text, as formatted text and so on. Then evaluate the effectiveness of each pattern as a means of viewing customer records.
This task requires four sets of UML diagrams one of each of the adaptations of the prototype customer record. Each UML containing of a class diagram and if required a use case diagram and state diagram.
This task is developmental to my understanding regarding my knowledge about patterns. The use of the suggested patterns helps me to appreciate and recognise the importance of patterns. the use of UML diagrams strengthens my understanding of data flow and and break down up to the coding level. As a result its one of the four i have decided to do as part of my course work.
Task two calls for using either Java, c++ or c# to create sufficient code to illustrate task one above. I don`t see this task constructive to me as it only suggets three programming languages of which i have no idea and interest. This task does`nt put into cosideration visual basic programmers or any other programming language apart from those mentioned. Futher still the code can be generated in task one while drawing the UML. It`s at this point that i have decided not to do this task as part of my four tasks required of me.
Task three requires browsing two websites about patterns related to good presonal websites design and expand one of the Iron`s temporal Patterns(leaving, increamental growth, freshness, dates and unchanging URLs)into a complete draft pattern using an appropriate format{Gang of Four or Alexandrian.} With this task i think its dvelopmental to the my understanding of patterns as it requires me to apply my knowledge of design patterns to website desining. therefore i`ll will be attempting this task.
Task four is about Anti-Patterns. It requires me,using a given quotation in the course work calling anti-patterns hype or traps and pitfalls to write a short esay of about 600 words discussing what Anti-patterns are or not explaining what there place is within the computing field. Since Anti-patterns are considered natural follow ups of patterns i see to that this task of importance to my knowledge of patterns. Therefore this tasks is one of the four i am to tackle.
Task five is about blogging. This blog is to be used to reflect each week on what i learn about patterns. This i really find interesting as it will help me reflect back on what i learn with patterns. Since my understanding of patterns is developng by each lecture and reading i do, blogging will show this to any reader and to myself which builds encouragement to read further. This task is definetely to be done.
Therefore i will be tackling tasks one, three, four and five.
Thursday, 15 March 2007
Abstract Factory
As one of the Gang of Four catalogued patterns, the Abstract factory Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
One of the nice things about abstraction is that it lets you take care of the bigger picture and worry about the details later.
An abstract factory class defines methods to create an instance of each abstract class that represents a user interface widget. Concrete factories are concrete subclasses of an abstract factory that implements its methods to create instances of concrete widget classes for the same platform e.g a uniform frame for cars no matter what type of car,which would be applied to all cars and then the other extras taken care of later such as engine, steering and lihgts.
In a more general context, an abstract factory class and its concrete subclasses organize sets of concrete classes that work with different but related products.
An example would be a pasta maker. A pasta maker will produce different types of pasta, depending what kind of disk is loaded into the machine. All disks should have certain properties in common, so that they will work with the pasta maker. This specification for the disks is the Abstract Factory, and each specific disk is a Factory.
You will never see an Abstract Factory, because one can never exist, but all Factories (pasta maker disks) inherit their properties from the abstract Factory. In this way, all disks will work in the pasta maker, since they all comply with the same specifications. The pasta maker doesn't care what the disk is doing, nor should it. You turn the handle on the pasta maker, and the disk makes a specific shape of pasta come out. Each individual disk contains the information of how to create the pasta, and the pasta maker does not.
Applicability of this pattern would be in some of the following senarios
when;
-a system should be independent of how its products are created, composed, and represented.
-a system should be configured with one of multiple families of products.
-a family of related product objects is designed to be used together, and you need to enforce this constraint.
-you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.
The Abstract Factory pattern has the following benefits and liabilities:
It isolates concrete classes. The Abstract Factory pattern helps control the classes of objects that an application creates. Because a factory encapsulates the responsibility and the process of creating product objects, it isolates clients from implementation classes. Users don`t need to know all properties of an oject or class to design it. Instances are manipulated through their abstract interfaces.
It makes exchanging product families easy. The class of a concrete factory appears only once in an application—that is, where it's created. This makes it easy to change the concrete factory an application uses. It can use different product configurations simply by changing the concrete factory. Because an abstract factory creates a complete family of products, the whole product family changes at once. Forexample,pasta maker disks inherit their properties from the abstract Factory. In this way, all disks will work in the pasta maker, since they all comply with the same specifications.
It promotes consistency among products. When product objects in a family are designed to work together, it's important that an application use objects from only one family at a time. AbstractFactory makes this easy to enforce. Same above example applies where its only the change of disks thats done and not the pasts maker.
However, extending abstract factories to produce new kinds of Products isn't easy. That's because the AbstractFactory interface fixes the set of products that can be created. Supporting new kinds of products requires extending the factory interface, which involves changing the AbstractFactory class and all of its subclasses. Forexample, the pasta maker would`nt make biscuits as its only tuned to making pasta. So each Abstract factory only applies to production of a certain product forexample cars only or pasts only.
Design Patterns,(Addison-Wesley 1998).Author GoF; Gama, HelmJohnson& Vlissides
http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/FactoryPattern.htm
One of the nice things about abstraction is that it lets you take care of the bigger picture and worry about the details later.
An abstract factory class defines methods to create an instance of each abstract class that represents a user interface widget. Concrete factories are concrete subclasses of an abstract factory that implements its methods to create instances of concrete widget classes for the same platform e.g a uniform frame for cars no matter what type of car,which would be applied to all cars and then the other extras taken care of later such as engine, steering and lihgts.
In a more general context, an abstract factory class and its concrete subclasses organize sets of concrete classes that work with different but related products.
An example would be a pasta maker. A pasta maker will produce different types of pasta, depending what kind of disk is loaded into the machine. All disks should have certain properties in common, so that they will work with the pasta maker. This specification for the disks is the Abstract Factory, and each specific disk is a Factory.
You will never see an Abstract Factory, because one can never exist, but all Factories (pasta maker disks) inherit their properties from the abstract Factory. In this way, all disks will work in the pasta maker, since they all comply with the same specifications. The pasta maker doesn't care what the disk is doing, nor should it. You turn the handle on the pasta maker, and the disk makes a specific shape of pasta come out. Each individual disk contains the information of how to create the pasta, and the pasta maker does not.
Applicability of this pattern would be in some of the following senarios
when;
-a system should be independent of how its products are created, composed, and represented.
-a system should be configured with one of multiple families of products.
-a family of related product objects is designed to be used together, and you need to enforce this constraint.
-you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.
The Abstract Factory pattern has the following benefits and liabilities:
It isolates concrete classes. The Abstract Factory pattern helps control the classes of objects that an application creates. Because a factory encapsulates the responsibility and the process of creating product objects, it isolates clients from implementation classes. Users don`t need to know all properties of an oject or class to design it. Instances are manipulated through their abstract interfaces.
It makes exchanging product families easy. The class of a concrete factory appears only once in an application—that is, where it's created. This makes it easy to change the concrete factory an application uses. It can use different product configurations simply by changing the concrete factory. Because an abstract factory creates a complete family of products, the whole product family changes at once. Forexample,pasta maker disks inherit their properties from the abstract Factory. In this way, all disks will work in the pasta maker, since they all comply with the same specifications.
It promotes consistency among products. When product objects in a family are designed to work together, it's important that an application use objects from only one family at a time. AbstractFactory makes this easy to enforce. Same above example applies where its only the change of disks thats done and not the pasts maker.
However, extending abstract factories to produce new kinds of Products isn't easy. That's because the AbstractFactory interface fixes the set of products that can be created. Supporting new kinds of products requires extending the factory interface, which involves changing the AbstractFactory class and all of its subclasses. Forexample, the pasta maker would`nt make biscuits as its only tuned to making pasta. So each Abstract factory only applies to production of a certain product forexample cars only or pasts only.
Design Patterns,(Addison-Wesley 1998).Author GoF; Gama, HelmJohnson& Vlissides
http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/FactoryPattern.htm
Subscribe to:
Comments (Atom)
