go back to school after a summer fooling around is never easy, but then you have to do. And Skep, recently joined the team sick, came from vacation with a new idea for his rts: he wants to make the units available to the player can be divided into teams , but does not want to be a simple grouping. He wants to ensure that the user is prompted to create a team through the group because you can cover the defects of a unit with the merits of another, so that the ability of an individual to become the skills of all: a doctor within the group, for example, means that all the soldiers learn to care slightly . In addition, each group thus created would be fun to assign a value of force that affects the outcome of the battle group. In this way create more homogeneous groups can make easy to overcome certain special missions.
The first idea was a simple array of soldiers as the data field of a new class CombatGroup. The idea has proved fallacious (!!!): suffered in this way, the code would prove difficult to modify and extend in case of updates, what would happen if we wanted to create groups of different type, such as an assault group and a group of spare drive? The second idea
jumped nell'insana mind of our young has been to exploit in a massive inheritance. His thought is to create subclasses of CombatGroup depending on the purpose of the team and add them to the soldiers one at a time. His idea is summed up in the following format
Even though this design provides a point in the hierarchy there is a list of some kind of soldiers in the team. Such a list provides methods to insert and remove elements and know that in the event of changes to the characteristics of a group would need to go to these methods also change.
The idea that comes to our aid is as simple as powerful and difficult to apply
E 'must always design our hierarchies so that are easily extendable but what extend should not be changed by the extension. What
second Skep completely solve the problem of maintaining a list of participating members of the team is a completely different approach. You can consider an item as a team of one-component? Sure, why not. Would it be possible then add more as teams made just told to form groups of several elements? It would make sense. In this way, you could probably use inheritance in an almost recursive and get the results of strength team and list of components without any list of items!
Helping our friends get funny as usual a design pattern, that the most friends call Decorator. The cold definition says
Let's see how to solve the problem points:
1. Create a group such as a AssaultGroup , initially empty
2. "Decorate" the group with a Soldier. Now the group contains an element.
3. "Decorate" the group with an Engineer.
4. To obtain the components GetComponents call () and let us consider the delegation to get the components. We do the same thing for the strength of the group.
How does, however, the delegation of the methods? We can think for one second to the group as a room.
At the room is completely empty, waiting to be decorated. Clearly the method calls GetComponents () and getGroupPower () give null result as if a hypothetical question was to ask these questions to the room would not receive response.
were decorated with an element, the room is filled with a person who sits at the door, so that if someone steps in to ask how many people are there and how strong is the group, she can answer on behalf group.
Each time the room is "decorated" by a new person, the line scale and the newest is at the door ready to provide the information if requested, also on behalf of the entire group.
To know how strong is the group for example, can certainly not scream "how strong are we?" aloud all respond and be forced to do the sums of all. This would give a unit a special ability that has no sense. (Suppose I am chief, who just are not able to count would be a casino). You might instead ask how strong is the last to communicate what is in the row in front of him, which adds value to its power and communicate in turn to the front. So that the door should not do is add the value that has come to own and communicate, just as they did everyone else. Such a thing is feasible to get a list of the group's capacity.
Once you understand the mechanism, we see how to create a schedule of classes for instantiating the decorator pattern for our case.
The focal point for understanding this design pattern is that objects and decorators are in the same hierarchy as the decorators are lower can be taken and used as components were real . Even if we use inheritance does not go against the principle of preferring the composition because agggiungiamo behavior to a group through the composition of objects: the genius is that all objects are of this subtype composition of the compound, could therefore be used in its stead. In addition, we untied from the static inheritance could add new behaviors at runtime.
Let 'code now. Today I take the good C + + instead of java, even if I put in the key interface (professionalism at historic lows), which clearly will implement an abstract class. We start with classes and CombatGroup AssaultGroup, presenting an implementation quite Natural
Take for example the method getGroupPower. Its implementation at this level is this. We do not care for any decoration in the future, give back only what we know directly, or the initial strength.
At this point we can move to codify the decorations. We have another abstract class that generalizes the decorators. It contains a reference to the decorated component to it, so that the delegation would go up the chain (as in the above example the value of passive force until the last item in the first row).
Ora passiamo alle decorazioni vere e proprie. Anche in questo caso l'implementazione del metodo getGroupPower non fa altro che sommare la forza particolare dell'unità a quella dell'intero gruppo. Questo è proprio il principio di delegazione delle responsabilità di cui parlavo prima.
This has always seemed quite unsubstantiated until I figured out how to make the whole operation. How do I create a group then? Here's the solution
Ok, now the pattern is complete. Decorator is extremely powerful and quite difficult to understand, since the idea of \u200b\u200bthe composition over inheritance is not intuitive at all from my point of view. In many cases it is preferred that a similar pattern we have already analyzed, namely the strategy. There are certainly similarities between the two, as they both add something to run in an orderly and flexible. The difference is in what to add: decorator is used to add behavior in terms of construction, or change the internal organs of an object and thus its capacity. Strategy deals rather closely the behavior as such, changing the "habits" of an object without touching the inside.
Decorator still has some major disadvantages:
- Although it is possible to dynamically add coportamento runtime, it can be removed without changing the nature of the object . This is in many cases it may be pointed out fatal. Moreover decorator is spesso usato nello sviluppo di interfacce grafiche, per aggiungere particolari quali bordi a componenti grafiche, quindi cose che non vengono mai più rimosse.
- Da un punto di vista di identità un componente e un decoratore non sono per niente la stessa cosa ma vengono trattati come se lo fossero . Questo punto, che è il senso proprio del pattern, è anche il suo difetto logico più vistoso.
- E' importante che le classi in cima alla gerarchia siano leggere, in quanto è necessario nei sottotipi assicurare la conformità delle interfacce è programmare classi decoratore con troppi metodi provoca una probabilità maggiore di errori.
- Decorator sfruttato in un progetto di grandi dimensioni può rivelarsi detrimental to the maintenance because it causes the generation of a large amount of very small classes. But of course it helps a lot the work of the designer.
Great Skep, again failed to find a way to keep me awake a few nights!
The first idea was a simple array of soldiers as the data field of a new class CombatGroup. The idea has proved fallacious (!!!): suffered in this way, the code would prove difficult to modify and extend in case of updates, what would happen if we wanted to create groups of different type, such as an assault group and a group of spare drive? The second idea
jumped nell'insana mind of our young has been to exploit in a massive inheritance. His thought is to create subclasses of CombatGroup depending on the purpose of the team and add them to the soldiers one at a time. His idea is summed up in the following format
Even though this design provides a point in the hierarchy there is a list of some kind of soldiers in the team. Such a list provides methods to insert and remove elements and know that in the event of changes to the characteristics of a group would need to go to these methods also change.
The idea that comes to our aid is as simple as powerful and difficult to apply
keep classes open to extension but closed to changes
E 'must always design our hierarchies so that are easily extendable but what extend should not be changed by the extension. What
second Skep completely solve the problem of maintaining a list of participating members of the team is a completely different approach. You can consider an item as a team of one-component? Sure, why not. Would it be possible then add more as teams made just told to form groups of several elements? It would make sense. In this way, you could probably use inheritance in an almost recursive and get the results of strength team and list of components without any list of items!
Helping our friends get funny as usual a design pattern, that the most friends call Decorator. The cold definition says
Decorator adds responsibility to an object dynamically. Also provides a flexible alternative to the extension to extend the functionality
Let's see how to solve the problem points:
1. Create a group such as a AssaultGroup , initially empty
2. "Decorate" the group with a Soldier. Now the group contains an element.
3. "Decorate" the group with an Engineer.
4. To obtain the components GetComponents call () and let us consider the delegation to get the components. We do the same thing for the strength of the group.
How does, however, the delegation of the methods? We can think for one second to the group as a room.
At the room is completely empty, waiting to be decorated. Clearly the method calls GetComponents () and getGroupPower () give null result as if a hypothetical question was to ask these questions to the room would not receive response.
were decorated with an element, the room is filled with a person who sits at the door, so that if someone steps in to ask how many people are there and how strong is the group, she can answer on behalf group.
Each time the room is "decorated" by a new person, the line scale and the newest is at the door ready to provide the information if requested, also on behalf of the entire group.
To know how strong is the group for example, can certainly not scream "how strong are we?" aloud all respond and be forced to do the sums of all. This would give a unit a special ability that has no sense. (Suppose I am chief, who just are not able to count would be a casino). You might instead ask how strong is the last to communicate what is in the row in front of him, which adds value to its power and communicate in turn to the front. So that the door should not do is add the value that has come to own and communicate, just as they did everyone else. Such a thing is feasible to get a list of the group's capacity.
Once you understand the mechanism, we see how to create a schedule of classes for instantiating the decorator pattern for our case.
The focal point for understanding this design pattern is that objects and decorators are in the same hierarchy as the decorators are lower can be taken and used as components were real . Even if we use inheritance does not go against the principle of preferring the composition because agggiungiamo behavior to a group through the composition of objects: the genius is that all objects are of this subtype composition of the compound, could therefore be used in its stead. In addition, we untied from the static inheritance could add new behaviors at runtime.
Let 'code now. Today I take the good C + + instead of java, even if I put in the key interface (professionalism at historic lows), which clearly will implement an abstract class. We start with classes and CombatGroup AssaultGroup, presenting an implementation quite Natural
class CombatGroup
{public:
CombatGroup ();
virtualGetComponents List ();
getGroupPower virtual int ();
/ / ...
}
AssaultGroup class: public CombatGroup
{private: int
_initialPower;
public: virtual int
getGroupPower ();
virtualGetComponents List ();
//...
}
Take for example the method getGroupPower. Its implementation at this level is this. We do not care for any decoration in the future, give back only what we know directly, or the initial strength.
int AssaultGroup: getGroupPower () {return
_initialPower;}
At this point we can move to codify the decorations. We have another abstract class that generalizes the decorators. It contains a reference to the decorated component to it, so that the delegation would go up the chain (as in the above example the value of passive force until the last item in the first row).
GroupDecorator class: public CombatGroup
{private:
CombatGroup _group;
public:
GroupDecorator (CombatGroup *);
virtualGetComponents List ();
getGruopPower virtual int ();
//...
}
ListGroupDecorator::getComponents() {
_group.getComponents();
}
int GroupDecorator::getGroupPower() {
_group.getGroupPower();
}
Ora passiamo alle decorazioni vere e proprie. Anche in questo caso l'implementazione del metodo getGroupPower non fa altro che sommare la forza particolare dell'unità a quella dell'intero gruppo. Questo è proprio il principio di delegazione delle responsabilità di cui parlavo prima.
class SoldierDecorator : public GroupDecorator {
private :
// unit rappresenta the drive that goes to join the group. This class is a container
/ / for it
Unit _unit;
int _power;
public:
SoldierDecorator (CombatGroup *);
getGroupPower virtual int ();
virstualGetComponents List ();}
/ / IMPLEMENTATION NOTE! Int
SoldierDecorator: getGroupPower () {return
this._power _group.getGroupPower + ();}
This has always seemed quite unsubstantiated until I figured out how to make the whole operation. How do I create a group then? Here's the solution
/ / create a group CO 2 soldiers, an engineer and a doctor
CombatGroup aGroup AssaultGroup = new ();
aGroup = new SoldierDecorator (aGroup)
aGroup = new SoldierDecorator (aGroup)
aGroup = new EngineerDecorator (aGroup)
aGroup = new MedicDecorator (aGroup)
aGroup.getGroupPower ();
Ok, now the pattern is complete. Decorator is extremely powerful and quite difficult to understand, since the idea of \u200b\u200bthe composition over inheritance is not intuitive at all from my point of view. In many cases it is preferred that a similar pattern we have already analyzed, namely the strategy. There are certainly similarities between the two, as they both add something to run in an orderly and flexible. The difference is in what to add: decorator is used to add behavior in terms of construction, or change the internal organs of an object and thus its capacity. Strategy deals rather closely the behavior as such, changing the "habits" of an object without touching the inside.
Decorator still has some major disadvantages:
- Although it is possible to dynamically add coportamento runtime, it can be removed without changing the nature of the object . This is in many cases it may be pointed out fatal. Moreover decorator is spesso usato nello sviluppo di interfacce grafiche, per aggiungere particolari quali bordi a componenti grafiche, quindi cose che non vengono mai più rimosse.
- Da un punto di vista di identità un componente e un decoratore non sono per niente la stessa cosa ma vengono trattati come se lo fossero . Questo punto, che è il senso proprio del pattern, è anche il suo difetto logico più vistoso.
- E' importante che le classi in cima alla gerarchia siano leggere, in quanto è necessario nei sottotipi assicurare la conformità delle interfacce è programmare classi decoratore con troppi metodi provoca una probabilità maggiore di errori.
- Decorator sfruttato in un progetto di grandi dimensioni può rivelarsi detrimental to the maintenance because it causes the generation of a large amount of very small classes. But of course it helps a lot the work of the designer.
Great Skep, again failed to find a way to keep me awake a few nights!
