Re: "Let's take example like yours with Customers but with Employees. There are different kinds of them. How do You calculate pay for them?" No, in practice there are NOT different "kinds" of employees. You are thinking in terms of hierarchical taxonomies. Hierarchical taxonomies are poor at modeling most business domains and domain objects. Modeling employees with *sets* of features or attributes is more realistic and more flexible. But OOP get's ugly when it tries to handle sets. It's not designed around sets, but rather physical objects and hierarchical taxonomies or nesting of physical objects. If you are modeling physical objects, that's fine, but in the biz domain one is modeling intellectual and conceptual things and relationships such as laws, management decrees, and customer and vendor inter-relationships; not so much physical things. OOP can't give decent examples of how great it is without resorting to physical analogies. This is a sign of the weakness, the "physical problem".

If there is a "good" way to do OOP and most are doing it the bad way in practice, then perhaps OOP needs to be redefined. The practices and techniques that make the "good way" need to be isolated and renamed something else. It's not OOP that's good, but apparently a sub-set of it, but nobody can define and document "it"; only say, "I'll recognize it when I see it". That's not good enough in the age of openness and science. That's Alchemy-Oriented-Programming. I personally find set-theory, or some variation of it more promising. Associations don't have to be hard-wired that way, meaning you don't have to get the design perfect up-front in order to use it effectively. OOP's associations are too hard-wired, and not searchable and query-able in a meta kind of way, except with spaghetti class browsers. Perhaps the "fight" over OOP is graphs (pointers) versus sets. The Functional Programming people are giving OOP a run for it's money. In my opinion they are just as zealotic as the OOP crowd, but it's nice to see visible competition to OOP out there, even if it is run by other zealots. Fight zealots with zealots? IT is so not science.

First, people keep using physical nouns analogies, such as your jet and jet parts. Yes, OOP may do well for physical modeling. OOP was actually born to assist with physical simulation. However, in my actual work, I don't do physical modeling for the most part, and a nested-component view doesn't work well when modeling the business domain. Things interweave more. A given association is only a temporary association of convenience for a given task or section, not a physical one. Please stop using physical examples; they are worn and can't help any further. My domain doesn't match them. Second, I use relational design to assist my procedural designs, and thus it's not entirely just "procedural" doing all the work and modeling. They work together. (Some say that OOP is for those who don't "get" set theory and SQL.) Third, most programmers tend to move out of direct coding in roughly ten years on average. There's a lot of burn-out, wrist injury, and age discrimination for pure coders. Offshore outsourcing has made it even more competitive. So if it takes 7 years of experience to finally get OOP right (you said it has a long learning curve), then only 3 years are left of "good" code. Thus, 70% of all OOP code will have to suck by that logic. That's not a very economical stance. If OOP takes that long to get right, there's something wrong with it.