27-02-2007 - BLOGG 6
Explain Abstract Factory and what you think about it.
An abstract factory provides an interface for creating families of related or dependent objects without specifying there concrete classes. [GOF]
I basically think that an abstract factory pattern tries to present an abstract class from which several other inherited classes can be derived from.
[GOF] Design patterns- elements of reusable object oriented software, GOF, (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
Monday 12 March 2007
Review of PAFSD coursework 2006/2007
27-02-2007 - BLOGG 5
Review of PAFSD coursework 2006/2007
I think the course work is very tough, but fair. I do appreciate question 1, and trying to under the question better in order to make a go at it. I do have a doubt about question 2. At the moment I think I understand question 3 which relates to expanding and extending One of Iron’s Temporal Patterns (living site, Incremental Growth, Freshness dates or Unchanging URL’s) into a complete, draft pattern putting one of this pattern into the 13 elements of GOF and question 4 which is to write an essay on anti-patterns based on the quote. I am trying to grasp proper footing in the related topics.
I do appreciate question 5- the bloggs section do give me the opportunity to post out my ideas and let others view and criticize. Also I can learn from others too as it presents an interactive forum to share views and ideas on design patterns ideas.
Review of PAFSD coursework 2006/2007
I think the course work is very tough, but fair. I do appreciate question 1, and trying to under the question better in order to make a go at it. I do have a doubt about question 2. At the moment I think I understand question 3 which relates to expanding and extending One of Iron’s Temporal Patterns (living site, Incremental Growth, Freshness dates or Unchanging URL’s) into a complete, draft pattern putting one of this pattern into the 13 elements of GOF and question 4 which is to write an essay on anti-patterns based on the quote. I am trying to grasp proper footing in the related topics.
I do appreciate question 5- the bloggs section do give me the opportunity to post out my ideas and let others view and criticize. Also I can learn from others too as it presents an interactive forum to share views and ideas on design patterns ideas.
One extra Design Pattern
20-02-2007 - BLOGG 4
PAFSD Lecturer ask the class to research and note one other design pattern (not within the GOF 23 design patterns).
Name of Pattern:
Module Tab design pattern [5]
Problem
The user needs to navigate through one or more stacked panes of content without refreshing the page.
Applicability: (where and when used)
There are multiple panes of content, but there is space to only show one content pane at a time
The different panes of content do not need to be viewed in context with each other.
You need a way to switch between the content without going to a different page. For navigating to different pages within a site, use Navigation Tabs instead
There are 2-10 category titles
The category titles are relatively short and predictable.
Solution
o Present a single-line row of links immediately above the stacked panes of content they will control.
o Never stack multiple rows of tabs to control a single piece of content.
o Separate the links with the vertical bar character "" or through an equivalent graphic.
o Always show one tab as selected with its content visible
o Indicate the selected tab by highlighting the background of the "cell" around it. Yahoo! adds a "pointer" to the bottom of the selected tab.
o The content should be visually connected to the tab it is associated with and be visually bounded (usually by a box.)
o Only one content area may be visible at a time.
Maintaining the Metaphor
o Tabs should appear in the same location as the user clicks from one tab to another.
o Wherever possible, do not refresh the entire page upon selection of a new tab.
o Selecting a tab will not affect other parts of the page.
o Selecting a tab will not navigate to a different page or perform an action (beyond switching the visible content.
Rationale
o Tabs provide context. They give visual indication of a user's location within a body of information.
o Tabs build on a real world metaphor. The selected state is reinforced with the file folder tab metaphor of a folder physically in front of the others in the set.
o Tabs provide navigation. They provide the ability to navigate alternate content views.
Accessibility
o Allow the user to navigate across the tabs in a logical order with the Tab key.
o A focused tab can be selected with the Enter key.
o Indicate the active tab (pane) by one of these alternative means (in addition to visual indication):
§ Include a TITLE attribute with the word "active" into the link that was just activated.
§ Include an invisible graphic with an ALT attribute and a word "active" into the link.
§ Attach an ALT attribute with the word "active" to Yahoo!'s graphic that indicates active link.
[5] http://developer.yahoo.com/ypatterns/pattern.php?pattern=moduletabs (2006-03-05)
[GOF] Elements of Reusable object Oriented Software, GOF 1998
PAFSD Lecturer ask the class to research and note one other design pattern (not within the GOF 23 design patterns).
Name of Pattern:
Module Tab design pattern [5]
Problem
The user needs to navigate through one or more stacked panes of content without refreshing the page.
Applicability: (where and when used)
There are multiple panes of content, but there is space to only show one content pane at a time
The different panes of content do not need to be viewed in context with each other.
You need a way to switch between the content without going to a different page. For navigating to different pages within a site, use Navigation Tabs instead
There are 2-10 category titles
The category titles are relatively short and predictable.
Solution
o Present a single-line row of links immediately above the stacked panes of content they will control.
o Never stack multiple rows of tabs to control a single piece of content.
o Separate the links with the vertical bar character "" or through an equivalent graphic.
o Always show one tab as selected with its content visible
o Indicate the selected tab by highlighting the background of the "cell" around it. Yahoo! adds a "pointer" to the bottom of the selected tab.
o The content should be visually connected to the tab it is associated with and be visually bounded (usually by a box.)
o Only one content area may be visible at a time.
Maintaining the Metaphor
o Tabs should appear in the same location as the user clicks from one tab to another.
o Wherever possible, do not refresh the entire page upon selection of a new tab.
o Selecting a tab will not affect other parts of the page.
o Selecting a tab will not navigate to a different page or perform an action (beyond switching the visible content.
Rationale
o Tabs provide context. They give visual indication of a user's location within a body of information.
o Tabs build on a real world metaphor. The selected state is reinforced with the file folder tab metaphor of a folder physically in front of the others in the set.
o Tabs provide navigation. They provide the ability to navigate alternate content views.
Accessibility
o Allow the user to navigate across the tabs in a logical order with the Tab key.
o A focused tab can be selected with the Enter key.
o Indicate the active tab (pane) by one of these alternative means (in addition to visual indication):
§ Include a TITLE attribute with the word "active" into the link that was just activated.
§ Include an invisible graphic with an ALT attribute and a word "active" into the link.
§ Attach an ALT attribute with the word "active" to Yahoo!'s graphic that indicates active link.
[5] http://developer.yahoo.com/ypatterns/pattern.php?pattern=moduletabs (2006-03-05)
[GOF] Elements of Reusable object Oriented Software, GOF 1998
Design Patterns and Gang of Four (GOF)
LECTURE 3 (20-01-2007) - BLOGG 3
DESIGN PATTERNS
I now have an introductory knowledge of design patterns. In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design.
GOF defined design patterns as “a design pattern names, abstracts and identifies the key aspects of a common design structure that make it useful for creating a reusable objects design. The design pattern identifies the participating classes and instances, there role and collaborations, and the distribution of responsibilities.” [GOF]
TASK 1: (20-10-2007)
Select ONE of GOF Design Patterns out of the 23 design patterns and criticize all its elements
Creational Pattern – Builder Pattern
One of the reason why I chose this pattern for criticism is the fact that this pattern explains that the constructor of a class is outside the class, whiles in java, the constructor is written within the same class. I find it rather a disturbing and conflicting statement.
After careful evaluation of this Pattern from the GOF: Design patterns- elements of reusable object oriented software. I am moved to appreciate the pattern concept.
The builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations. [GOF]
[GOF] Design patterns- elements of reusable object oriented software, GOF, (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
If you are to a create a complex object independent of the parts that make up the object then, the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled and also the construction process must allow different representations for the object that is constructed.
The good consequences of builder pattern concepts are that it lets you vary a product's internal representation and also isolates code for construction and representation.
There is a need to catalogue each pattern created so it can be referred to and re-used. GOF created thirteen (13) elements of patterns under which each of the 23 GOF design patterns created is catalogue under.
Elements of patterns
Pattern name and classification
o Builder Pattern; this name uniquely identifies this pattern, this pattern is classified under creational patterns.
Intent
o The intention of this pattern is when complex objects are created, it seperates it’s construction from its representation so that the same construction process can be used to create more different representations.
o In my view I think Intent is a vital element and is necessary at all times when preserving patterns as it tells a user the intentions of the preserved pattern in the catalogue.
Also known as
o Just like humans can have other names, so patterns too.
o I critically think this element is not so necessary. There might be cases when a pattern will not have other known names.
Motivation
o This element presents a problem and the usefulness of the pattern to solve it in a given context.
o I critically think this element is important and must be documented whenever a pattern is been preserved.
Applicability
o This element highlights scenarios (context) areas in which the pattern might be applied to.
o I critically think this element is very important as it deals with the context area from which a problem is coming from.
Structure
o This element shows a pictorial image of the pattern suing class diagrams.
o I critically think this element in very important as a brings forward a comprehensive pictorial view of the pattern.
Participants
o This element shows all assembly parts. i.e. classes and objects used in the pattern.
o I critically think that this element is very vital as it shows all classes and objects and there functions and relationships.
Collaborations
o This element shows basically interaction of classes.
o I critically think that this element is vital as it will help developers to use the patten irrespective of there programming background.
Ø Consequences
o This element shows the resulting effects both positive and negative when this pattern is applied in system design.
o I critically think that this element is very vital as
§ It lets u vary a products internal representation
§ It isolates code for construction and representation
§ It gives you finer control over the construction process.
Implementation
o This element explains how the pattern is implemented, In builder pattern it states that its constructs it products in step by step fashion.
o I critically think that this element is very vital as it aids greatly in implementing the pattern.
Sample code
o In some cases it is not necessary to put a sample code. Can only be necessary to programmers who are working iwith same language in which the code is written.
o I critically think that this can be omitted if necessary, but in cases were there are multiply versions of the same code written in different languages, it will become useful.
Known uses
o Thie element is like a reference, for users to check out areas where the pattern have been implemented before.
o I critically think this element must be included as it shows confirmation that the pattern is actually a proven tested on.
Related Patterns
o This element shows other patterns that are directly linked, or have some relationship to the pattern
o I critically think it not necessary to include this element only in extreme cases were there are close ties between a pattern and the pattern under review.
Wednesday 7 March 2007
SOFTWARE PATTERNS AND FAQ
LECTURE 2 (13-02-2007) – SOFTWARE PATTERNS- BLOGG 2
After lecture 2 – PAFSD, I now have the basic knowledge of what software patterns is and can now define software patterns as an accepted proven solution to solve a recurring software engineering problem in a given context.
Patterns and Software Patterns FAQ’s
Q1. What is a pattern?
Ans: A pattern is a proven accepted solution to solve a recurring problem in a given context. If the context changes even if the problem is the same, then the solution changes too.
Q2. Why applying patterns to software engineering a good idea?
Ans: Benefiting from the knowledge and experience of other people who have put more effort into understanding contexts, forces, and solutions than you have done or want to do. Further, patterns can be more reusable than code, since they can be adapted so that you can build software to address particular special circumstances that cause you to be unable to reuse an existing component.
Q3. What is a software pattern?
Ans: Software patterns can be defined as an accepted proven solution to solve a recurring software engineering problem in a given software engineering context.
Q4. What is not a pattern?
Ans: A general solution to every design problem in a context is not a pattern. Solution to problems in a context that have worked only once is not a pattern.
Q5. Where can software pattern be applied?
Ans: Software patterns can be applied in software engineering development processes.
Q6. What is the difference between software patterns, frameworks, algorithms, and business objects?
Ans: Software patterns can be defined as an accepted proven solution to solve a recurring software engineering problem in a given software engineering context.
Whiles a framework is a set of cooperating classes that make up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes a framework to a particular application by subclassing and composing instances of framework classes. [2]
A pattern is not an implementation. It describes when, why, and how to go about creating an implementation or other engineering product.
An algorithm is basically a formula or set of steps for solving a particular problem.
A pattern describes how and why an algorithm may be apply in a given development context, along with guidance for applying them.
Business objects are objects in an object-oriented computer program that abstract the entities in the domain that the program is written to represent. For example, an order entry program needs to work with concepts such as orders, line items, and invoices and so on. Each of these may be represented by a business object. [3]
Q7. In real life can software patterns be used by both beginners and software specialists alike?
Ans: Software patterns can be used by both beginners and software specialists alike as it is said, if there is a proven software engineering solution to a problem in a given context, why not use it rather than creating the wheel. (Finding the solution to the problem from scratch may be a waste of time.
Q8. What is anti-pattern?
Ans: Anti-Pattern are Negative solutions that present more problems than they address. [4] A well formulated Anti-Pattern also tells why the bad solution looks attractive.
References:
[2] http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html#TOC_PatternElements#TOC_PatternElements 14/02/2000
[3] http://en.wikipedia.org/wiki/Business_object_(computer_science) 07:43, 5 October 2006
[4] http://www.antipatterns.com/briefing/sld003.htm, AntiPatterns :Refactoring software architectures, and projects in crisis SWEE 98 hays w. Mc Cormick
After lecture 2 – PAFSD, I now have the basic knowledge of what software patterns is and can now define software patterns as an accepted proven solution to solve a recurring software engineering problem in a given context.
Patterns and Software Patterns FAQ’s
Q1. What is a pattern?
Ans: A pattern is a proven accepted solution to solve a recurring problem in a given context. If the context changes even if the problem is the same, then the solution changes too.
Q2. Why applying patterns to software engineering a good idea?
Ans: Benefiting from the knowledge and experience of other people who have put more effort into understanding contexts, forces, and solutions than you have done or want to do. Further, patterns can be more reusable than code, since they can be adapted so that you can build software to address particular special circumstances that cause you to be unable to reuse an existing component.
Q3. What is a software pattern?
Ans: Software patterns can be defined as an accepted proven solution to solve a recurring software engineering problem in a given software engineering context.
Q4. What is not a pattern?
Ans: A general solution to every design problem in a context is not a pattern. Solution to problems in a context that have worked only once is not a pattern.
Q5. Where can software pattern be applied?
Ans: Software patterns can be applied in software engineering development processes.
Q6. What is the difference between software patterns, frameworks, algorithms, and business objects?
Ans: Software patterns can be defined as an accepted proven solution to solve a recurring software engineering problem in a given software engineering context.
Whiles a framework is a set of cooperating classes that make up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes a framework to a particular application by subclassing and composing instances of framework classes. [2]
A pattern is not an implementation. It describes when, why, and how to go about creating an implementation or other engineering product.
An algorithm is basically a formula or set of steps for solving a particular problem.
A pattern describes how and why an algorithm may be apply in a given development context, along with guidance for applying them.
Business objects are objects in an object-oriented computer program that abstract the entities in the domain that the program is written to represent. For example, an order entry program needs to work with concepts such as orders, line items, and invoices and so on. Each of these may be represented by a business object. [3]
Q7. In real life can software patterns be used by both beginners and software specialists alike?
Ans: Software patterns can be used by both beginners and software specialists alike as it is said, if there is a proven software engineering solution to a problem in a given context, why not use it rather than creating the wheel. (Finding the solution to the problem from scratch may be a waste of time.
Q8. What is anti-pattern?
Ans: Anti-Pattern are Negative solutions that present more problems than they address. [4] A well formulated Anti-Pattern also tells why the bad solution looks attractive.
References:
[2] http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html#TOC_PatternElements#TOC_PatternElements 14/02/2000
[3] http://en.wikipedia.org/wiki/Business_object_(computer_science) 07:43, 5 October 2006
[4] http://www.antipatterns.com/briefing/sld003.htm, AntiPatterns :Refactoring software architectures, and projects in crisis SWEE 98 hays w. Mc Cormick
Subscribe to:
Posts (Atom)