27 Feb 2007
Today’s lesson was entirely related to Abstract Factory, where we covered almost all of it. Good discussion took place where I believe I was asking most of the questions because I read about Abstract Factory in advance. All readers especially for those who didn’t attend the class I hope my notes will be helpful.
Abstract Factory
In abstract factory without specifying concrete classes we can create set/families of related or dependent objects.
Lets take example of pasta maker that makes different types of pasta i.e. spaghetti, rigatoni, spiral etc. the shape of pasta depends on the pasta maker ‘disk’ which makes different shapes. Each specific pasta disk is a factory because they make different types of pasta. Whereas pasta maker is abstract factory. When we place the disk on the maker, the factory, which is disk, inherits the properties from the Abstract Factory (pasta maker). Pasta maker doesn’t care what disk is doing. Start the maker and shapes starts coming out. Now lets go back to the definition, “without giving all the details of concrete classes” that is, without giving the details of size and shape of pasta we require, we can make families or types of pasta (spaghetti, rigatoni, spiral etc.)
Of course in real world, every time we’ll have to change the disk but in abstract factory you can imagine that you can put all the disks once and wouldn’t require changing it manually.
Another example can be of a printer, that has different color cartridges(factory) in the printer(abstract factory). Client only deals with the printer(abstract type) without knowledge or defining which cartridges to use. Client uses the printouts(objects) coming from the printer (abstract factory)
In software programming factory is where the objects are defined and the intent of this pattern is to use/create these objects when required straight from the source without changing the concrete class or rewriting the code. However this pattern increases the complexity and extra work in initial coding.
I’ vent written any code yet but I have come across very good example of Abstract factory coding and UML diagram
UML :
http://www.fluffycat.com/javasource/javapatterns/UML/AbstractFactory.jpg
Abstract Factory
http://www.fluffycat.com//javasource/javapatterns/AbstractSoupFactory.txt
Concrete Factories
http://www.fluffycat.com//javasource/javapatterns/BostonConcreteSoupFactory.txt
http://www.fluffycat.com//javasource/javapatterns/HonoluluConcreteSoupFactory.txt
Test Abstract Factory
http://www.fluffycat.com//javasource/javapatterns/TestAbstractSoupFactory.txt
Tuesday, 27 February 2007
27 Feb 2007 Course Work --- D Day
27 Feb 2007
We have received the coursework and Ms Jane Chandler the course coordinator, cleared almost all questions related to it.
The coursework seems very reasonable, in fact easy if I manage to complete the designing and coding bits early enough. I read through some of the patterns needed to answer coursework’s Task1 from Book “Design Patterns in Java” and from the net. Didn’t find these patterns very difficult but still need lecturers help to understand better.
In a nutshell, all operations are initiated today towards the success of design pattern unit, so think it’s tolerable to call today a D Day.
Free e-book available online at www.patterndepot.com/put/8/DesignJava.PDF
We have received the coursework and Ms Jane Chandler the course coordinator, cleared almost all questions related to it.
The coursework seems very reasonable, in fact easy if I manage to complete the designing and coding bits early enough. I read through some of the patterns needed to answer coursework’s Task1 from Book “Design Patterns in Java” and from the net. Didn’t find these patterns very difficult but still need lecturers help to understand better.
In a nutshell, all operations are initiated today towards the success of design pattern unit, so think it’s tolerable to call today a D Day.
Free e-book available online at www.patterndepot.com/put/8/DesignJava.PDF
Wednesday, 21 February 2007
Distributed result set iterator Pattern
In this post I would give slight insight into a pattern that is not a GoF pattern and is in use today.
After some research on past research papers I found very interesting pattern made by Brad Long known as Distributed result set iterator. It is used for Retrieving large amounts of information over wide area networks, including the Internet.
Since the public and industry demand for fast transmission of large amount of data is increasing, various problems arise when big chunks of data and information are accessed from the database over the internet. Issues like response delay, fault tolerance and lack of direct memory access to data serving resources are major concerns. To meet the demands and deliver consumer’s request for immediate, prompt data/information, distributor result set iterator design pattern is developed that tackles such data related issues, where user request for data from client end to the remote server, both residing on different sites on the internet.
This pattern has been incorporated into Oracle corporation software development framework.
Source: http://cat.inist.fr/?aModele=afficheN&cpsidt=15838640
After some research on past research papers I found very interesting pattern made by Brad Long known as Distributed result set iterator. It is used for Retrieving large amounts of information over wide area networks, including the Internet.
Since the public and industry demand for fast transmission of large amount of data is increasing, various problems arise when big chunks of data and information are accessed from the database over the internet. Issues like response delay, fault tolerance and lack of direct memory access to data serving resources are major concerns. To meet the demands and deliver consumer’s request for immediate, prompt data/information, distributor result set iterator design pattern is developed that tackles such data related issues, where user request for data from client end to the remote server, both residing on different sites on the internet.
This pattern has been incorporated into Oracle corporation software development framework.
Source: http://cat.inist.fr/?aModele=afficheN&cpsidt=15838640
Tuesday, 20 February 2007
20 Feb 2007 Design Patterns, Zero to 60 in 3 seconds (i mean 3 weeks)
20 Feb 2007
In this third lesson today we learned what Design Patterns are, people behind its origin and the way they preserve it.
In a nut shell in software engineering Design Patterns are solutions to the design problems in a context. Firstly found in 1987 by Christopher Alexander but gained popularity after the book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al in 1994. They documented each pattern in way that it will contain enough information about the problem, the context and salutations with sample code.
Todays task was to choose one of the GoF design patterns out of 23 and try criticising all its elements.
I think criticising a work done by professional with experiences over 40 years is very difficult especially by the person who is new to patterns. but I suppose it will help me understand the pattern I have chosen better, how the elements are preserved and what do they contain. Anyhow, I have chosen Facade pattern. There is no specific reason why I choose it; I guess I just liked the name.
FACADE
Intent
As the name implies we talk about the intention behind creating this pattern. Façade is very simple; it basically gives one (high level) interface to the number of interfaces in the subsystem. Thus it makes easier to oversee underlying interfaces in the subsystem.
Motivation
Adding an additional interface or system over subsystem helps reduce complexity, communication and dependencies between subsystems and that why Façade is introduced to provide unified facility.
Applicability
In other words places where it is suitable to apply Facade
In this third lesson today we learned what Design Patterns are, people behind its origin and the way they preserve it.
In a nut shell in software engineering Design Patterns are solutions to the design problems in a context. Firstly found in 1987 by Christopher Alexander but gained popularity after the book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al in 1994. They documented each pattern in way that it will contain enough information about the problem, the context and salutations with sample code.
Todays task was to choose one of the GoF design patterns out of 23 and try criticising all its elements.
I think criticising a work done by professional with experiences over 40 years is very difficult especially by the person who is new to patterns. but I suppose it will help me understand the pattern I have chosen better, how the elements are preserved and what do they contain. Anyhow, I have chosen Facade pattern. There is no specific reason why I choose it; I guess I just liked the name.
FACADE
Intent
As the name implies we talk about the intention behind creating this pattern. Façade is very simple; it basically gives one (high level) interface to the number of interfaces in the subsystem. Thus it makes easier to oversee underlying interfaces in the subsystem.
Motivation
Adding an additional interface or system over subsystem helps reduce complexity, communication and dependencies between subsystems and that why Façade is introduced to provide unified facility.
Applicability
In other words places where it is suitable to apply Facade
- A simple interface is required to replace a complex subsystem
- Numerous dependencies exist between the implementation (abstract) class and client
- Also for layering the subsystem
Structure
Every pattern will have structure of its own. A diagram is normally used to describe the structure, which makes understanding very easier.
The structure that Façade adds to the system is more understandable using diagram, but for now Use this example to understand. As we go the Mc Donald’s Drive Thru Only and order something, one person goes and brings fries, burger and drinks to the window. There aren’t different windows for fries, drinks or burgers. So that only ONE Window is acting as a Façade.
Participants
Participants are the bodies making the pattern function. Thinking of the food again, as we have ingredients part for every dish in cookbook, we also have participant elements for every pattern in GOF book.
Facade (Compiler)
Subsystems classes (Scanner, Parser, ProgramNode, etc.)
Collaborations
In collaboration we talk about how and what mingles with the pattern, which is Façade here.
Client uses Façade as a middle man to communicate with the subsystem objects and thus client do not have to access subsystems objects directly.
Consequences
Usage of every pattern will bring some end result, its not necessary that consequences will always be beneficiary, it may have some shortcomings too. Good descriptions will have all, the Benefits, Shortcomings of the pattern and Advice on what to do about the shortcomings. Some benefits of using Façade is that It makes subsystem easier to use and reduced complex dependencies between objects. However it it gives an option between ease of use or generality because it does not prevent subsystem classes useage.
Implementation
Here we know that the method of implementing the pattern will be advised but useful tricks of it be will be helpful too, and not to forget the things to avoid during implementation.
In Façade when implementing:
-The pairing between clients and the subsystem can be reduced even further by making Facade an abstract class with concrete subclasses for different implementations of a subsystem.
- Making subsystem classes private would be useful,
Sample Code
Here we put the sample code to show how lay pattern; Façade on the complier
Known Uses
For beginners like me, this element is very helpful t understand in greater dept by looking at the real examples of the system where it is used or can be used.
Related Patterns
A brief details about which patterns are similar or can be linked to Façade.
Mediator and abstract factory pattern can be ralted and can be used alongside.
I hope the reader will get some knowledge about Façade and the way patterns are documented. And hope you enjoy reading it as much as I enjoyed in writing it.
Source: http://www.javaprogrammingworld.com/java-design-patterns.doc
Wednesday, 14 February 2007
14 Feb 2007 Five FAQs about Software Patterns
Still at this point there might be few doubts about Patterns and Software Patterns, so I wrote few Frequently Asked Questions to help you understand it better.
Q1 How to differentiate between pattern and what seem like pattern?
Patterns are tried and tested theories, they are not solution that has worked once or is applicable to every context.
Business objects, Frameworks, templates, algorithms and libraries are not patterns.
Q2 What are Software patterns and where this concept is adapted from?
Software Patterns are software solution to an engineering problem in particular context.
The concept of software pattern is adapted from construction engineering.
Q3 What are the benefits of patterns in software engineering?
Patterns helps to improve software quality, reduced engineering time, provide reusability and pass the knowledge from expert to beginners in better understandable form.
Q4 What about the creativity and different approaches of a developer?
Imposing rigid design rules is not the objective of design patterns. Instead, the intent is to ensure that initial designs are made effectively so that it can be reused, easily maintained and easy to understand. Also recurring problems can be solved using design patterns.
Q5. What are anti-patterns?
Anti-patterns are bad solutions to a problem applied in wrong context. They can be used to aviod design problems in first place and to come out of a problem if one find himself in such case.
Thank you for reading and please comment
Q1 How to differentiate between pattern and what seem like pattern?
Patterns are tried and tested theories, they are not solution that has worked once or is applicable to every context.
Business objects, Frameworks, templates, algorithms and libraries are not patterns.
Q2 What are Software patterns and where this concept is adapted from?
Software Patterns are software solution to an engineering problem in particular context.
The concept of software pattern is adapted from construction engineering.
Q3 What are the benefits of patterns in software engineering?
Patterns helps to improve software quality, reduced engineering time, provide reusability and pass the knowledge from expert to beginners in better understandable form.
Q4 What about the creativity and different approaches of a developer?
Imposing rigid design rules is not the objective of design patterns. Instead, the intent is to ensure that initial designs are made effectively so that it can be reused, easily maintained and easy to understand. Also recurring problems can be solved using design patterns.
Q5. What are anti-patterns?
Anti-patterns are bad solutions to a problem applied in wrong context. They can be used to aviod design problems in first place and to come out of a problem if one find himself in such case.
Thank you for reading and please comment
Tuesday, 6 February 2007
6 Feb 2007 Patterns!! whats that?
Understanding of Pattern
Today, in the very first lesson we discussed what patterns are and where this whole idea of design patterns came from. So here we go! Basically we use patterns to make life easy and instead of reinventing a wheel over and over again, we can create pattern once and use the same pattern to solve same or similar given problem in particular context. For instance, reaching from one destination to another lets say your home to work place, there can be numerous ways to reach there but we always take the same route why? Two reasons, either because we know that we’ll reach there safely on time or because we don’t want to spend time and effort looking for direction to reach there. This idea is adapted in software development to save time and effort. Thus, a pattern is more than just a guide, outline or blueprint, in fact we can call it imitate solution for a problem in particular context.
For better understanding I will take an example from real life
Problem: Get Money
Context: Insufficient funds to pay bills, tuition fees, transport and accommodation costs. Not eligible for Bank loan, No friends are willing to lend money, physically unable to work due to medical condition. No criminal convictions so far and not interested to get any to get money. However eligible to apply for income support.
Solution: Apply for benefits
Today, in the very first lesson we discussed what patterns are and where this whole idea of design patterns came from. So here we go! Basically we use patterns to make life easy and instead of reinventing a wheel over and over again, we can create pattern once and use the same pattern to solve same or similar given problem in particular context. For instance, reaching from one destination to another lets say your home to work place, there can be numerous ways to reach there but we always take the same route why? Two reasons, either because we know that we’ll reach there safely on time or because we don’t want to spend time and effort looking for direction to reach there. This idea is adapted in software development to save time and effort. Thus, a pattern is more than just a guide, outline or blueprint, in fact we can call it imitate solution for a problem in particular context.
For better understanding I will take an example from real life
Problem: Get Money
Context: Insufficient funds to pay bills, tuition fees, transport and accommodation costs. Not eligible for Bank loan, No friends are willing to lend money, physically unable to work due to medical condition. No criminal convictions so far and not interested to get any to get money. However eligible to apply for income support.
Solution: Apply for benefits
Subscribe to:
Comments (Atom)