Composition vs Inheritance?

You are given the lead of a project, where can only use one:
WHAT DO YOU PICK?
strawpoll.me/13699058

Lets solve this now!!

Other urls found in this thread:

youtu.be/0WO3H_MOjrI?t=326
twitter.com/NSFWRedditVideo

What language is this? It looks terrible.

This is a Role from Perl 6.

You can give more 'roles' to an object in runtime if you need to. (last line in the screenshot)

Sounds neat but unnecessary

I noticed that. Which is why I added a sentence after my question.

Thanks for letting me know I need to steer clear of perl.

Well, the question is not about perl anyway... Everyone is very familiar with inheritance, so i put an image of composition. This was clear enough as an example IMO.

Composition is almost always better than inheritance.
Inheritance was a mistake.

I think Hierarchy is good for representing "artificial" hierarchies, like an insect taxonomy or hierarchy-based mental frameworks, which sometimes are needed for mental sanity :) . For for the "real world", composition works great. Specially when you can encapsulate things like external validations or connections, logging, etc... in roles. For example, in a trading financial instrument, the SWIFT connectivity is a great candidate for a Role/Trait applicable to runtime objects. With proper Role/Trait handling, you can question one object if it supports some Role/Trait.

Current status of poll

Use the one that sounds logical.
Anyway, from a technical POV, there are plenty of things you can do with composition you can't do with inheritance.

The only thing you really need is to be able to make collections of Objects (to be able to have "typeless" lists. If you can't use polymorphism, I guess you need this at least.

Current poll status

We know composition is the way to go.

Even James Gosling agrees, and he created Java.

Ok, so before this dies: These are the results:


Thanks for your opinion, anons

i heard the same for Object Oriented Databases, with he argument "That's why we have ORM".

Thing is, ORM is awful.

Why is that? I only used EF but it was great, saved a lot of time for me.

You should not have to make concesions in the design, because of any persistance layer limitation. If you have a model, you should not do two, one in code, and one in database, just because the persistance layer requires this from you.

This guy makes a good explanation for what i mean
youtu.be/0WO3H_MOjrI?t=326

>not using both

Right tool for the right job idiots. Sometimes even both at once. No dogma here.

components

I don't see what makes a role different to a class. Is this an interface or something?

Explicit code + data, that you can "compose" to an existing object in runtime.

In this way, you can have a "bag" of behaviors that you can use to apply to other objects, instead of putting these behaviors in the class hierarcy.

In the last line of the code, you gave a basic Dog ($d3). Next you say "Now this Dog will act as a Guard" and you use "$d3 does Guard" to indicate that. Now, $d3 has the features to be a GuardDog. Basically, you convert a Dog object into a GuardDog object.

If for some reason you want to have a Flying dog, just create a Flies role and compose it to an existing Dog. You can, of course, create a Flying Dog or Flying Guard dog in the classic way too.

It fucking depends. Finish your CS studies before trying to start stupid arguments.

If you want polymorphism then inheritance can be useful. You can get away with variants/tagged unions though, but it has other limitations.