Identify aspects of your application that vary and separate from those that do not vary
Suppose Skep has decided to spend the free time between a cigarette and the next cigarette in a useful way: it has decided to design a simulation of war, perhaps an RTS. The game can simulate battles between soldiers for now ruled out armored vehicles or other amenities, for sheer simplicity (after all believed that good planning simulation, add items later is not so complicated). After a brief brainstorming session (from which came out for the most porn actresses names and insults) and 'time to design in the game, or the soldiers.
beginning Skep uses a standard technique of object-oriented programming, which creates a Soldier superclass from which all the different types of soldiers will inherit.
This clearly missing in this scheme is the ability to shoot, which Skep decide to implement a method shoot () in superclass Soldier.
The sick mind of Skep innvative always manages to produce ideas: one day decided that it would be great if your in the simulation are also present special soldiers, able to deal with other soldiers on the battlefield but are not able to shoot . Here the pattern is modified accordingly
Skep wanted to show everyone his skills in OO design, but made a serious mistake: the next day, when he started to do the first tests on its software, is a lot of healers who run for the field battle by killing enemies left and right, which was not clearly provided for the initial project. This is because the subclass inherits the method Healer shoot which is not defined as abstract as it indicates the order to shoot the gun, and it is hoped that the soldiers all shoot the same way if they have the same gun. Although it may seem trivial, the problem becomes serious when you have multiple subclasses that do not have the ability to shoot: take for instance the implementation of a class for masters, able to only give orders, or soldiers of genius, capable only to make bombs.
Skep, after yet another brainstorming (this time the main theme is "who will win the title? "), considers appropriate two completely different solutions:
1. Override
Skep think that might just make an override of the method to shoot all those classes who can not implement. The override would either give an implementation nothing about the method, so that when you ask for a unit that does not have the ability to shoot, it does not perform any action. But if one day were to invent some other peculiar behavior, such as a soldier who does not run and do not fly because Shoot, it should override both methods. And if it was worth for 20, 30 different classes, how much time would be spent unnecessarily in maintenance?
2. Interfaces
Skep finally understand that probably the inheritance is not the solution to your problem. Then, as a good Java programmer, she started on the interfaces, which presumed to solve the problem. Sums up his thoughts in this scheme:
But it is even worse than before! If the first thought wrong to override some methods in some instances, in which case the override is systematic for all subclasses that want to implement specified interfaces. Until it comes to a small number of classes the idea is applicable, but a maintenance of a detail of the shoot such method would lead to the need for change shoot all methods of all classes. Hard to think even for a workhorse like Skep.
At this point it is easy to think that the problem has already been solved by a very nice design any pattern, but Skep decides that he prefers the good old way, or by applying the sound principles of Object-Oriented Programming. (Actually Skep test for years to memorize the patterns correct but does not remember ever applying ...). The idea is, however, to write the software easier to maintain as possible, ie that the changes made by a correction cause the fewest side-effects can tap the fewest lines of code possible.
Here comes in. the planning principle discussed in this article: what changes need to be taken more often and encapsulated, so that it has the least possible impact on the rest of the code. The result will be fewer unexpected result from the code change and greater flexibility in the system .
To achieve this you must first define what are the parts that vary from class to class. Skep far as he knows, the only two methods are changing shoot and heal. The problem can be solved by creating two sets of separate classes, one to represent the behavior of "shoot" and another to represent the behavior "heal". For example, we have to all "shoot" a class that implements shoot () and a class that implements noShoot ().
The Soldier class is still superclass for the other, but we extrapolate the behavior to define the newly created external families, according to this scheme
In the next section we will see another important principle of object-oriented programming that will allow Skep to achieve what they want.
0 comments:
Post a Comment