well said stuart! I couldn't agree more! for someone with madison's level of oop experience though, what I've said remains a good general rule of thumb. at least it's far better than the multiple inheritance hell that alot of folks run into otherwise...<br clear="all">
--<br>Shaun Fryer<br><br>On Thu, Dec 10, 2009 at 4:58 PM, Stuart Watt <span dir="ltr"><<a href="mailto:stuart@morungos.com">stuart@morungos.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Inheritance is not completely intrinsic to OO - there are OO languages without inheritance (e.g., Self) and with limited concepts of inheritance (e.g., JavaScript). OO is really about being to build effective pieces of abstract behaviour. That is, you can hide internal implementation details, and still provide a service to others.<br>
<br>
I'd say it all depends on what your purpose is. If you are writing code to be used by others, rather than writing code to be extended by others, you typically end up with different structures. If you want your code to be extended by others, inheritance is kind of invaluable. Most frameworks for extension provide many classes you can extend. Catalyst is a great example. DBI is a good contrast: you rarely benefit from extending database access provision, so a well-defined interface is a better choice.<br>
<br>
Moose makes much of this a lot better, as it adds a few very helpful concepts, such as roles. Having used at least five different OO systems over the years, Moose is probably the one I've had most control over my application architecture with.<br>
<br>
Just a few thoughts,<br>
<br>
All the best<br><font color="#888888">
Stuart<br>
<br>
</font></blockquote></div><br>