inheritance vs composition

On Thu, Aug 11, 2011 at 8:41 AM, wwagner4 <wwagner4@gmail.com> wrote:

Because multiple inheritance is much less restrictive than single
inheritance I feel like I do not use composition any longer. It seems
to be possible to write code using the following rules.

1. Code all logic in traits
2. Mixin the traits you need in your classes

What are the arguments against programming by these rules?

Because you always need access to concrete types and constructors.

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

wwagner4 skrev 2011-08-11 08:41:
> Because multiple inheritance is much less restrictive than single
> inheritance I feel like I do not use composition any longer. It seems
> to be possible to write code using the following rules.
>
> 1. Code all logic in traits
> 2. Mixin the traits you need in your classes
>
> What are the arguments against programming by these rules?

Some arguments that pops into my head:

- No clean separation between class interface and implementation. When a
class inherit from an implementation trait you might inherit
implementation details that you don't want to expose in the class
interface. With composition you have full control what to expose in the
class interface.

- Dynamic composition is much harder. Consider this example:

trait Gui
class OpenGlGui extends Gui
class DirectXGui extends Gui

// Class using composition
class Display(val gui : Gui)

def createGui(config : String) : Gui = ...

def createDisplay(config : String) = new Display(createGui(config))

If you would instead use inheritance (i.e. "Display with OpenGlGui" and
"Display with DirectXGui") you can't separate the createGui and
createDisplay methods, i.e. it's less modularizable.

/Jesper Nordenberg

Composition also allows you to choose which members and how those
members are exposed from the inner classes. With inheritance you must
take all members at their declared visibility. I find such control very
useful when I'm composing objects to create a class that is different
than the sum of all the composed classes, or I want to use the composed
classes in very specific/controlled ways.

ARKBAN

On 8/11/2011 4:03 AM, Jesper Nordenberg wrote:
> wwagner4 skrev 2011-08-11 08:41:
>> Because multiple inheritance is much less restrictive than single
>> inheritance I feel like I do not use composition any longer. It seems
>> to be possible to write code using the following rules.
>>
>> 1. Code all logic in traits
>> 2. Mixin the traits you need in your classes
>>
>> What are the arguments against programming by these rules?
>
> Some arguments that pops into my head:
>
> - No clean separation between class interface and implementation. When
> a class inherit from an implementation trait you might inherit
> implementation details that you don't want to expose in the class
> interface. With composition you have full control what to expose in
> the class interface.
>
> - Dynamic composition is much harder. Consider this example:
>
> trait Gui
> class OpenGlGui extends Gui
> class DirectXGui extends Gui
>
> // Class using composition
> class Display(val gui : Gui)
>
> def createGui(config : String) : Gui = ...
>
> def createDisplay(config : String) = new Display(createGui(config))
>
> If you would instead use inheritance (i.e. "Display with OpenGlGui"
> and "Display with DirectXGui") you can't separate the createGui and
> createDisplay methods, i.e. it's less modularizable.
>
> /Jesper Nordenberg
>

On 11/08/2011 08:41, wwagner4 wrote:
> Because multiple inheritance is much less restrictive than single
> inheritance I feel like I do not use composition any longer. It seems
> to be possible to write code using the following rules.
>
> 1. Code all logic in traits
> 2. Mixin the traits you need in your classes
>
> What are the arguments against programming by these rules?

Isn't what dependency injection is about? Ie. avoiding hard-coded
dependencies on an implementation of some interface, to allow easy
switching of components?
Somebody having really used this paradigm can confirm or correct me...

I think there is some overlap, but there is a such a thing as too much dependency injection ;-)

On 11 August 2011 15:51, Philippe Lhoste <PhiLho@gmx.net> wrote:

On 11/08/2011 08:41, wwagner4 wrote:

Because multiple inheritance is much less restrictive than single
inheritance I feel like I do not use composition any longer. It seems
to be possible to write code using the following rules.

1. Code all logic in traits
2. Mixin the traits you need in your classes

What are the arguments against programming by these rules?

Isn't what dependency injection is about? Ie. avoiding hard-coded dependencies on an implementation of some interface, to allow easy switching of components?
Somebody having really used this paradigm can confirm or correct me...

Just because Scala has cool features, doesn't mean that the principles of good programming are turned on their head. Strongly agree with Jesper and ARKBAN's objections.
Regards,Ken