[Torn]

This horse still needs to be beaten.

Messy inheritance still plagues product Java, C#, and, with the increasing proliferation of MVC frameworks, JS these days.

Hierarchies usually start out small. But, when new features are added and scope creeps, they get deeper and more abstract and messier.

Substitutability (i.e. the L in SOLID principles) does require more boiler-plate when using composition though. Interfaces and mixins (if available in your language) go some way to helping.

[dtech]

Do you have examples? Most modern Java libraries I know (e.g. Guava) implement interfaces and heavily use composition.

The "inheritance based" things mostly got deprecated/replaced when Java 1.5 introduced generics and most libraries needed to be heavily changed anyways.

[Zigurd]

The Android View subclasses are an interesting example of a deep inheritance hierarchy in a relatively modern design.

[twic]

The Android API is fascinatingly anachronistic. I have been programming Java since 1.0.2, but only recently started working with Android. It's been like stepping through a portal back to a time when we had no idea how to structure software.

[Torn]

I've seen a lot of it in product codebases (both Enterprise and Startup) I've had to work with.

I guess it's different when you're maintaining a library - you have more freedom to version up and rewrite things.

[mercurial]

Sadly, many of the "older" programmers haven't learned any better. And sometimes it's a limitation of the language (eg, Java which doesn't allow default implementations in interfaces).

[chton]

I haven't really noticed that this particular horse needs much beating (I work mainly in the C# world). It's drilled so well into beginner programmers that they tend to forget other principles like Single Responsibility.

[stinos]

Single Responsibility

This. There aren't enough dead single reponsability horses :P. This should be drilled in new and experienced programmers over, and over, and over again. And then some more. Because while it sounds so simple it's actually all to easy too violate and because it applies to each and every layer of a project. I'd even say most design patterns are actually proper implementations of SRP in one way or another. Most of the time I have a feeling something if off with my code, it boils down to some pieces just doing too much, hereby dragging others down with it.

Anecdote applied to this particular topic: the intern, proud of having used composition as much as possible, creating mostly classes composed of 10+ other classes and functions that might as well be called NowDoItAll().

[EdwardDiego]

> Hierarchies usually start out small. But, when new features are added and scope creeps, they get deeper and more abstract and messier.

We have real issues with some complex class hierarchies that another team likes - they keep adding yet another abstract subclass of an abstract subclass to handle more cases, so you can end up following logic up and down multiple levels of classes when reading code, and missing one overridden statement can dramatically change the outcome.

[tonyedgecombe]

I wish we could move beyond this idea that just because someone uses a particular language their code is going to be poorly written.

[mamcx]

But is true that some languages make some kind of bad/problematic code MORE common, and requiere discipline and/or knowledge to combat it (and like in this case, is likely that the avg developer is not aware of the alternatives at all.)

[mercurial]

But a language is not just syntax and a compiler, it is an ecosystem. And for good or bad, programmers rely on and are influenced by this ecosystem.

[kyllo]

Not to mention Ruby on Rails, that codebase is a huge mess of inheritance.