What is your weightage of the 3 characteristics of Object-Oriented Programming....

  • Thread starter Thread starter G.Ashok
  • Start date Start date
G

G.Ashok

Hi All,

What is your weightage of the 3 characteristics of Object-Oriented
Programming
i.e. Inheritance, Encapsulation and Polymorphism. for a total of 100%

Please quote your values and let's discuss how the people thinking about OOP

:-)
Regards,
....@shok
 
What is your weightage of the 3 characteristics of Object-Oriented
Programming
i.e. Inheritance, Encapsulation and Polymorphism. for a total of 100%
Click to expand...

What about Aggregation, Composition and Delegation ?

Joanna
 
I don't know about "relative weightage"... I don't know if that even
means anything.

However, I claim that Encapsulation is usually the principle that has
the most ready application... it's easiest to see immediate and direct
advantages to encapsulation, so it's easy for old procedural
programming hacks like me to see what it's for.

Next comes Inheritance, which doesn't make a whole lot of sense unless
you first understand encapsulation. After writing a lot of stand-alone,
encapsulated classes, it starts to make sense why you'd want
inheritance.

Finally, Polymorphism is the most abstract of the three. Once you have
encapsulation and inheritance, you start to see scenarios in which
polymorphism would be useful.

This says nothing about their relative importance to success of
software projects, or their frequency of use in the industry. It's just
the order in which I recommend that programmers new to O-O tackle them,
becaues the benefits of each tend to be clearer when approached this
way.
 
Joanna,

Delegation, Containment, are all I think design patterns and not key
characteristics of OOP. These are all used in VB6 like langauages. Rest of
the things are conceptual terms of OOA and OOD etc. of cource all are
applied to OO.

Regards,
....Ashok


| "G.Ashok" <[email protected]> a écrit dans le message de | OzXuv5#[email protected]...
|
| > What is your weightage of the 3 characteristics of Object-Oriented
| > Programming
| > i.e. Inheritance, Encapsulation and Polymorphism. for a total of 100%
|
| What about Aggregation, Composition and Delegation ?
|
| Joanna
|
| --
| Joanna Carter
| Consultant Software Engineer
|
|
 
G.Ashok said:
Delegation, Containment, are all I think design patterns and not key
characteristics of OOP. These are all used in VB6 like langauages. Rest of
the things are conceptual terms of OOA and OOD etc. of cource all are
applied to OO.
Click to expand...

Encapsulation and polymorphism are no typical OO features too, they can be
implemented in simple procedural programming languages up to a certain
extent.

PIE (polymorphism, inheritance, and encapsulation) is a minimal subset of
language features which are required for a programming language language to
be called an object-oriented programming language. Each of the features
alone doesn't necessarily have to do with object-orientation.
 
#1 the use of reusable and redesignable classes. From which as much objects
as needed can be instanced.

For me is the rest academically, nice when you learn it, however like
driving not important anymore when you drive a car. most things go
automatic.

Cor
 
#2 Inheritance. The use of objects without inheritance is object based
programming.

Regards,
Jeff
 
OK, he posted this message, over 3PM on a Friday.... So, how many people
here are thinking "take-home exam" ?

Now, the first question that must be asked is, "What is the question?
Which is more important to OOP? or which is more important to good program
design?"

To the latter, Encapsulation (and data hiding) is, by far, the most
important design characteristic. Having your data properly factored in
objects is the primary key to a well-design program. If I had to put a
number of it, it would be about 65-75%. Polymorphic behavior come next,
which I'd put at about 10-20%. These leaves somewhere between 5-25% for
everything else, of which I'd put Inheritance rather low, maybe 0-5%.
Inheritance is an important technique in OOP, but it's just one technique to
implement polymorphism (one of many -- for example, generic programming
accomplishes many of the tasks of OOP without inheritance). We've learned
that deeply rooted class library are often more of a hinderance than a help,
and most modern class libraries tend to be very shallow.

--
Truth,
James Curran
[erstwhile VC++ MVP]

Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
Actually, I'd go with Polymorphism, without which, Inheritance is
pointless.
Click to expand...


They certainly go hand in hand, but I would say inheritance is the
key. Without inheritance, polymorphism is questionable at best - if
it even makes any sense. But without polymorphism, inheritance is
still a huge design advantage.

