The class is the description of the object and the object in an instance of the
class. For example the class of humans would describe us as having the attributes such as
arms, hands, legs and heads; and methods such as talk, think, eat, and sit. However each of us
would be an instance of that class, an object. If I can jump it’s because humans can jump, if I can laugh, it’s because humans can laugh. That is, the class defines the methods and attributes
for each object belonging to that class.
POLYMORPHISM :
Polymorphism is the ability for objects to respond differently to the same message, depending upon what type of object they are. For example, members from each of the following classes; Spouse, YoungerBrother, TotalStranger or LawEnforcementOfficer, are likely to behave differently when the hug method is called upon them.
Polymorphism becomes very useful when we have a group of related objects upon which we want to perform an operation, but those objects may need to react in different ways. For example, an ElectricCar will need to react differently to a FossilFuelCar when asked to accelerate.
There are two distinct forms of polymorphism in object oriented programming; interface and
inheritance polymorphism. Interface polymorphism is where two or more unrelated classes provide the same interface to certain methods. For example both sparrows and aeroplanes can fly. Although sparrows and aeroplanes fly in completely different ways, if we implement our classes in such a way that the methods have the same arguments and argument order then we have an example of interface polymorphism.
Inheritance polymorphism is where a child class inherits methods from an ancestor. Hence if the
Machine class, mentioned above, implemented a turn_on method then the DrinksMachine class
would inherit that method. If we were to call the turn_on method on a DrinksMachine object the
DrinksMachine object would behave as if it were merely a Machine object for that method call.
Ten rules for when to use OO :
1. When your design is large, or is likely to become large.
2. When data is aggregated into obvious structures, especially if there’s a lot of data in each
aggregate.
A person’s name is often not a good candidate for an object. A string of any length is still only a
single piece of information. If however, you wish to associate other information with the name,
such as age, address, phone number (enough data for example that you’d think to use a hash),
then you have a good case for an object.
my %person1 = (
name => "Julien Gileson",
age => 42,
address => "42 Halloway St"
);
3. When types of data form a natural hierarchy that lets us use inheritance.
Inheritance allows us to have a common set of operations shared by all similar objects, while
still allowing specific operations for each specialised type. For example, one may have a class
that tests the functionality on a website, and another that spiders a company’s local intra-net.
Both classes share a common base concerning access and parsing of web-pages.
4. When operations on data varies on data type.
Many similar types of data have similar operations. For example music stored on CD is a
different kind of data than music stored on disk in mp3 or ogg vorbis format. However, although
the details are different for all, all these kinds of music can be played. An OO model allows
code similar to the following, without needing to be concerned about the underlying format:
foreach my $song ($cd_track, $mp3, $ogg) {
$song->play();
}
5. When it’s likely you’ll have to add data types later.
Consider the above example. If our specification says that we want something which will handle mp3 files and music from CDs, we could code a solution to handle these two exact cases.
However, as requirements tend to evolve over time it may become likely that we’ll need to
handle ogg vorbis, midi, iTunes, and other formats too. A carefully designed OO model can allow us to accommodate these future requirements without significant changes to our application.
6. When interactions between data is best shown by operators.
Perl’s object model allows operators to be overloaded so that things work the way you’d like
them to. For example: $volume += 5;
is traditionally only meaningful if $volume is a number. However, with overloading, $volume
can represent the actual state of our speakers, and numerical adjustments can directly increase or decrease the energy output of the speakers.
7. When implementation of components is likely to change, especially in the same program.
Object oriented programming assists in data encapsulation. A class should be treated as a black box by the code which uses it. Defining clear interfaces allows the internals of the class to be changed as many times as necessary without affecting the rest of the project.
Thus if your class implements access to some data in a file, then the data’s format could change
from being in plain-text, to a flat-file database, to a full relational database without the rest of the application needing to change.
8. When the system design is already object-oriented.
9. When huge numbers of clients use your code.
In addition to encapsulation, object oriented code encourages modularisation. By breaking your
project up into separate modules it becomes easier to maintain and re-use. A change to a class
should not change any application code, making bug-fixes and improvements more
straightforward.
10. When you have a piece of data on which many different operations are applied.
Consider a piece of data representing sound. This sound can be mixed, adjusted, run backwards, have echo effects added and many other kinds of operations. By wrapping it in a Perl object we can associate these operations with this kind of data. The resulting code is often easier to read, understand, and maintain
11. When the kinds of operations have standard names (check, process, etc).
The traditional way of handling identical names for operations on unrelated data is to use the
data type in the subroutine name. For example.
sub process_person { ... }
sub process_payment { ... }
sub process_music { ... }
Objects side-step this issue by associating the operation with the data allowing all of the
subroutines to have the same name, but be in different name spaces.
So: Person::process(); Payment::process(); Music::process();
class. For example the class of humans would describe us as having the attributes such as
arms, hands, legs and heads; and methods such as talk, think, eat, and sit. However each of us
would be an instance of that class, an object. If I can jump it’s because humans can jump, if I can laugh, it’s because humans can laugh. That is, the class defines the methods and attributes
for each object belonging to that class.
POLYMORPHISM :
Polymorphism is the ability for objects to respond differently to the same message, depending upon what type of object they are. For example, members from each of the following classes; Spouse, YoungerBrother, TotalStranger or LawEnforcementOfficer, are likely to behave differently when the hug method is called upon them.
Polymorphism becomes very useful when we have a group of related objects upon which we want to perform an operation, but those objects may need to react in different ways. For example, an ElectricCar will need to react differently to a FossilFuelCar when asked to accelerate.
There are two distinct forms of polymorphism in object oriented programming; interface and
inheritance polymorphism. Interface polymorphism is where two or more unrelated classes provide the same interface to certain methods. For example both sparrows and aeroplanes can fly. Although sparrows and aeroplanes fly in completely different ways, if we implement our classes in such a way that the methods have the same arguments and argument order then we have an example of interface polymorphism.
Inheritance polymorphism is where a child class inherits methods from an ancestor. Hence if the
Machine class, mentioned above, implemented a turn_on method then the DrinksMachine class
would inherit that method. If we were to call the turn_on method on a DrinksMachine object the
DrinksMachine object would behave as if it were merely a Machine object for that method call.
Ten rules for when to use OO :
1. When your design is large, or is likely to become large.
2. When data is aggregated into obvious structures, especially if there’s a lot of data in each
aggregate.
A person’s name is often not a good candidate for an object. A string of any length is still only a
single piece of information. If however, you wish to associate other information with the name,
such as age, address, phone number (enough data for example that you’d think to use a hash),
then you have a good case for an object.
my %person1 = (
name => "Julien Gileson",
age => 42,
address => "42 Halloway St"
);
3. When types of data form a natural hierarchy that lets us use inheritance.
Inheritance allows us to have a common set of operations shared by all similar objects, while
still allowing specific operations for each specialised type. For example, one may have a class
that tests the functionality on a website, and another that spiders a company’s local intra-net.
Both classes share a common base concerning access and parsing of web-pages.
4. When operations on data varies on data type.
Many similar types of data have similar operations. For example music stored on CD is a
different kind of data than music stored on disk in mp3 or ogg vorbis format. However, although
the details are different for all, all these kinds of music can be played. An OO model allows
code similar to the following, without needing to be concerned about the underlying format:
foreach my $song ($cd_track, $mp3, $ogg) {
$song->play();
}
5. When it’s likely you’ll have to add data types later.
Consider the above example. If our specification says that we want something which will handle mp3 files and music from CDs, we could code a solution to handle these two exact cases.
However, as requirements tend to evolve over time it may become likely that we’ll need to
handle ogg vorbis, midi, iTunes, and other formats too. A carefully designed OO model can allow us to accommodate these future requirements without significant changes to our application.
6. When interactions between data is best shown by operators.
Perl’s object model allows operators to be overloaded so that things work the way you’d like
them to. For example: $volume += 5;
is traditionally only meaningful if $volume is a number. However, with overloading, $volume
can represent the actual state of our speakers, and numerical adjustments can directly increase or decrease the energy output of the speakers.
7. When implementation of components is likely to change, especially in the same program.
Object oriented programming assists in data encapsulation. A class should be treated as a black box by the code which uses it. Defining clear interfaces allows the internals of the class to be changed as many times as necessary without affecting the rest of the project.
Thus if your class implements access to some data in a file, then the data’s format could change
from being in plain-text, to a flat-file database, to a full relational database without the rest of the application needing to change.
8. When the system design is already object-oriented.
9. When huge numbers of clients use your code.
In addition to encapsulation, object oriented code encourages modularisation. By breaking your
project up into separate modules it becomes easier to maintain and re-use. A change to a class
should not change any application code, making bug-fixes and improvements more
straightforward.
10. When you have a piece of data on which many different operations are applied.
Consider a piece of data representing sound. This sound can be mixed, adjusted, run backwards, have echo effects added and many other kinds of operations. By wrapping it in a Perl object we can associate these operations with this kind of data. The resulting code is often easier to read, understand, and maintain
11. When the kinds of operations have standard names (check, process, etc).
The traditional way of handling identical names for operations on unrelated data is to use the
data type in the subroutine name. For example.
sub process_person { ... }
sub process_payment { ... }
sub process_music { ... }
Objects side-step this issue by associating the operation with the data allowing all of the
subroutines to have the same name, but be in different name spaces.
So: Person::process(); Payment::process(); Music::process();
Comments