Hello, I did some reasoning about OOP and it's advantages.
A lot of OOP fans say that "OOP is closer to our way of
thinking". This might be the case when you always used
classical OOP languages... Such argumentations can be
summarized as: OOP is great because OOP is great...
IMHO the advantages of OOP can be seen most when you think
in terms like interface and implementation. An interface
defines which methods are supported while the implementation
describes how this is done. Several classes with different
method implementations share the same interface. This
view is not something new. When you write to a file you use
the same interface (higher level printf or lower level write)
for harddisk files, console output and printer output. The
implementation does totally different things for this files.
UNIX uses the "everything is a file" philosopy for ages (even
network communication uses the file interface (see sockets)).
When there is only one implementation you can omit the
interface. Then it is not really OOP any more. But this is
not something bad. IMHO interfaces make only sense when there
are several implementations.
Things like inheritance have advantages but most programmers
prefer the has-a (the object has an element of a class)
relation over the is-a (the object has the superclass
mentioned) relation. This is done because the has-a relation
is easier to handle and to understand. For the same reason
multiple inheritance is not loved by programmers. Instead of
multiple inheritance it is often possible to use an
implementation which supports several interfaces.
Container librarys are often seen as advantages of OOP, but
they have nothing to do with OOP. Typical OOP containers have
no type checking for the elements. Type checked containers
usually use the generic/template concept which is a totally
independend concept and it can be used without any OOP.
In the classic OOP philosopy a message is sent to an object.
In the method the current object is referred with 'this' or
'self'. The other parameters use the same mechanisms as in
the procedural programming languages (value or reference
parameter). This classic OOP philosopy is called single
dispatch. One class decides which implementation is used.
Classical OOP fans think this unsymetrical situation is
normal. Every class has a table which uses method names as
index. This table contains a function pointer for each method.
IMHO it is better to come back to a symetrical situation.
The classes of all parameters together decide which implementation
is used. For long time OOP proponents this sounds strange, but
it is a more natural approach. This concept is called multiple
dispatch. When multiple dispatch is used some things change:
Methods do not belong to a class any more. Instead the methods
are "between" the classes. There is no 'this' of 'self' any more.
Instead there are just normal parameters. But how can you do this?
There are implementation types and interface types. It is
possible to declare than an interface type is implemented by an
implementation type. Objects are only created for implementation
types. A variable of an interface type just points to an object
of a corresponding implementation type (which implements the
interface). When you define a function you define just a classical
function from the pre-OOP era. When you call such a function
there is no runtime decision about which method should be called.
Additionally you can define interface (DYNAMIC) functions which
consist of the header of a function (The name of the function
and the types of the parameters). A dynamic function makes only
sense when at least one of the parameters has an interface type.
At runtime the dispatcher looks for the implementation types
of all parametes which have an interface type. If a function
is found it is called. The dispatcher can be implemented using
a multi dimensional table.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch.
|
