Application without Model

[LorraMento]

The deeper the inheritance hierarchy is, the greater the probability is that it gets complicated and hard to predict its behaviour. Additionally, this underlying principle can be abstracted to provide a conceptual model for application-to-application and application-to-enterprise connectedness. Now consider this: the MSF philosophy holds that there is no single structure or process that optimally applies to the requirements and environments for all sorts of projects. Consequently, A composite service is atomic in nature, but orchestrates the invocation of component services into a business level process.

I have heard that each classes comprise non material products of our minds in order to allow us for reasoning about their circumstances of creation, their identity and historical implications.

It kinda makes sense, but not completely convincing. If anyone has come across this issue, please let me know if you have found a better explanation.

 

[DonQuichote]

Sorry. I see a lot of words, but I do not understand anything of it.

Large inheritance chains are a code smell for themselves. I never needed one, nor can I imagine that a class can have responsibilities at so many levels. Inheriting is something like wearing a "hat" that comes with a uniform. Uniforms come with levels also. Somebody may be a "policeman" (course responsibility, high in the inheritance chaine), a "detective" (finer grained) and an "assistant murder investigator" (low in the inheritance chain, finest responsibility). Each level has its own responsibilities, and therefore a large inheritance chain usually means too many responsibilities for one class.

Now I don't know what MSF exactly stands for, but both objects and environments can be adjusted. You may have to inherit something general for your specific situation, or you can "wrap" your situation into something your standard object understands.

So what exactly is your question?

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)