[jon_hendry]

I think a lot of the benefits of OO reuse have been lost due to platform shifts. If you build a system on NeXTSTEP in the early 90s, then throw it out and switch to Java, then throw it out and switch to C#, you're naturally going to lose a lot of the efficiencies you theoretically could have taken advantage of had you somehow managed to stay on NeXTSTEP or OpenStep all along.

And then, of course, you have mergers and acquisitions leading to code being thrown away or warehoused or merged with other systems, or new management deciding to start from scratch.

Basically, the industry doesn't really have a long enough attention span to really make the most of OO code reuse.

[barrkel]

People have long talked about how OO failed to generate code reuse, but I don't understand how they do it with a straight face. You reuse masses of OO code every time you write a non-trivial program using a modern standard library.

I think the people making this criticism are looking in the wrong place for the reuse, and / or had weird ideas of what could be reused, and how it could be reused, to begin with.

The reuse that OO gives us comes from raising the level of abstraction with which the program is written, in particular because runtime libraries are so much larger ("batteries included", etc.). The hierarchical namespaces and encapsulated structure of modern class libraries reduces their cognitive overhead. For example, in .NET, you can work with WebRequest, TcpClient or Socket, depending on what level of control you need; and the conventions for working with these things are pretty uniform across the board. Larger applications are self-similarly written at a higher level, reusing code within themselves in a framework-like way.

But the people who thought there was going to be some kind of central library of domain-specific classes in your company, that you would reuse in multiple disparate applications, I think that was always fairly naive; reuse implies coupling, and coupling of things that are individually subject to change in ways that affects their users is fraught with problems, and always has been.

The best candidates for reuse aren't usually representations of the domain concepts that are central to a business, because each application in the business will probably be wanting to do something quite unique with those domain classes. Rather, it's concepts that are self-contained, universal, not likely to change much over time nor need different intrinsic behaviour from application to application, which are best suited to reuse.

[ori_b]

"You reuse masses of OO code every time you write a non-trivial program using a modern standard library."

How much of that is due to OO, though? I reuse masses of code without OO all the time.

[jon_hendry]

"But the people who thought there was going to be some kind of central library of domain-specific classes in your company, that you would reuse in multiple disparate applications, I think that was always fairly naive"

Well, perhaps, but I've seen it done successfully in NeXTSTEP/OpenStep shops back in the day, such as an investment bank. Not one big library, but a few frameworks so there's some separation.

The team I was on had our own frameworks, shared among the apps we developed. We also used/built our frameworks on frameworks from the bank's Architecture group, which were also used by other development groups.

[Stormbringer]

The biggest problem with OO is the abuses. I recently worked with a large codebase where /none/ of the behaviour for objects was in the objects themselves. Some Architect had come along and beaten it out of them with an extreme application of the 'too many patterns' anti-pattern.

One way they justify this is to 'reduce coupling', and so your comment about coupling tripped a red flag for me. Whenever I want to take the piss out of an Architect I just tell them that we should 'add an extra layer of indirection' to the design. 99% of the time they agree without realising that I'm satirising them.

[dkersten]

"where /none/ of the behaviour for objects was in the objects themselves"

Actually, this could be a good thing, depending on what the goals were. For example, non-member non-friend classes are often more OO than putting everything into the class[1]. Furthermore, if you want to use function overloading for multiple dispatch, the keeping the functions separate from the objects is also useful. If your system is highly concurrent, keeping the code and data separate can be quite helpful. Also keeping data in structure-of-arrays form and using external functions to operate on these arrays can make huge differences in terms of cache usage, potential parallelism and vectorization of instructions.

Coupling might be a reason to do this, but its certainly not the first reason I think of. There are plenty of better reasons (and as always, not all reasons apply to all codebases).

TL;DR: There are lots of reasons why doing this could be a good thing.

(fwiw, I like to do this with my core data structures because I believe code and data should be kept separate (and that data is the more important of the two). I do like to provide normal objects as an API though, because I often feel that its a natural interface, but the internals of my code are rarely very OO in the C++/Java sense).

[1] http://www.gotw.ca/gotw/084.htm