Symptoms and alternatives to overused OOP

Lately I am losing my trust in OOP. I have already seen many complaints about common OOP misuses or just simple overuse. I do not mean the common confusion between is-a and has-a relationship. I mean stuff like the problems of ORM when dealing with relatio开发者_开发问答nal databases, the excessive use of inheritance from C# and also several years of looking at code with the same false encapsulation belief that Scott Meyers mentions in the item 23 of Effective C++

I am interested in learning more about this and non OOP software patterns that can solve certain problems better than their OOP counterparts. I am convinced that out there there are many people giving good advice on how to use this as an advantage with non pure OOP languages such as C++.

Does anyone knows any good reference (author, book, article) to get started?

Please, notice that I am looking for two related but different things:

• Common misuses of OOP concepts (like item 23)
• Patterns where OOP is not the best solution (with alternatives)

Well I can recommend you a book Agile Principles, Patterns, and Practices in C#. Examples are in C# of course, but the idea of the book is universal. Not only it covers Agile but also focuses on bad practices and shows in examples how to convert bad code to a good code. It also contains descriptions of many design pattern and shows how to implement them in semi-real example of Payroll application.

This has to be done but if you truly want to get away from OOP or at least take a look at concepts which are not OOP but are used with great effectiveness: Learn you a Haskell. Try a new programming paradigm and then start seeing where you can apply much of the concepts back to OOP languages. This addresses your second bullet, not in a direct way but trust me, it'll help more than you can think.

It's a bit odd that you mention C#. It has very powerful keywords to keep the usual inheritance misery in check. The first one ought to be the internal keyword. The notion of restricting the visibility to a module. That concept is completely absent in C++, the build model just doesn't support it. Otherwise a great concept, "I only trust the members of my team to get it right". Of course you do.

Then there's the slammer one, the sealed keyword. Extraordinary powerful, "the buck stops here, don't mess with me". Used with surgical precision in the .NET framework, I've never yet found a case where sealed was used inappropriately. Also missing in C++, but with obscure ways to get that working.

But yes, the WPF object model sucks fairly heavy. Inheriting 6 levels deep and using backdoors like a dependency property is offensive. Inheritance is hard, let's go shopping.

I would say to look at game engines. For the most part, OOP has a tendency to cause slight performance decreases, and the gaming industry is seemingly obsessed with eliminating minor slowdowns (and sometimes ignoring large ones). As such, their code, though usually written in a language that supports OOP, will end up using only those elements of OOP that are necessary for clean code / ease of maintenance that also balances performance.

EDIT:

Having said that, I don't know if I would really go look at Unreal. They do some strange things for the sake of making their content pipeline easier for developers... it makes their code... well, look if you really want to know.

One common overuse is forcing OOP in programs/scripts that take some input, turn it to output, then exit (and not receiving input from anywhere else during the process). Procedural way is much cleaner in these cases.

Typical example of this is forcing OOP in PHP scripts.