We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
Page Index Toggle Pages: 1
OOP (Read 2660 times)
Jun 17th, 2010, 7:32am

The other day i was discussing OOP with a freind who is much more advanced than i am in coding. I became totally confused when he did not understand what i meant my composite objects, and suggested i was mistaken - and that in fact i probably meant polymorphism.

Can anyone clarify this please. I thought perhaps the terminology was a processing thing: that a composite is easier to understand that polymorphism, but i googling i find both - and niether refer to the other??

the following explains composite objects in computer programming generally as i understand it from processing guides:

but the later explains OOP with no reference to composition but it does to polymorphism.

it seems inheritance is 'standard', so thats clear but whats the difference between polymorphism and composite objects?

can anyone clarify this please? thanks.
Reply #1 - Jun 17th, 2010, 9:01am
I'm no OOP guru and don't have a computer science background, so could be wide of the mark, but here's my take:

'Composition' allows you to combine objects of different types ('parts' if you like) to create a greater 'whole'.  So you might have classes for a wheel, engine, base etc. and these could be combined to create a vehicle: e.g. a car, a motorbike, scooter etc...

On the other hand Polymorphism would allow you, for example, to create several types of engine object and, since these would all implement a base Interface with the same core properties and methods, any of these could be swapped into your vehicle and work with no modification required.

In fact it looks to me as though 'Composition' might correspond to 'modularity' on the OOP page you linked to...
Reply #2 - Jun 18th, 2010, 3:20am
Thanks blindfish,

looking a little further i found on this page a reference to the "composite code reuse principle":

it seems that composite objects are a 'kind of' polymorphism...
"The Composite Reuse Principle in object-oriented programming is a
technique by which classes may achieve polymorphic behavior and code reuse by containing other classes which implement the desired functionality instead of through Inheritance.....this technique is often referred to as 'Composition' over 'Inheritance'."
see: http://en.wikipedia.org/wiki/Composite_reuse_principle
and: http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation

i need an idiots guide but i think i understand it correctly that;
Encapsulation conceals the functional details of a class from objects that send messages to it.
For example, the Dog class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and volume).
(which is the same as composition)
and polymorphism allows the programmer to treat derived class members just like their parent class's members. More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to different data types to respond to calls of methods of the same name, each one according to an appropriate type-specific behavior. One method, or an operator such as +, -, or *, can be abstractly applied in many different situations. If a Dog is commanded to speak(), this may elicit a bark(). However, if a Pig is commanded to speak(), this may elicit an oink(). Each subclass overrides the speak() method inherited from the parent class Animal.
from: http://en.wikipedia.org/wiki/Object_oriented_programming#Encapsulation

Reply #3 - Jun 18th, 2010, 5:57am
Well I guess this basically all boils down to how you construct your code, and the techniques you use will depend on the context.

TBH we already use the 'composition' technique the moment we start adding properties to a class.  More often than not these properties are built-in objects, but it doesn't take much to also start using custom objects; and that's where polymorphism can be really useful as it ensures that your custom object conforms to a required standard.

Obviously if working alone it's possible to manually ensure that your new objects conform, but it doesn't take much effort to write a base Interface (or abstract class), which means that if you come back to the project 6 months later you don't have to spend ages figuring out how to make your object fit the container: you just implement the Interface and you know it will work.  This is also especially useful when working on collaborative projects.  Colleagues just implement an interface, write any required methods and it should just work...
Page Index Toggle Pages: 1