I don't know if you include overriding methods under the heading of
"polymorphism" - I don't. And just with the ability to override
methods in derived classes so that you can write code that speaks in
terms of base classes (say, "animal" or "mammal") but actually
processes based on the derived classes (say, "cat" or "dog") is the
KEY to OO. It's where the power is. You can write a program that
says "feed the animal", and the dog or cat or cow or bird or marmoset
will be fed correctly, even though your bit of code that controls the
daily routines of the animals doesn't distinguish what kind of animals
are being fed. THAT is the power of OO design and programming.
 
goody8 said:
I don't know if you include overriding methods under the heading of
"polymorphism" - I don't.
Click to expand...

I do, because....(see below)
that you can write code that speaks in
terms of base classes (say, "animal" or "mammal") but actually
processes based on the derived classes (say, "cat" or "dog") is the
KEY to OO. It's where the power is.
Click to expand...

And that is the very definition of "polymorphism"

Overriding methods is merely an implementation technique to achieve
polymorphism. And, in general, in OO, Implemenation Is Irrelevant. (my OO
mantra)

In fact, overriding virtual functions gets away from true OO-ness. In
strict OO,
windows w;
file f;
w.open(0,0, 100, 200);
f.open("output.txt");

is an example of polymorphism, even though classes window & file would share
no parent other than Object (since in strict OO, we are sending the same
message -- "open" -- to both objects)

--
--
Truth,
James Curran
[erstwhile VC++ MVP]

Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
I do, because....(see below)


And that is the very definition of "polymorphism"

Overriding methods is merely an implementation technique to achieve
polymorphism. And, in general, in OO, Implemenation Is Irrelevant. (my OO
mantra)

In fact, overriding virtual functions gets away from true OO-ness. In
strict OO,
windows w;
file f;
w.open(0,0, 100, 200);
f.open("output.txt");

is an example of polymorphism, even though classes window & file would share
no parent other than Object (since in strict OO, we are sending the same
message -- "open" -- to both objects)
Click to expand...


But that's not polymorphism because w and f are not related. It's
just to unrelated things that happen to have member functions with the
same names.

I would, however, revise my earlier statement. My brain farted -
sorry. Overriding a method IS polymorphism. I guess I was thinking
more of methods with the same names that have different parameters.
But overriding methods is still polymorphic behavior.

But anyway, the inheritance hierarchy and the polymorphism go
hand-in-hand, and that is where the power of OO comes from. Sure,
it's also valuable to encapsulate within objects, but you can do that
sort of organization even with procedural languages, so I guess I
don't see that as a particularly great *advantage* of OO - it's not
unique to OO.
 
goody8 said:
But that's not polymorphism because w and f are not related. It's
just to unrelated things that happen to have member functions with the
same names.
Click to expand...

No, that *is* Polymorphism. That was exactly the point I was trying to
make. You are confusing an implementation detail with an OO design concept.
The essence of Polymorphism is that two different objects respond
differently to the same message.

I guess I was thinking
more of methods with the same names that have different parameters.
Click to expand...

And that too is polymorphism. Different responses to the same message.
But anyway, the inheritance hierarchy and the polymorphism go
hand-in-hand, and that is where the power of OO comes from. Sure,
it's also valuable to encapsulate within objects, but you can do that
sort of organization even with procedural languages, so I guess I
don't see that as a particularly great *advantage* of OO - it's not
unique to OO.
Click to expand...

Which is why I posed the question I did at the very start of this thread:
"What is the question?
Which is more important to OOP? or which is more important to good program
design?" But who cares if a certain principal is part of strict OO or not.
What's really important is if it is a principal of good design.
 
James... you're a Smalltalk programmer aren't you? :) Your definition
of "polymorphism" is very implementation-dependent: it's very
Smalltalk.

I side with goody8 on this one: it's "polymorphism" only when you can
treat two objects interchangeably for the purposes of some operation,
because they implement that same operation (with possibly different
implementations, but it's the same operation).

In C#, the fact that two methods have the same name is irrelevant. They
must have the same name and the same signature in order to participate
in polymorphic behaviour. In other languages it may be different. C#
has no concept of "message".
 
James... you're a Smalltalk programmer aren't you? :) Your definition
of "polymorphism" is very implementation-dependent: it's very
Smalltalk.
Click to expand...

