From the time i got this coursework,PATTERNS,i have enjoyed and found it exciting. Frankly,i hard a lesser understanding about bloggs until i got the coursework. The ability to express oneself on the internet is both challenging and educative in a number of ways as i have found out durring this brief time i have been blogging. Even though not a regular blogger, the past three months have helped me learn from my fellow bloggers in both a good and bad in that i have learnt to appreciate those who have been better than me and those i feel i have beaten.
The ability to blog nicely so as to be appreciated by others comes from the way one expreeses his material in a coherent and annalytical manner which is both educative and challenging.
When i look at JOHN SSEBAALE's blogg, i both feel challenged and educated in way that he is one annalytical fellow student compared to at least my self. The understanding of the subject he writes about in a mature and consistent rythm leaves me alert and clamouring to adapt his style.
Another blogger i have admired is the unit cordinator, CHANDLER. the simplicity she potrays with her bloggs is really exciting. Not until i saw one of her bloggs, i wasn't sure of how to start. one of paraphrases starts,"yesterday while lecturing,... ", which is really normal compared to her expertise in the field.
this encourages people like me to feel confident and come up with something at least similar.
The first time i blogged i really felt special though not sure of what i had done but with the next and next and next, i felt fine and started flowing with the rythm of blogging.
Still i thank my tutor DR Sri and Jane Chandler. Keep up with your educative work.
Monday, 14 May 2007
ANTI-PATTERNS
CRITIQUING PATTERNS (Position of Anti-patterns within computing.)
Hype is something deliberately misleading or deception; exaggerated or extravagant claims made especially in advertising material. To ravage is to bring heavy destruction or grievously damage something. Business Process Reengineering is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. Yes it is possible that goods things could be destroyed but not all and not always. For anything to be” ravaged”, there has to be a reason. If a scenario is all good, then there is no reason and cause to be hyped. From the above quotation, BPR is wide subject hence almost everyone can write about it. Almost every specialty and field deploys BPR. That’s the reason as to why many people from different circles have to write about it portraying what they understand about it. Relating this to patterns, every reader understands patterns in various ways. For example, when I had just started reading about them, I thought I understood them the very first time I had a lecture. I was wrong, each day that passes with further reading, proves to me that am still no where near the experts in patterns. If I wrote an article about patterns, it wouldn’t imply I don’t understand the basics about them! Any one who writes about BPR definitely knows something about them and criticizing another person’s work should be given credit for at least reading it and expressing his opinion about it for it is through criticisms that we improve and bring out the best from our selves.
To say antipatterns are hype as the author states, we need to understand what they are. Anti-patterns show something that looks like a good idea, but which backfires badly when applied. Therefore they are a toolkit for categorizing, identifying and getting rid of the typical problems in the software development process showing how to go from a bad solution to a good solution. With so many people writing about them in various ways, despite their importance in the computing world, is it right to criticize them? As mentioned above, we all understand situations in different ways. With a number of professionals seeing a bottle half full and others half empty, what the writer of this quotation calls hype isn’t really one to me.
The quotation goes ahead to say. “Every author has the responsibility to convey good and valuable information to its readers.” If this is the case then anti-patterns shouldn’t be criticized. We the readers of anti-patterns get vital information which helps in overcoming the “traps and pitfalls” which might cause us failure during the software engineering process. With work compiled over 40yeas ago as the author states, computer technology has evolved from time to time. This also means patterns need to change since it is the same field where they are applied.
AntiPatterns are quite closely related to design patterns and we would not be wrong to call them natural extensions to Design Patterns. With such a close relationship, it is not a mistake that anti-pattern authors had something to write about. Anti-patterns are not hype! They show how an antipattern comes into existence, what causes it, how to avoid them and the solution to them with any related solution as a reserve. In the first paragraph we saw that hype is something deliberately misleading or deception; exaggerated or extravagant claims made especially in advertising or promotional material. Anti pattern authors don’t exaggerate or make extravagant claims because they do not carry out advertisements. They warn us to be aware of the possible traps and pitfalls which would be disastrous during the software development process.
The book writes about patterns showing how wrongly they are applied. If this book is called “traps and pitfalls”, it would be misleading to its buyers and intending readers for it wouldn’t show traps and pitfalls to what situation.
By calling it anti-patterns, the name suits it as the reader would know what it’s about and where to apply the knowledge got from it. Right from the beginning the book shows the metamorphosis of the anti pattern as discussed below;
Antipattern Name which defines the problem that requires a solution, in an informative way. From this we get the context and cause which call for a solution in this case being the Antipattern solution. AntiPattern Solution showing how the applied solution becomes the bad solution/ Antipattern. This comes with symptoms, and consequences which come about as a result of applying this Antipattern solution. Refactored Solution the best solution to the original problem that should have been applied in the first place. It shows positive consequences and benefits after it is applied.
References
[1] Brown William J. et al. Anti Patterns –
Refactoring Software, Architectures, and Projects in Crisis.
John Wiley & Sons,
3rd March 2007.
[2] Brown William J. et al. Anti Patterns (the official website)
[3] Gamma Erich et al. Design Patterns
Elements of Reusable Object
Oriented Software.
Addison-Wesley,
April, 2007
[4] http://www-128.ibm.com/developerworks/webservices/library/ws-antipatterns/
Hype is something deliberately misleading or deception; exaggerated or extravagant claims made especially in advertising material. To ravage is to bring heavy destruction or grievously damage something. Business Process Reengineering is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. Yes it is possible that goods things could be destroyed but not all and not always. For anything to be” ravaged”, there has to be a reason. If a scenario is all good, then there is no reason and cause to be hyped. From the above quotation, BPR is wide subject hence almost everyone can write about it. Almost every specialty and field deploys BPR. That’s the reason as to why many people from different circles have to write about it portraying what they understand about it. Relating this to patterns, every reader understands patterns in various ways. For example, when I had just started reading about them, I thought I understood them the very first time I had a lecture. I was wrong, each day that passes with further reading, proves to me that am still no where near the experts in patterns. If I wrote an article about patterns, it wouldn’t imply I don’t understand the basics about them! Any one who writes about BPR definitely knows something about them and criticizing another person’s work should be given credit for at least reading it and expressing his opinion about it for it is through criticisms that we improve and bring out the best from our selves.
To say antipatterns are hype as the author states, we need to understand what they are. Anti-patterns show something that looks like a good idea, but which backfires badly when applied. Therefore they are a toolkit for categorizing, identifying and getting rid of the typical problems in the software development process showing how to go from a bad solution to a good solution. With so many people writing about them in various ways, despite their importance in the computing world, is it right to criticize them? As mentioned above, we all understand situations in different ways. With a number of professionals seeing a bottle half full and others half empty, what the writer of this quotation calls hype isn’t really one to me.
The quotation goes ahead to say. “Every author has the responsibility to convey good and valuable information to its readers.” If this is the case then anti-patterns shouldn’t be criticized. We the readers of anti-patterns get vital information which helps in overcoming the “traps and pitfalls” which might cause us failure during the software engineering process. With work compiled over 40yeas ago as the author states, computer technology has evolved from time to time. This also means patterns need to change since it is the same field where they are applied.
AntiPatterns are quite closely related to design patterns and we would not be wrong to call them natural extensions to Design Patterns. With such a close relationship, it is not a mistake that anti-pattern authors had something to write about. Anti-patterns are not hype! They show how an antipattern comes into existence, what causes it, how to avoid them and the solution to them with any related solution as a reserve. In the first paragraph we saw that hype is something deliberately misleading or deception; exaggerated or extravagant claims made especially in advertising or promotional material. Anti pattern authors don’t exaggerate or make extravagant claims because they do not carry out advertisements. They warn us to be aware of the possible traps and pitfalls which would be disastrous during the software development process.
The book writes about patterns showing how wrongly they are applied. If this book is called “traps and pitfalls”, it would be misleading to its buyers and intending readers for it wouldn’t show traps and pitfalls to what situation.
By calling it anti-patterns, the name suits it as the reader would know what it’s about and where to apply the knowledge got from it. Right from the beginning the book shows the metamorphosis of the anti pattern as discussed below;
Antipattern Name which defines the problem that requires a solution, in an informative way. From this we get the context and cause which call for a solution in this case being the Antipattern solution. AntiPattern Solution showing how the applied solution becomes the bad solution/ Antipattern. This comes with symptoms, and consequences which come about as a result of applying this Antipattern solution. Refactored Solution the best solution to the original problem that should have been applied in the first place. It shows positive consequences and benefits after it is applied.
References
[1] Brown William J. et al. Anti Patterns –
Refactoring Software, Architectures, and Projects in Crisis.
John Wiley & Sons,
3rd March 2007.
[2] Brown William J. et al. Anti Patterns (the official website)
[3] Gamma Erich et al. Design Patterns
Elements of Reusable Object
Oriented Software.
Addison-Wesley,
April, 2007
[4] http://www-128.ibm.com/developerworks/webservices/library/ws-antipatterns/
Tuesday, 3 April 2007
ADAPTER PATTERN
In our pursuit to understand and appreciate patterns more, we recently discussed the adapter pattern.
An adapter, one of those catalogued by the Gang of Four, allows classes to work together despite their incompatible interfaces by wrapping its own interface around that of an already existing class. The adapter is also responsible for handling any logic necessary to transform data into a form that is useful for the consumer. We discussed an example of where an electric adapter in the UK is different from the one in the USA. In order to use an appliance in both countries one needs a converter for the differential power usage by the electric appliance. This converter is the mechanism to overcome the incompatibility in power usage and socket usage hence the adapter.
There are two types of adapter patterns:
The Object Adapter pattern This implements a desired interface which clients require to hold to hold the instance of the adaptee. The adapter inherits the target interface that the client expects to use, and relates object in question to it so as to be used by the adopting target. When the client calls the request () method on its target object (the adapter), the request is translated into the corresponding specific request on the adaptee.
The object adapter is advantageous in a way that since it does not use inheritance of the adptee, it can wrap the adptee and any derivatives of the adpatee. Secondly, unlike the class adapter where all methods of the target are exposed to the client the object adapter may choose the desired methods that it wants to expose to the client and there is no restriction of multiple inheritance requirements.
It is disadvantageous in a way that it makes harder to override the target behavior because it will require inheriting from the adaptee and making the wrapper refer to the subclass rather than the adpatee itself.
Applicability
This is generally used when the client and the adptee need to be completely decoupled from each other where one will be overridden by the other’s interface.
The Class Adapter pattern
This type of adapter uses multiple inheritances to achieve its goal. The adapter is created inheriting interfaces from both the interface that is expected and the interface that is pre-existing. The Object Adapter pattern is more often used in some popular languages, such as Java; do not support true multiple inheritances as the designers of these languages consider it a dangerous practice. Class adapters use multiple inheritances to achieve their goals. As in the object adapter, the class adapter inherits the interface of the client's target. However, it also inherits the interface of the adaptee as well. Since Java does not support true multiple inheritance, this means that one of the interfaces must be inherited from a Java Interface type. The request to the target is simply rerouted to the specific request that was inherited from the adaptee interface.
Class adapters have a problem with name conflicts if methods of the same signature exist on both the target and the adaptee. Note that just because two objects have methods that have the same signature (syntax), it does not guarantee that the two methods have the same meaning or behavior (sematics). That is, the two methods do not necessarily map directly to each other. Object adapters do not have this problem.
Class adapters are simpler than object adapters in that they involve fewer classes and are useful if total decoupling of the client and adaptee is not needed.
Advantageous in that it changes of some adapted class methods will still allow the other methods to be unchanged and Lets you override the common methods from the interface class in the wrapper class to call the methods in the adaptee class as appropriate. This design results in an efficient run time performance.
Disadvantageous due to the fact that Only the adaptee class can be adapted but its other subclasses cannot be used and is applicable only for languages that support multiple inheritances in some cases. It requires multiple inheritances.
Applicability
It is generally used in applications in which there is a need to use an existing class but the interface of the target class does not match. It has common methods from the target interface class and the adaptee class.
http://www.designpattern.lu.unisi.ch/
http://ww1.ucmss.com/books/LFS/CSREA2006/SER4955.pdf
An adapter, one of those catalogued by the Gang of Four, allows classes to work together despite their incompatible interfaces by wrapping its own interface around that of an already existing class. The adapter is also responsible for handling any logic necessary to transform data into a form that is useful for the consumer. We discussed an example of where an electric adapter in the UK is different from the one in the USA. In order to use an appliance in both countries one needs a converter for the differential power usage by the electric appliance. This converter is the mechanism to overcome the incompatibility in power usage and socket usage hence the adapter.
There are two types of adapter patterns:
The Object Adapter pattern This implements a desired interface which clients require to hold to hold the instance of the adaptee. The adapter inherits the target interface that the client expects to use, and relates object in question to it so as to be used by the adopting target. When the client calls the request () method on its target object (the adapter), the request is translated into the corresponding specific request on the adaptee.
The object adapter is advantageous in a way that since it does not use inheritance of the adptee, it can wrap the adptee and any derivatives of the adpatee. Secondly, unlike the class adapter where all methods of the target are exposed to the client the object adapter may choose the desired methods that it wants to expose to the client and there is no restriction of multiple inheritance requirements.
It is disadvantageous in a way that it makes harder to override the target behavior because it will require inheriting from the adaptee and making the wrapper refer to the subclass rather than the adpatee itself.
Applicability
This is generally used when the client and the adptee need to be completely decoupled from each other where one will be overridden by the other’s interface.
The Class Adapter pattern
This type of adapter uses multiple inheritances to achieve its goal. The adapter is created inheriting interfaces from both the interface that is expected and the interface that is pre-existing. The Object Adapter pattern is more often used in some popular languages, such as Java; do not support true multiple inheritances as the designers of these languages consider it a dangerous practice. Class adapters use multiple inheritances to achieve their goals. As in the object adapter, the class adapter inherits the interface of the client's target. However, it also inherits the interface of the adaptee as well. Since Java does not support true multiple inheritance, this means that one of the interfaces must be inherited from a Java Interface type. The request to the target is simply rerouted to the specific request that was inherited from the adaptee interface.
Class adapters have a problem with name conflicts if methods of the same signature exist on both the target and the adaptee. Note that just because two objects have methods that have the same signature (syntax), it does not guarantee that the two methods have the same meaning or behavior (sematics). That is, the two methods do not necessarily map directly to each other. Object adapters do not have this problem.
Class adapters are simpler than object adapters in that they involve fewer classes and are useful if total decoupling of the client and adaptee is not needed.
Advantageous in that it changes of some adapted class methods will still allow the other methods to be unchanged and Lets you override the common methods from the interface class in the wrapper class to call the methods in the adaptee class as appropriate. This design results in an efficient run time performance.
Disadvantageous due to the fact that Only the adaptee class can be adapted but its other subclasses cannot be used and is applicable only for languages that support multiple inheritances in some cases. It requires multiple inheritances.
Applicability
It is generally used in applications in which there is a need to use an existing class but the interface of the target class does not match. It has common methods from the target interface class and the adaptee class.
http://www.designpattern.lu.unisi.ch/
http://ww1.ucmss.com/books/LFS/CSREA2006/SER4955.pdf
Thursday, 15 March 2007
Appreciating Coursework
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.
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.
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
Tuesday, 6 March 2007
CRITICIZING THE GOF WAY OF CATALOGUING PATTERNS
Critiquing the GOF cataloguing pattern of the ADAPTER
The task calls for selecting one pattern and criticize it, in this case the Adapter and this is what follows;
The adapter pattern is catalogued using the name, intent, Also known as, motivation, Applicability, structure, participants, collaborations, consequences, implementation, sample code, known use, and lastly related patterns.
Cataloguing the pattern gives a general idea of what the pattern is about, what it does and how it can be applied. Such information gives the user a wide scope of information about the catalogue before applying it which gives enough knowledge of how to use it. It also helps the user find all required information in one abstract which saves time looking for other sources with information about the pattern. By giving the intent, the reader gets the whole idea about what the adapter does, how it works and in what situations to apply it. The consequence gives a clear example of how the pattern yields results when applied. The motivation shows how the need to apply the adapter leads to its applicability.
However, much as all this information is vital, some of it is not necessary to include in the catalogue of the Adapter pattern.
The GoF say the pattern should have a unique identifying name. However a known as is given which isn’t even necessary, in this case a wrapper,
Including the participants showing the adapter and adoptee isn’t really necessary. Such information can be got from the various UMLs drawn to express the pattern. Likewise the applicability shows the participants as well.
The sample code too can be got from the `UML if needed. ` It is shown in one particular language which isn’t use full to all as different intending users use different programming languages.
Including the related patterns is a disadvantage in a way that it might even cause confusions to the intending user of which to apply. These are totally different as they show a different challenge.
Task 2;
This one is to show one different pattern that is not shown by the Gang of Four.
Author; Martin van Welie
Name; positioning objects precisely
Problem; users need to position objects precisely
Context; Applications that use direct manipulation. Te application involves graphical manipulation of items where the relative or absolute positions are important.
Forces; -the users want precision but the display resolution is relatively low.
The users see positions as a "final destinations" but dragging usually does not involve "walls
Solution; Make the objects magnetic towards certain positions or other objects.
When the users are positioning the objects, the objects get drawn to other objects or positions when they are close i.e. typically within several pixels. The destination object should act as a "wall" that keeps the moving object from passing it. In other cases, a "bump" is better than a "wall".
Known use; Winamp, PowerPoint, Macromedia Flash, Adobe Photoshop
Rewn uselated pattern;
http://www.welie.com/patterns/gui/magnetism.html
The task calls for selecting one pattern and criticize it, in this case the Adapter and this is what follows;
The adapter pattern is catalogued using the name, intent, Also known as, motivation, Applicability, structure, participants, collaborations, consequences, implementation, sample code, known use, and lastly related patterns.
Cataloguing the pattern gives a general idea of what the pattern is about, what it does and how it can be applied. Such information gives the user a wide scope of information about the catalogue before applying it which gives enough knowledge of how to use it. It also helps the user find all required information in one abstract which saves time looking for other sources with information about the pattern. By giving the intent, the reader gets the whole idea about what the adapter does, how it works and in what situations to apply it. The consequence gives a clear example of how the pattern yields results when applied. The motivation shows how the need to apply the adapter leads to its applicability.
However, much as all this information is vital, some of it is not necessary to include in the catalogue of the Adapter pattern.
The GoF say the pattern should have a unique identifying name. However a known as is given which isn’t even necessary, in this case a wrapper,
Including the participants showing the adapter and adoptee isn’t really necessary. Such information can be got from the various UMLs drawn to express the pattern. Likewise the applicability shows the participants as well.
The sample code too can be got from the `UML if needed. ` It is shown in one particular language which isn’t use full to all as different intending users use different programming languages.
Including the related patterns is a disadvantage in a way that it might even cause confusions to the intending user of which to apply. These are totally different as they show a different challenge.
Task 2;
This one is to show one different pattern that is not shown by the Gang of Four.
Author; Martin van Welie
Name; positioning objects precisely
Problem; users need to position objects precisely
Context; Applications that use direct manipulation. Te application involves graphical manipulation of items where the relative or absolute positions are important.
Forces; -the users want precision but the display resolution is relatively low.
The users see positions as a "final destinations" but dragging usually does not involve "walls
Solution; Make the objects magnetic towards certain positions or other objects.
When the users are positioning the objects, the objects get drawn to other objects or positions when they are close i.e. typically within several pixels. The destination object should act as a "wall" that keeps the moving object from passing it. In other cases, a "bump" is better than a "wall".
Known use; Winamp, PowerPoint, Macromedia Flash, Adobe Photoshop
Rewn uselated pattern;
http://www.welie.com/patterns/gui/magnetism.html
Friday, 23 February 2007
Friday, 16 February 2007
SOFTWARE PATTERNS
To understand software patterns one needs to understand what software engineering means as the two go hand in hand; thus software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of SOFTWARE. Software engineering encompasses knowledge, tools, and methods for defining software and performing software design, software testing, and software maintenance tasks as well as software construction.
What is a software pattern?
It is the combination of a software engineering problem, which arises when engineering software with a corresponding solution within a specific context. Such a solution can be reused by another software engineer facing the same problem.
Frequently asked questions about software engineering;
-what is the use for software pattern?
Software pattern present solutions to software engineering problems faced during the process of software engineering within a particular context.
-Is prior knowledge needed about patterns for one to use them?
Not necessarily for as long as on knows what the problem is about and ready to use the solution available that is tried over a period of time. A pattern is where theory and practice meet to reinforce and complement one another, by showing that the structure it describes is useful, useable, and used!
-What is a pattern catalogue?
A pattern catalog is a collection of related patterns. It typically subdivides the patterns into at least a small number of broad categories and may include some amount of cross referencing between patterns.
-What is a Pattern System?
A pattern system is a cohesive set of related patterns which work together to support the construction and evolution of whole architectures. Not only is it organized into related groups and subgroups at multiple levels of granularity, it describes the many interrelationships between the patterns and their groupings and how they may be combined and composed to solve more complex problems. The patterns in a pattern system should all be described in a consistent and uniform style and need to cover a sufficiently broad base of problems and solutions to enable significant portions of complete architectures to be built.
What is a software pattern?
It is the combination of a software engineering problem, which arises when engineering software with a corresponding solution within a specific context. Such a solution can be reused by another software engineer facing the same problem.
Frequently asked questions about software engineering;
-what is the use for software pattern?
Software pattern present solutions to software engineering problems faced during the process of software engineering within a particular context.
-Is prior knowledge needed about patterns for one to use them?
Not necessarily for as long as on knows what the problem is about and ready to use the solution available that is tried over a period of time. A pattern is where theory and practice meet to reinforce and complement one another, by showing that the structure it describes is useful, useable, and used!
-What is a pattern catalogue?
A pattern catalog is a collection of related patterns. It typically subdivides the patterns into at least a small number of broad categories and may include some amount of cross referencing between patterns.
-What is a Pattern System?
A pattern system is a cohesive set of related patterns which work together to support the construction and evolution of whole architectures. Not only is it organized into related groups and subgroups at multiple levels of granularity, it describes the many interrelationships between the patterns and their groupings and how they may be combined and composed to solve more complex problems. The patterns in a pattern system should all be described in a consistent and uniform style and need to cover a sufficiently broad base of problems and solutions to enable significant portions of complete architectures to be built.
Tuesday, 13 February 2007
Patterns
What is a pattern?
A Pattern would be described as a well tried-solution to a real problem of a particular context.
Patterns are optimal solutions to common problems. As common problems are tossed around a community and are resolved, common solutions often spontaneously emerge. Eventually, the best of these rise above the din and self-identify and become refined until they reach the status of a Design Pattern.
Patterns are atomic in that they can be grouped to form more complex patterns: a chair pattern nests within a dining room pattern that nests within a house pattern that nests within a town pattern.
One idea that distinguishes Patterns from simple prescriptions is that Patterns never lose sense of their context; they describe things that work together and the rules that govern those collections.
Example of a pattern;
Problem name: Getting on the property ladder
Authors: Steven. J. Kintu
Creation date: 13-02-07
Keywords: [save no matter how much you bring in, retain your job at all costs]
Intent:Keep the interest in the dream. Don’t give up stay focused don’t let negative thoughts wash your dream away
Context:
Suppose you are thinking of owning your own house, as soon as after you have graduated. With that part time job you have that you have been doing through out your course. Make a regular saving out of it into an ISA [instant savings account]. Ignore any student loans and debts, as long as you have an income save up ₤ 3000 a year, if you can into your ISA. Its tax free with at least 4% p.a. team up with one of your close ones if you opt for a joint mortgage. With this you could end up with ₤ 6000 between the two of you on your ISA accounts. Do this for two years and have almost ₤12,500 between the two of you. That’s good enough to be your initial deposit on an average told on two bedroom flat. With this under your arms hold on to it for two years and you’ll notice an increase in value upon your property incurring the same expense on it as you would while paying rent.
Forces
We want to get on the property ladder.
We don’t want to compromise the limit we are set for monthly rent payment.
solution:Use an ISA to save as it’s a relatively high interest paying account.
Example/ known use:The bank that holds your ISA account will favor your mortgage intentions.
patterns need to be documented;
-for refferal reasons by designers to acquire knowledge of how to reapply them and use them.
-to support reuse in design and boost confidence in reapplication of the pattern by future users
-to present optimized solutions to particular partial design problems.
-to help make the used code easier to understand for intending users of the pattern
The general form for documenting patterns is to define items such as:
The motivation or context that this pattern applies to,
Prerequisites that should be satisfied before deciding to use a pattern,
A description of the program structure that the pattern will define,
A list of the participants needed to complete a pattern,
Consequences of using the pattern, both positive and negative and
Examples
Qualities of a pattern
Encapsulation and Abstraction
Each pattern encapsulates a well-defined problem and its solution in a particular domain. Patterns should provide crisp, clear boundaries that help crystallize the problem space and the solution space by parceling them into a lattice of distinct, interconnected fragments. They also serve as abstractions which embody domain knowledge and experience, and may occur at varying hierarchical levels of conceptual granularity within the domain.
Openness and Variability
Each pattern should be open for extension by other patterns so that they may work together to solve a larger problem. A pattern solution should be also capable of being realized by an infinite variety of implementations (in isolation, as well as in conjunction with other patterns).
Generatively and Compos ability
Each pattern, once applied, generates a resulting context which matches the initial context of one or more other patterns in a pattern language. These subsequent patterns may then be applied to progress further toward the final goal of generating a "whole" or complete overall solution. "Patterns are applied by the means of piecemeal growth. Applying one pattern provides a context for the application of the next pattern." But patterns are not simply linear in nature, more like fractals in that patterns at a particular level of abstraction and granularity may each lead to or be composed with other patterns at varying levels of scale.
Equilibrium
Each pattern must realize some kind of balance among its forces and constraints. This may be due to one or more invariants or heuristics that are used to minimize conflict within the solution space. The invariants often show an underlying problem solving principle or philosophy for the particular domain, and provide a rationale for each step/rule in the pattern.
The aim is that, if well written, each pattern describes a whole that is greater than the sum of its parts, due to skillful choreography of its elements working together to satisfy all its varying demands.
What a pattern comprises of;
• The pattern name: This could be a noun for pattern names, but short verb phrases can also be used.
•The problem is often stated as a question or design challenge.
• The context: A description of the context in which the problem might arise, and to which the solution applies.
• The forces: The forces describe pattern design trade-offs; what pulls the problem in different directions, toward different solutions?
• The solution: The solution explains how to solve the problem, just as in the emboldened section of an Alexandrian pattern.
•Why does this pattern work? What is the history behind the pattern? We extract this so it doesn’t “clutter” the solution. As a section, it draws attention to the importance of principles behind a pattern; it is a source of learning, rather than action.
• Resulting context: This tells which forces the pattern resolves and which forces remain unresolved by the pattern, and it points to more patterns that might be the next ones to consider.
http://www.designpattern.lu.unisi.ch/
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/
A Pattern would be described as a well tried-solution to a real problem of a particular context.
Patterns are optimal solutions to common problems. As common problems are tossed around a community and are resolved, common solutions often spontaneously emerge. Eventually, the best of these rise above the din and self-identify and become refined until they reach the status of a Design Pattern.
Patterns are atomic in that they can be grouped to form more complex patterns: a chair pattern nests within a dining room pattern that nests within a house pattern that nests within a town pattern.
One idea that distinguishes Patterns from simple prescriptions is that Patterns never lose sense of their context; they describe things that work together and the rules that govern those collections.
Example of a pattern;
Problem name: Getting on the property ladder
Authors: Steven. J. Kintu
Creation date: 13-02-07
Keywords: [save no matter how much you bring in, retain your job at all costs]
Intent:Keep the interest in the dream. Don’t give up stay focused don’t let negative thoughts wash your dream away
Context:
Suppose you are thinking of owning your own house, as soon as after you have graduated. With that part time job you have that you have been doing through out your course. Make a regular saving out of it into an ISA [instant savings account]. Ignore any student loans and debts, as long as you have an income save up ₤ 3000 a year, if you can into your ISA. Its tax free with at least 4% p.a. team up with one of your close ones if you opt for a joint mortgage. With this you could end up with ₤ 6000 between the two of you on your ISA accounts. Do this for two years and have almost ₤12,500 between the two of you. That’s good enough to be your initial deposit on an average told on two bedroom flat. With this under your arms hold on to it for two years and you’ll notice an increase in value upon your property incurring the same expense on it as you would while paying rent.
Forces
We want to get on the property ladder.
We don’t want to compromise the limit we are set for monthly rent payment.
solution:Use an ISA to save as it’s a relatively high interest paying account.
Example/ known use:The bank that holds your ISA account will favor your mortgage intentions.
patterns need to be documented;
-for refferal reasons by designers to acquire knowledge of how to reapply them and use them.
-to support reuse in design and boost confidence in reapplication of the pattern by future users
-to present optimized solutions to particular partial design problems.
-to help make the used code easier to understand for intending users of the pattern
The general form for documenting patterns is to define items such as:
The motivation or context that this pattern applies to,
Prerequisites that should be satisfied before deciding to use a pattern,
A description of the program structure that the pattern will define,
A list of the participants needed to complete a pattern,
Consequences of using the pattern, both positive and negative and
Examples
Qualities of a pattern
Encapsulation and Abstraction
Each pattern encapsulates a well-defined problem and its solution in a particular domain. Patterns should provide crisp, clear boundaries that help crystallize the problem space and the solution space by parceling them into a lattice of distinct, interconnected fragments. They also serve as abstractions which embody domain knowledge and experience, and may occur at varying hierarchical levels of conceptual granularity within the domain.
Openness and Variability
Each pattern should be open for extension by other patterns so that they may work together to solve a larger problem. A pattern solution should be also capable of being realized by an infinite variety of implementations (in isolation, as well as in conjunction with other patterns).
Generatively and Compos ability
Each pattern, once applied, generates a resulting context which matches the initial context of one or more other patterns in a pattern language. These subsequent patterns may then be applied to progress further toward the final goal of generating a "whole" or complete overall solution. "Patterns are applied by the means of piecemeal growth. Applying one pattern provides a context for the application of the next pattern." But patterns are not simply linear in nature, more like fractals in that patterns at a particular level of abstraction and granularity may each lead to or be composed with other patterns at varying levels of scale.
Equilibrium
Each pattern must realize some kind of balance among its forces and constraints. This may be due to one or more invariants or heuristics that are used to minimize conflict within the solution space. The invariants often show an underlying problem solving principle or philosophy for the particular domain, and provide a rationale for each step/rule in the pattern.
The aim is that, if well written, each pattern describes a whole that is greater than the sum of its parts, due to skillful choreography of its elements working together to satisfy all its varying demands.
What a pattern comprises of;
• The pattern name: This could be a noun for pattern names, but short verb phrases can also be used.
•The problem is often stated as a question or design challenge.
• The context: A description of the context in which the problem might arise, and to which the solution applies.
• The forces: The forces describe pattern design trade-offs; what pulls the problem in different directions, toward different solutions?
• The solution: The solution explains how to solve the problem, just as in the emboldened section of an Alexandrian pattern.
•Why does this pattern work? What is the history behind the pattern? We extract this so it doesn’t “clutter” the solution. As a section, it draws attention to the importance of principles behind a pattern; it is a source of learning, rather than action.
• Resulting context: This tells which forces the pattern resolves and which forces remain unresolved by the pattern, and it points to more patterns that might be the next ones to consider.
http://www.designpattern.lu.unisi.ch/
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/
Subscribe to:
Comments (Atom)
