Team-based object languages
I recently attended a mini-conference on the topic of "object languages after 20 years". Have objects failed ? Is a new "post-object" era being ushered in, and can we guess what new ground will be broken in that era ?The answers seem to cluster around two major and opposing axes. There are those who predict the end of Objects as an inclusive paradigm and herald the coming of age of Models. They are the tenants of MDA, model-driven architecture; of "platform-independent models", among which business process models, service models etc.
Actually I'm not quite sure that these people are at all talking about the same thing as the people who discuss object languages, but the impression is definitely that languages in general (object or otherwise) are not something of interest, and models are where all the action will be. Maybe. To my way of thinking, "model" is to "class" as "class" is to "object" : a drive to generalization, the grander and more sweeping the better.
The ideal of MDA, as stated, is to be able to describe the essence of a business in a set of models, and then automate more or less fully the generation of code (actual applications, plus the platform-specific plumbing) that allows people to perform the work. The unstated implication, if you throw in the notion of "reusable models", is that there is a sort of Platonic abstraction which every business under the sun is a somehow distorted reflection of; modeling captures the Platonic essences, and programming is mere correction, a way of adjusting for the inevitable imperfections and divergences that arise when the essence is realized in the physical world.
Several authors, Jim Coplien most recently, have warned against the error of identifying object languages with the notions of classes and inheritance. This is the second trend I see - a direction away from the classifying and Platonic school. Actually, according to Richard Gabriel this was the original object philosophy but was derailed along the way:
[...] with C++ and Java, the dynamic thinking fostered by object-oriented languages was nearly fatally assaulted by the theology of static thinking inherited from our mathematical heritage and the assumptions built into our views of computing by Charles Babbage whose factory-building worldview was dominated by omniscience and omnipotence.
Coplien goes on to argue that "type" is a less useful notion in an object design than "role". The way I think of object designs based on roles and responsibilities is by analogy with organizational concerns. If you are building a project team, you can proceed in two different ways to select the next person you hire. You can be interested in whether that person "is a" Programmer, or Architect, or Tester, or Manager - and at a finer level, a Senior Programmer or Junior Programmer, an Integration Tester or an Acceptance Tester. In other words, you can take an interest in types and classifications. Or you can be concerned with making sure that your team, as a whole, includes the appropriate mix of programming skills, testing skills, management skills, etc. The next person you hire doesn't have to "be a" Programmer, but might be a good recruit because they can in part fulfill that role thanks to their programming skills, and also complement existing testing skills.
We see this kind of approach in a recent programming language, Scarlet, which does away completely with class inheritance and class hierarchies; rather, the main approach to reusing implementation is aggregation. In Scarlet you find interfaces, which are akin to roles, and implementations - which we can think of as persons with the skills required in these roles. You compose objects which are associations of implementations brought together to perform tasks - in other words, objects which look a lot like teams.
No comments:
No trackbacks:
Trackback link:
Please enable javascript to generate a trackback url