The Command Pattern, is a very useful pattern when wanting a client to call a method of an object but keep all information of that particular object not only hidden but interchangeable with other objects.
The way the command pattern hides the information regarding the target is by delegating to the wrapped object within.
a Command Abstract defines the structure for all subclasses Commands.
public class aCommand{
private var _targetObject:Object
public function aCommand(obj:Object):void{
_targetObject-obj
}
public function execute():void{
//throw new IllegalOperationError(’Abstract methods must be overriden’)
}
}
When a subclass of aCommand are created, an object that will be the target which a method will be called upon will be delegated to when a client calls the execute().
Its the concrete class of the aCommand which will hold specifics about the method it will trigger.
By delegating to the method from within a type aCommand, the only thing that our client must know is that there is a type aCommand which it must call execute upon.
The command pattern utilizes strategy method to be interchangeable by declaring a type of aCommand and delegates through composition to a receiver.
The factory method is a simple concept to grasp, but not as easy a task to understand why to use it.
The factory method Pattern, is dubbed such that a subclass will override the method of its superclass.
This means the super class is in charge of crafting the signature of the method that the subclasses must adhere while the subclass implements in any way shape or form the return type its signature calls for.
FactoryMethod Design Pattern
At first glance, the factory method pattern appears to be a proxy to a product. But beacause you must import the Concrete Factory into your current client .as file, why would you even need to use a factory method at all?
The answer is not because its easy to update or because it separates the client from the product, although these are very accurate. Its in the way you need to see how its useful. What this did was create a second step to creating your classes, so if you were to use this concrete class in many places throughout your application, rather than hunting those instantiations down, you can go right to the 1 concrete class and make changes that are necessary.
If you used the product directly rather than the creator you would have to physically adjust each instance.
Regular Expression
1. RegExp.text(string) returns a Boolean
2. RegExp.exec(string) returns an Object
3. String.search(pattern) returns an int
4. String.match(pattern) returns an Array
5. String.replace(pattern, replace) returns a String
Abstraction by definition in a nutshell means vague. Consider an abstract class to have just enough to get a point across yet absent of specifics and details giving the abstraction a much larger group to make up of similar items and represent a common thing.
Lets use the example: the Guitar.
If we abstract a guitar we would recognize its abstraction to be one that has a model, has a price, has a number of strings, as well as a sound type. This is what embodies the object guitar. All guitars fall into this abstraction yet as their own individual class they have the ability to fill in the gaps the abstraction left out.
Abstract classes should never be instantiated but rather used as a type to allow like classes to be interchangeable.
Key Features:*
Abstractions hold as much overall information as required to make as many classes be similar. The more finite information you add will slowly turn an abstraction into a concrete class, so one must be certain to give careful consideration to what groups these particular items together.
It is actually possible to create an XMLList that meets more than one condition. The way to do this is a bit linear but will works. Each time you compare an XML element with a condition, you are able to follow up the expression with a request. In most cases you would ask for the name of the element or text or attribute, but we can use this to our advantage and keep checking for conditions to return to a list.
consider the usual way to create an XMLList:
myXMLList:XMLList= xml..childElement.(@identification<=3)
As you know my XMLList will be populated with any node that contains an attribute labeled identification that holds a value that is less than or equal to 3.
Now what if i wanted to know what the value was :
myXMLList:XMLList= xml..childElement.(@identification<=3).@identification
this expression will not only populate my list with the following but because i am still on the same index, i can continue to use the current xml node index to retrieve a value, in this case, the current xml Nodes attribute identification which gives me 2.
Utilizing the same method to find out what that value is, we can once again add another condition to choose whether we want to populate our xmlList with the following node.
myXMLList:XMLList= xml..childElement.(@identification<=3).(@identification!=2)
This statement will only push an element into our xmlList that has an attribute labeled identification which must be either 3 or less, but can not be 2.
