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.
IndexProgramming Questions & HelpSyntax Questions › Lists' objects interaction mess
Pages: 1 2 
Lists' objects interaction mess (Read 967 times)
Re: Lists' objects interaction mess
Reply #15 - Jan 17th, 2009, 11:13am
 
The classes marked as "abstract" are the parent/ancestors. You cannot make an object out of them, they serve only as "blueprint"/model.

The children use "extends" keyword to show they use the base classe, inherit from it. They can use everything defined in the base class (unless it is private) and override the methods (ie. redefine them, with capability to still call the original one).

It is powerful because it allows to define a base mechanism (all shapes have common state and behavior) and yet to specialize them (you can override isOver() for Circle to take in account radius instead of bounding box).

Note also the abstract method showShape() in Shape class: it makes no sense to define this method for something abstract, but it forces children to define this method, otherwise the code won't compile. It is also a kind of contract: you know a Shape will have such method.
Although for such contract, we usually use an interface, but that's another story.
Re: Lists' objects interaction mess
Reply #16 - Jan 20th, 2009, 8:00am
 
  PhiLho, thanks a lot! Now I see!
Pages: 1 2