Showing posts from January, 2012

Design Patterns Series 16 - Command Pattern

Today we will discover another pattern from our design patterns list, The Command Pattern   The Command Pattern : The Command Pattern  lets you package complex commands into a single one. Rather than having to preform the multiple steps needed to execute each command every time, you can create a bunch of ready-to-use command objects, each of which can handle multiple steps internally. Each command is already configured with  its target and the action it's supposed to perform, so a set of command objects can act as a ready-made toolkit, already configured and all set to operate on the target objects they're supposed to handle. The Command Pattern  says you should encapsulate all the separate actions into objects configured for specific targets. This gives you a number of objects that act like a set of tools, ready to be used. In other words, the idea here is encapsulation.  You are encapsulating a set of complex actions, targeted at a particular target, into an easily h

Design Patterns Series 15 - State Pattern

This Post will be about The State Pattern where an object keeps track of its internal state, and can change its behavior based on that state. The State Pattern : The State Design Pattern will " Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. " In other words your code should keep track of an internal state. Any part of the code can check what the current state is and react accordingly. When you use the State Pattern , any part of your code can check what state is current. That clarify and centralize the workings of very large pieces of code because you have control over what far-flung code segments do, just by changing the current state. In general, The State Pattern is useful when you have got a lot of code that's getting more and more murky and complex. If you can compartmentalize the working of what you are trying to do into a set of independent states, you can compartmentalize your code.

Design Patterns Series 14 - Composite Pattern

This post will be about the second pattern in the alliance. In the last post we explored first pattern in this alliance, the Iterator Pattern , and today is the time of  Composite Pattern . The Composite Pattern : The Composite Pattern  is all about creating tree-like structures where the leaves in the structure can be treated in the same way as the branches(which are substructures that can contain multiple leaves, as well as other branches). The idea here is that, to make life easier, you should be able to treat the leaves and compositions of leaves in a tree structure the same. You use the Composite pattern  to " Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformally ". That is typical of Composite Pattern - when you ask a branch to perform some action, it iterates over all its contained leaves and branches. The insight behind The Composite Pattern is reall

Design Patterns Series 13 - Iterator Pattern

This post and the next will be about two allied patterns: the Iterator Pattern and the Composite Pattern . The Iterator Pattern: The Iterator Pattern gives you a way of accessing the elements inside an object without having to know the internal details of that object. When you dealing with a collection of objects, The Iterator Pattern  is the ideal solution. You can use the Iterator Pattern  to " Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. " In other words, iterators are designed to let you handle many different kinds of collections by accessing their members in standard, accepted way, without having to know the internal details of those collections. The Iterator Pattern is especially important when the collection you are creating is made up internally of separate subcollections, as when you have mixed hashes with array lists, for example. The design insight here is one of what’s called

Design Patterns Series 12 - Builder Pattern

Today we have a date with another pattern that give you a clever way of dealing with adapting the process of creating objects. previous post we explored The Template Method pattern  today we will explore its twin,  Builder Pattern . Builder Pattern: We use the Template Method Pattern when we have a multi-steps algorithm with in a certain order and we want to customize some steps. But what about if the number of steps and its order differs from one case to another?!!!!!. In Builder Pattern you don't inherit a template method anymore and then customize that method to create your own object. Instead, to create different types of objects, you allow client code to use different builder objects. The client code now sets the number and sequence of the steps in the algorithm, and selects which builder to use. The Builder Pattern let you " Separate the construction of a complex object from its representation so that the same construction processes can create different repre

Design Patterns Series 11 - Template Method Pattern

This post and the next will be about two patterns that give you clever ways of dealing with adapting the process of creating objects: The Template Method Pattern and Builder Pattern . The Template Method Pattern: The Template Method pattern lets sub-classes redefine the steps involved in creating an object.The Template Method will " define the skeleton of an algorithm in an operation, deferring some steps to sub-classes. Template Method lets sub-classes redefine certain steps of an algorithm without changing the algorithm structure. " You should use the Template Method pattern when you have an algorithm that is made of multiple steps, and you want to be able to customize some of those steps. Note That if you want to rewrite everything from scratch every time - if every step has  to be customized by writing it from scratch - then you have no need of a template. Only if you have steps that are shared by various implementations of the algorithm do you need to work with

How to prepare your machine for developing android apps?

In this post I will state the required steps that you have to do for making your machine ready to develop your android applications. I think what happened with me happened with you too, when anyone starts to learn a new technology, language, or application he first should know how to prepare its environment/install this new thing into his machine. He follows the preparation/installation instruction and go ahead. once he made that and continue his learning process, he forget how to prepare/install these things. If his machine is crashed or want to prepare another machine, he will refer to prepare/installation chapter again. That happened with me when I learned Android on Win XP Then installed Win7 on my machine.So I thought it will be better if I write a post to keep these steps in brief. As you know (or may not!!!!!!!!!!!) android platform using Java programming language. That means we want JDK to develop and run our android application (on emulator) and we want any java IDE

Design Patterns Series 10 - Facade Pattern

Similar to Adapter pattern, that we explored in the previous post , there is another design pattern that work in much the same way, but it has different purpose. Facade Pattern : The facade pattern gives you a wrapper that makes the original code easier to deal with.It makes an OOP interface easier to use. it's fundamentally a design issue - if an object or class interface is too hard to work with, the facade pattern gives you a front end to that interface to make it easier. The facade pattern should provide a unified interface to a set of interfaces in a system. Facade defines a higher level interface that makes the subsystem easier to use. The idea is simple; a facede just simplifies the interface between a class or object and the code that makes use of that class or object. You usually use the facade pattern when you cannot rewrite the code you wish were simpler. Although using a facade can fix the problem, but it adds another layer, and if the underlying code changes,