Cart
[Home] [By Thread] [By Date] [Recent Entries]
> Ahah! Ok, in a non-OO language you'd normally have references to the UUCP > emailing function library in the Customer code, yes? Replacing those with > SMTP stuff would be tricky. Shoving stuff into classes is encouraged in OO > languages as a modularisation step, but the fact that the calls to the > UUCP library go through the vtable of emailMixin means that it's possible > to swap in another "library" without changing the source. Associating code > with data means that bits of code can be assigned to variables and, hence, > indirected. > > In a non-OO language you could do the same thing by explicitly > creating a struct full of function pointers, but then you're just > emulating OO without language support! I think this nails our point of difference. It seem to me that you're taking basically any sound development practice and calling it "OO". I find that odd, since most of it predates what we know as OO chronologically, but at least it seems you're not claiming that OO polymorphism, inheritance and encapsulation are the be-all and end all of modeling and design. This is a good thing. Note that you can do what I did above in languages that don't even claim to be OO. In LISP (not even CLOS), you do it with lambdas. In C you do it with function pointers. Both predate OO, so I don't see how you can say they are "emulating" OO. -- Uche Ogbuji Principal Consultant uche.ogbuji@f... +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python
|