Well, yes, my first OO language was SmallTalk, although I was taught ST
in the context of learning OO. Which brings us to your
"implementation-dependent" line --- Actually, it just the reverse -- It's
*your* definition that limited by a particular implementation. I do not
speak in any particular implementation but in the concepts of OO as they
were originally defined (by the person to defined OO and at the same time
defined SmallTalk to implement them).
I side with goody8 on this one: it's "polymorphism" only when you can
treat two objects interchangeably for the purposes of some operation,
because they implement that same operation (with possibly different
implementations, but it's the same operation).
Click to expand...

And why would you say that "opening a window" and "opening a file" are
not the "same operation with [a] different implementation" ? So, the
implementation is radically different. Nevertheless, the message "opens"
the object for use.

First of all, this is precisely why C++ & C# are consider "imperfect" OO
languages. Good enough to get work done, but they don't reach the theoretic
standard of Perfect OO.

More to the point, who said we are talking about "OO as implemented by
C#" ?? Reread the OP. It just talks about "Object Oriented Programming".

--
--
Truth,
James Curran
[erstwhile VC++ MVP]

Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
More to the point, who said we are talking about "OO as implemented
by C#" ?? Reread the OP. It just talks about "Object Oriented
Programming".

True... but then who said we are talking about "OO as implemented by
Smalltalk?"

In Smalltalk, the name of a message defines the message. "open" as
handled by a File is the same message as "open" as handled by a Window,
so having two objects handle messages with the same name results in
polymorphism _in Smalltalk_.

In C#, C++, and Java, having two classes implement methods with the
same _short_ name _and even the same signature_ does not necessarily
mean that they are processing what you would call the "same message"
and therefore exhibiting polymorphic behaviour. C#, C++, and Java
require that the _full_ method name (including the name of the
interface or base class in which it is defined, and in C# including the
name of the assembly in which that interface or base class was defined)
_and_ the method signature be identical in order that the two objects
exhibit polymorphic behaviour.

What's at issue here is "what is the name of the method" (or, if you
prefer, "the name of the message"). In Smalltalk, the name of the
message is "open". In C#, the name of the method is
AssemblyName.Namespace.Interface.Open(string, string) or some such
thing, not simply "Open". Therefore, if one class implements
AssemblyName.Namepace.Interface.Open(string, string), and another
implements AssemblyName.Namespace.BaseClass.Open(string, string), the
two methods _do not_ have the same name, and therefore there is no
polymorphism.

This is even clearer in C++, which does name mangling: the run-time
message names (or method names) can be quite different, even if what
appears written in the code is simply "Open". Different run-time
message names means no polymorphism.

