From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/15 Message-ID: <5vkfb2$f2p$2@trumpet.uni-mannheim.de>#1/1 X-Deja-AN: 272791809 Organization: --- Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-15T00:00:00+00:00 List-Id: Nick wrote via Owen Fellows about supposedly "pure" OO a la Eiffel vs. Ada-like modules and types as different concepts and non-method procedures: > But it it more likely that you just inherit MATHEMATICIAN somewhere in > your heirarchy to save on typing. I find that totally unacceptable, as it creates much too strong coupling between library modules and their clients. Adding new features to a library module shouldn't force even the smallest change in any previously existing clients. The same applies to unavoidable visibility of every parent feature in children - to avoid potential clashes, one is forced to revert to using long_feature_names_saying_they_are_only_for_class_X_and_not_for_children, which is a shame for a somewhat recent language like Eiffel (even in old K&R C you had private - aka static - functions/variables), in my view. The point isn't so much about children touching conceptually private features of parents where they shouldn't do that (though that does get "interesting" in large projects with say, 50 to 100 programmers of varying quality, and I'd rather have that checked, too), but about clean separation of concerns and minimal coupling. > Having the same implementation as inherits is a hint that it probably is > inherits! No more than the implementation of loops via conditional goto is a hint to drop explicit loops from the language and only provide conditional goto (and perhaps call/return) as control structure. I expect most people wouldn't follow the latter reasoning (nor do I), and likewise I disagree with your above suggestion. In fact, I'd already use inheritance much less than what seems to be usual in the Eiffel world (if Bertrand Meyer's books are a hint about general usage): Even if it means more writing, I prefer having a mere client for an object via a field over implementation inheritance: As long as the representation type can be used unchanged via its abstract interface, I'll do so. If it's mostly right, but still no proper "is-a" relation holds, I'll also seriously consider a different subclass with some small changes for the different need, and then using this adaption as client in that new type which really isn't a proper subtype. I find this to be much better at decoupling, more explicit about the essential relations between those types, and more readable for my taste. The counter-argument about inefficiency due to another indirection doesn't hold, as the above is only about source level stuff: If performance is critical, make the compiler sufficiently clever to inline the respective data and operations for such cases, which should be quite trivial. The counter-argument about needing all the facilities which are used for inheritance again for import doesn't really work either, since the usage of library modules with qualified names for feature access doesn't need things like renaming, redefinition, re-export or hiding; simply write e.g. Math.Sin(X) and stop worrying about name space pollution. (Well, you do have to think about module names, which should ideally be a hierarchical name space, similar to Ada child packages or Java packages, but it reduces the amount of relevant names dramatically.) -- Marc Wachowitz