I've learned many new things about JAVA through pattern which I was totally unaware of 3 monts ago. I am sure if you spend some time with Design pattern you will find new ways of writing same program with better functionality. No doubt, quality and benefits design patterns bring to the software development process, especially in the areas of maintenance and code reuse is very valuable.
Those of you who are finishing BSc next year, try applying design patterns in your final year project application, I am sure you will be able to score more marks and its a very good opportunity for applying your knowledge before entering IT industry.
I wish this unit was in previous term so I could've use patterns in my project as well. However in evaluation chapter of my report I developed Abstaract factory pattern that suited my application and left it for future work.
I am very grateful to Dr Sri for always being at hand and all his support. And last but not least, all the readers for leaving comments and taking interest in my work.
Good luck with your coursework.
Regards
Sunday, 13 May 2007
Friday, 13 April 2007
Anti-Patterns
“Use identify and apply strategy towards Patterns and identify and remove for Anti-patterns” Dr M.G. Sri.
As we know patterns are good, effective solutions to a problem, identified, practiced and designed for reuse. However Anti-patterns are bad, ineffective solution to a problem identified and documented for others to avoid. Anti-patterns are useful not only because they notify you about the bad practices but also because it informs you about the ways to change the solution into healthier one if you find yourself caught up with an anti-pattern.
A good example of anti-pattern is spaghetti code, where the code is messy, difficult to read, modify and reuse. Another example is God Object Anti-pattern, where lot of other objects, operations and methods are handled by this object. Now these are bad practices and knowledge of them are useful for every programmer to avoid these ‘pitfalls’ at first place.
As we know patterns are good, effective solutions to a problem, identified, practiced and designed for reuse. However Anti-patterns are bad, ineffective solution to a problem identified and documented for others to avoid. Anti-patterns are useful not only because they notify you about the bad practices but also because it informs you about the ways to change the solution into healthier one if you find yourself caught up with an anti-pattern.
A good example of anti-pattern is spaghetti code, where the code is messy, difficult to read, modify and reuse. Another example is God Object Anti-pattern, where lot of other objects, operations and methods are handled by this object. Now these are bad practices and knowledge of them are useful for every programmer to avoid these ‘pitfalls’ at first place.
Friday, 23 March 2007
Strategy pattern
Strategy pattern
Strategy pattern is valuable where one algorithm has to be applied out of number of algorithms in real-time according to application needs.
The question in you mind must be that why use strategy and not if else or case statements, because that exactly what they do, choose one algorithm from others. An answer is yes it is similar but strategy pattern makes life easy. If-else and case statement can become very nested and complex. With strategy, to add another strategy or algorithm, strategy containing class code doesn’t have to be changed.
Good example from real life given by Pops[1] about credit card purchases. I’ll use UML diagram to explain better:
Strategy pattern is valuable where one algorithm has to be applied out of number of algorithms in real-time according to application needs.
The question in you mind must be that why use strategy and not if else or case statements, because that exactly what they do, choose one algorithm from others. An answer is yes it is similar but strategy pattern makes life easy. If-else and case statement can become very nested and complex. With strategy, to add another strategy or algorithm, strategy containing class code doesn’t have to be changed.
Good example from real life given by Pops[1] about credit card purchases. I’ll use UML diagram to explain better:
When we shop we can use different credit card it matter of choice which one to use. All creadit cards have different information in there magnetic strip, so these are different algorithms. Interface is the StripContents that is used while the implementation represents the TypeOfCard.
[1] Pops (n.d.) Components Tutorial, Retrieved from http://www.topcoder.com/tc?module=Static&d1=tutorials&d2=strategyPattern
Decorator Pattern
Decorator Pattern is used when components (instances of Component) are to be extended dynamically by functionality. Without changing the structure of a class, one class adds more functionality to other class.
Decorator eleminates the need for subclassing and add the additional behavior/funcionality at runtime.
I think decorator pattern can also be very helpful for coders when end user requests more additional features when task is almost complete. Because without changing the structure of one class coder can create another class with less effort and with less chances of logical errors, that will add all extra required features.
I think decorator pattern can also be very helpful for coders when end user requests more additional features when task is almost complete. Because without changing the structure of one class coder can create another class with less effort and with less chances of logical errors, that will add all extra required features.
Adapter Pattern
As name implies Adapter pattern is used to allow incompatible classes/objects work together. Without modifying the client’s object who wishes to use another object whose interfaces or data types doesn’t match, adapter object/class can be implemented to solve the problem.
Adapter pattern can be applied for classes and for objects.
In Class Adapter;
the adapter class multiple inherits adoptee class and the clients target (interface) class. Because JAVA does not permit multiple inheritances, either one has to be adapted as Java interface type.
In Object Adapter;
In Object Adapter; Adapter contains the instance of the Adaptee and inherits the Client’s Target interface. When Client calls Target object the request is translated into request of the Adaptee object.
Image Source:
http://staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/fig-GoF/PNG/adapter1.png
http://staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/fig-GoF/PNG/adapter2.png
Adapter pattern can be applied for classes and for objects.
In Class Adapter;
the adapter class multiple inherits adoptee class and the clients target (interface) class. Because JAVA does not permit multiple inheritances, either one has to be adapted as Java interface type.
In Object Adapter;
In Object Adapter; Adapter contains the instance of the Adaptee and inherits the Client’s Target interface. When Client calls Target object the request is translated into request of the Adaptee object.Image Source:
http://staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/fig-GoF/PNG/adapter1.png
http://staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/fig-GoF/PNG/adapter2.png
Tuesday, 27 February 2007
27 Feb 2007 Abstract Factory
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
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
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
Subscribe to:
Comments (Atom)