Different languages implement O-O in different ways. Just because a
particular syntax in one language results in polymorphic behaviour (or
doesn't) doesn't mean that it will (or won't) in another language. It
so happens that C#, C++, and Java have a (reasonably) common
interpretation of what results in polymorphic behaviour. Smalltalk is
different. Each approach has its upside and downside; I don't see any
reason why either is "inferior" in any general sense.
 
Upon thinking about this further, what's at issue here is not so much
"what is the name of the method (or message)", but syntax versus
semantics.

I see polymorphism (independent of programming language) from a
different angle: "Polymorphism" is happening when you can invoke the
same behaviour in objects of diverse classes. I don't even care about
the name of the method, property, or message at work, so long as it
conceptually implements the "same operation". That is to say, I can
even imagine a language in which the methods / properties / messages
have different names, but are somehow identified as implementing the
"same operation" in some larger sense. Polymorphism, then, isn't about
syntax at all. It isn't about what method name is typed in the code.
Polymorphism is a behaviour, not a notation. It's about being able to
treat disparate objects interchangeably for the purposes of certain
operations.

However a particular language allows you to treat disparate objects
interchangeably for some operations... that is how it implements
polymorphism. Even if "this" language allows a syntax that would
produce polymorphic behaviour in "that" language, but that syntax
doesn't allow you to treat disparate objects as interchangeable in
_this_ language, then in _this_ language the syntax does not indicate
polymorphism. Again, it's about semantics, not syntax. In Smalltalk,
the _syntax_ of naming two messages the same results in polymorphic
semantics. In C#, even overloading method names doesn't introduce the
possibility of polymorphic behaviour; only inheritance and interface
implementations introduce that possibility _in C#_. In some other
language it may be different yet again.

Therefore, in Smalltalk, sending the message "open" to a Window and
sending the message "open" to a File is, in fact, an example of
polymorphism, because that's how Smalltalk implements polymorphism: by
naming two messages the same you are _ipso facto_ indicating that you
want polymorphic behaviour.

In C#, C++, and Java, two methods with the same name (even the same
full name, as outlined in my previous post) are _not necessarily_ the
same operation, and therefore do not necessarily indicate that you want
polymorphic behaviour.
 
Bruce Wood said:
Upon thinking about this further, what's at issue here is not so much
"what is the name of the method (or message)", but syntax versus
semantics.

I see polymorphism (independent of programming language) from a
different angle: "Polymorphism" is happening when you can invoke the
same behaviour in objects of diverse classes.
Click to expand...

I agree, but think that although the classes can be diverse, they
should indicate the relationship between them in some way (i.e. say
that the operation *is* the same one, not just one with the same name).
I don't even care about the name of the method, property, or message
at work, so long as it conceptually implements the "same operation".
That is to say, I can even imagine a language in which the methods /
properties / messages have different names, but are somehow
identified as implementing the "same operation" in some larger sense.
Click to expand...

Sure - and indeed in VB.NET you can implement an interface's method
with a different implementation method name.

I believe this is very different to James's view though - I wouldn't
say that opening a file and opening a window *are* the same operation,
really. I wouldn't expect them to be indicated to be the same operation
in any language where that indication is explicit.

A better example would be "Join" - look at String.Join and Thread.Join.
They are radically different operations with the same name. I certainly
wouldn't view those as polymorphically related, even though Smalltalk
would. No doubt Smalltalkers would argue that they're definitely
related *because* they share the same name, but until natural language
becomes completely unambiguous, I think it's a bad way of implying
relationship.
 
A better example would be "Join" - look at String.Join and
Thread.Join.
They are radically different operations with the same name. I certainly
wouldn't view those as polymorphically related, even though Smalltalk
Click to expand...
would. No doubt Smalltalkers would argue that they're definitely
related *because* they share the same name, but until natural language
becomes completely unambiguous, I think it's a bad way of implying
relationship.
Click to expand...

String.Join and Thread.Join are a great example. (I was trying to come
up with an example like that... thanks, Jon.)

This is starting to look more and more like the "strongly typed
language" versus the "weakly typed language" debate, isn't it? It's
like the discussion between VB6 programmers, who are used to having an
"anything" type that they can just stuff values into, and C++
programmers who are used to the rigour of having to declare everything
and be concerned with casting and type conversions. The VB6 guys I knew
used to laugh at C++ and all of the picky housekeeping details you had
to look after in that language; the C++ used to sniff at the VB6 guys
and all of the bugs that cropped up because you inexplicably ended up
with a bitmap in a variable you thought contained an integer.

It strikes me that Smalltalk implements what I would call "weakly typed
polymorphism": same name = same operation. The upside is that you don't
have to worry about picky housekeeping details: the language sorts it
out at runtime. The downside is that you get polymorphism even when it
isn't appropriate and you don't want it, allowing you to do stupid
things like confuse concatenating two strings (String.Join) with
waiting for a thread to complete (Thread.Join). C++, Java, and C# all
implement what I would call "strongly typed polymorphism", where the
programmer has to explicitly indicate that he wants polymorphism, and
keep careful track of what overrides what. The upside is that you get
polymorphism only where you explicitly indicate it; the downside is
that there is lots of picky housekeeping to do.

The fact that both strongly-typed and weakly-typed languages continue
to flourish tells me that each has something to offer. I would say the
same with the two approaches to polymorphism.

I should add that given the mandate of the .NET Framework and C#,
weakly-typed polymorphism seems to me to be a total non-starter in this
environment. The C# / .NET designers took great pains to ensure that
you couldn't possibly introduce rogue code that would override and
redefine things in order to create security holes, or in order to take
over threads for nefarious purposes. I'm not sure how you would mix
that kind of locked-down rigour with a language that sorts out its
polymorphism issues at run-time. They seem like oil and water to me,
although that may just be lack of imagination on my part. :)
 
Back
Top