When I worked at Boeing,  in Wichita, KS, we had an application that ran the payroll system.  The problem was that the application was "one" program. It did everything cause it was the "payroll" process. Turns out the "one" program was over 250,000 lines of code and only the creator was able to understand and make changes to the program. The "one" program was immediately re-written once the creator retired. 

I have also seen a lot of Java developers load up a class with many different disparate functions and "scream" in your face stating that they were writing OO code because the language was Java.

I have been writing Smalltalk (mostly) and other OO programs for close to twenty years and I have rarely run into an instance where I wished that I could use MI.  I was always able to implement delegation and solve the problem.

It seems to me that the example you provided should be implemented in several classes that is wrapped in an manager class.  Not sure MI is the best solution in this instance.

Brad Selfridge

On 6/7/2012 1:07 PM, James Robertson wrote:

Imho, delegation is far easier to maintain.  For one thing, you don't need to "cover" all the inherited code you don't need

On Thursday, June 7, 2012, andre wrote:

Thanks for the pointers, Georg. Interesting read.

I see the points, but am inclined to disagree with such a general verdict against MI. There are legitimate uses for it, although it can certainly be abused to create a mess.

Code readability is, and Smalltalkers know that best, a question of the right tools. Plain source "files" are almost always hard to read, no matter which language.

One interesting thing I recently observed concerning the way my thoughts tend to go is, that the typical thought pattern when creating a new class in Smalltak is "of what existing class *is* this object a derivate or specialization?" It is an ontological model. In contrast, the typical thought in C++ is "what is this object supposed to be able to *do*?", which is a behavioral model.

Either model has its advantages and disadvantages. If for example, I have an object that is supposed to be able to

- Run a background thread
- Receive and process jobs from a queue
- Broadcast events to dependent objects
- Provide a server on a network that clients can connect to
- Receive and react to OS events
- Implement application specific behavior that builds on all the above

then using MI, all but the last point could be simply assembled from existing classes. In Smalltalk, I would need to add a lot of protocols and copy/paste/rewrite code from elsewhere.

Delegation is verbose and laborious and hard to maintain. Also if the individual delegates of an object need to share a great deal of common state, things are getting even more laborious.

Andre



_______________________________________________
vwnc mailing list
vwnc <at> cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________ vwnc mailing list vwnc <at> cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
vwnc <at> cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc