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
Subscribe to:
Post Comments (Atom)
1 comment:
Wow! the Positioning Objects Precisely Pattern you worked on sounds great. It is such a simple but useful pattern. Just wondering whether you managed to get the UML diagram of this pattern. I sounds interesting. Well done!
Cheers
Post a Comment