C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Design by Contract for abstract base class? Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ language (comp.lang.c++) View previous topic :: View next topic   Author Message kk_oop Guest Posted: Sun Oct 26, 2003 7:04 pm    Post subject: Design by Contract for abstract base class? Hi. I'm looking to find a way to apply Design by Contract in my C++ programs. The problem that I'm having deals with pure abstract base classes. Since these are often how an object gets exposed to clients via polymorphism, it seems critical that an abstract base class can define and enforce its contracts. Defining contracts is critical, so LSP can be utilized when defining derived implementation classes. However, if the pure abstract base class defines a method to enforce its contract, it will no longer be pure abstract. This poses a problem, for instance, if the abstract class is being used to apply multiple interface inheritance. In that case, the abstract class really needs to be pure abstract. Is there a way for C++ to somehow enable an pure abstract base class to enforce its contracts? Seems like an unfixable paradox. Any thoughts? Thanks, Ken Back to top David White Guest Posted: Mon Oct 27, 2003 3:44 am    Post subject: Re: Design by Contract for abstract base class? kk_oop<no_spam> @yahoo.com> <"kk_oop Quote: Hi. I'm looking to find a way to apply Design by Contract in my C++ programs. The problem that I'm having deals with pure abstract base classes. Since these are often how an object gets exposed to clients via polymorphism, it seems critical that an abstract base class can define and enforce its contracts. Defining contracts is critical, so LSP can be utilized when defining derived implementation classes. However, if the pure abstract base class defines a method to enforce its contract, it will no longer be pure abstract. This poses a problem, for instance, if the abstract class is being used to apply multiple interface inheritance. In that case, the abstract class really needs to be pure abstract. Is there a way for C++ to somehow enable an pure abstract base class to enforce its contracts? Seems like an unfixable paradox. I don't know if I can help because I don't know what you are talking about. This is a C++ (and, incidentally, a plain text) newsgroup, but I don't see much in your post beyond a whole lot of OO jargon. If you have a C++ question, and you can ask it in _plain_ language, and without undefined abbreviations such as 'LSP', please ask it. In the meantime, I'll have a stab at answering this part: "However, if the pure abstract base class defines a method to enforce its contract, it will no longer be pure abstract." // abstract class class Base { public: virtual void f() = 0; // pure virtual }; // implementation of pure virtual void Base::f() { } // concrete class class Derived : public Base { public: void f() {} // override Base::f() }; int main() { Derived d; // okay Base b; // error; Base::f() pure virtual } The point is that Base is still abstract, or "pure abstract" as you put it, even though Base "defines a method" for its only pure virtual function. DW Back to top jeffc Guest Posted: Mon Oct 27, 2003 5:04 pm    Post subject: Re: Design by Contract for abstract base class? "David White" <no (AT) email (DOT) provided> wrote Quote: kk_oop<no_spam> @yahoo.com> <"kk_oop news:bnh5k7$cje$2 (AT) bob (DOT) news.rcn.net... Hi. I'm looking to find a way to apply Design by Contract in my C++ programs. The problem that I'm having deals with pure abstract base classes. Since these are often how an object gets exposed to clients via polymorphism, it seems critical that an abstract base class can define and enforce its contracts. Defining contracts is critical, so LSP can be utilized when defining derived implementation classes. However, if the pure abstract base class defines a method to enforce its contract, it will no longer be pure abstract. This poses a problem, for instance, if the abstract class is being used to apply multiple interface inheritance. In that case, the abstract class really needs to be pure abstract. Is there a way for C++ to somehow enable an pure abstract base class to enforce its contracts? Seems like an unfixable paradox. I don't know if I can help because I don't know what you are talking about. This is a C++ (and, incidentally, a plain text) newsgroup, but I don't see much in your post beyond a whole lot of OO jargon. If you have a C++ question, and you can ask it in _plain_ language, and without undefined abbreviations such as 'LSP', please ask it. OO jargon is obviously part of C++, since C++ is an OO language. LSP is Liskov Substitution Principle, which basically says that inheritance should be used when a subclass object can be substituted for a base class object, and the code would still work the same. Quote: In the meantime, I'll have a stab at answering this part: "However, if the pure abstract base class defines a method to enforce its contract, it will no longer be pure abstract." He might be confusing "pure abstract" with "pure virtual", or there might be an OO term that would translate in C++ terms to "a base class with a pure virtual function that has no function definitions". Or, as you said, he might not be aware that abstract classes can have function definitions while still not allowing any instances to be created. I'd ask the OP what his definition of "abstract class" is, at this point. Back to top David White Guest Posted: Mon Oct 27, 2003 10:40 pm    Post subject: Re: Design by Contract for abstract base class? jeffc <nobody (AT) nowhere (DOT) com> wrote Quote: "David White" <no (AT) email (DOT) provided> wrote in message news:vE%mb.87$xm.6381 (AT) nasal (DOT) pacific.net.au... I don't know if I can help because I don't know what you are talking about. This is a C++ (and, incidentally, a plain text) newsgroup, but I don't see much in your post beyond a whole lot of OO jargon. If you have a C++ question, and you can ask it in _plain_ language, and without undefined abbreviations such as 'LSP', please ask it. OO jargon is obviously part of C++, since C++ is an OO language. Yes, but I've never see so much OO jargon in discussions of C++ features. What exactly does it mean for an abstract base class to "define and enforce its contracts"? Is "multiple interface inheritance" simply multiple inheritance? The OP is speaking a language that I don't recall most of the C++ experts in this newsgroup ever speaking. Quote: LSP is Liskov Substitution Principle, which basically says that inheritance should be used when a subclass object can be substituted for a base class object, and the code would still work the same. I have a colleague who is usually brilliant at recalling the meanings of the most obscure abbreviations used in a range of computing-related areas. If I come across one I don't know, I call out, "What does <insert abbrev> mean?" and he can nearly always tell me. He and I are also project leaders and OO designers and implementers of about 10 years experience. Neither of us knew what "LSP" meant. The principle itself seems rather obvious to me and I use it all the time, but I don't feel as though I've missed anything important in not knowing its name. DW Back to top Ken Guest Posted: Tue Oct 28, 2003 1:46 am    Post subject: Re: Design by Contract for abstract base class? "jeffc" <nobody (AT) nowhere (DOT) com> wrote Quote: He might be confusing "pure abstract" with "pure virtual", or there might be an OO term that would translate in C++ terms to "a base class with a pure virtual function that has no function definitions". Or, as you said, he might not be aware that abstract classes can have function definitions while still not allowing any instances to be created. I'd ask the OP what his definition of "abstract class" is, at this point. Hi. What I was trying to refer to is a class that has only pure virtual methods and no data. What is the term for that in C++? In Java and UML it's an interface. Anyway, perhaps that puts my original question in a clearer context? My understanding of C++ (based on Scott Meyers' Effective C++) is that multiple inheritance should only be done for interface base classes (using my definition of interface class above). By adding a contract verification method to the interface base class, it should no longer be used in multiple inheritance relationships, since it would have implementation. But if you don't define these contract verification methods in the base class, you'd have to define them in every instance of the derived classes. Perhaps not a bad thing. Or perhaps there's another way to do this--maybe with ASSERTs? If that adds some clarity, are there any suggestions or comments? Thanks again, Ken Back to top David White Guest Posted: Tue Oct 28, 2003 2:10 am    Post subject: Re: Design by Contract for abstract base class? Ken <kk_oop (AT) yahoo (DOT) com> wrote Quote: "jeffc" <nobody (AT) nowhere (DOT) com> wrote He might be confusing "pure abstract" with "pure virtual", or there might be an OO term that would translate in C++ terms to "a base class with a pure virtual function that has no function definitions". Or, as you said, he might not be aware that abstract classes can have function definitions while still not allowing any instances to be created. I'd ask the OP what his definition of "abstract class" is, at this point. Hi. What I was trying to refer to is a class that has only pure virtual methods and no data. What is the term for that in C++? In Java and UML it's an interface. I don't know, but I doubt it has a different name in C++. I've never paid much attention to whether a class that only has pure virtual functions has data members or not, because I don't see how that makes a fundamental difference to it either way. Quote: Anyway, perhaps that puts my original question in a clearer context? My understanding of C++ (based on Scott Meyers' Effective C++) is that multiple inheritance should only be done for interface base classes (using my definition of interface class above). I haven't read it, but that sounds a bit odd to me. I've hardly ever used multiple inheritance for any purpose. It just seems unwieldy and inelegant to me, but if I were to use it I don't see why it should be restricted to interface classes. Quote: By adding a contract verification method to the interface base class, it should no longer be used in multiple inheritance relationships, since it would have implementation. I think it's necessary to fully understand the reason for what "should" no longer be done. If there's a compelling reason that multiple inheritance should not be used just because you add implementations for pure virtual functions, I can't guess what it is. Do what works unless someone can identify why it shouldn't be done. Quote: But if you don't define these contract verification methods in the base class, you'd have to define them in every instance of the derived classes. Perhaps not a bad thing. Or perhaps there's another way to do this--maybe with ASSERTs? Can you give an example of what a contract-verification method does, preferably with some real code? DW Back to top kenandeva Guest Posted: Tue Oct 28, 2003 2:35 am    Post subject: Re: Design by Contract for abstract base class? David White wrote: Quote: "David White" <no (AT) email (DOT) provided> wrote in message news:vE%mb.87$xm.6381 (AT) nasal (DOT) pacific.net.au... DW: For info on contracts and LSP, see: http://ootips.org/lsp.html It's got some cross reference links to additional info. You can look at LSP almost like a design pattern, in that it's a good practice that lots of good OO designers do without giving it a name. Barbara Liskov gave it a name and wrote a paper about it, so, just like with a design pattern, the name she gave stuck--and it just happens to include her own name (as in Liskov Substitutability Principle). Save that for the OO version of Trivial Pursuit. Though I do find it useful to just refer to the concept as LSP, just like calling a Singleton a Singleton is easier that describing what it means every time you need to bring it up. If you want to see her original paper (I wouldn't recommend it--it's very dense. The OO tips links are much more readable.), it's called: A Behavioral Notion of Subtyping. Doing a Google search reveals many PDF versions suitable for framing and giving as gifts this holiday season . My questions have to do with defining the contracts used to verify LSP--namely should they just be comments in a method or class abstract, or can/should they be actually included in the code via ASSERTs or contract verification methods. See ya, Ken Quote: Back to top jeffc Guest Posted: Tue Oct 28, 2003 3:37 pm    Post subject: Re: Design by Contract for abstract base class? "David White" <no (AT) email (DOT) provided> wrote Quote: OO jargon is obviously part of C++, since C++ is an OO language. Yes, but I've never see so much OO jargon in discussions of C++ features. That was quite a load :-) Quote: LSP is Liskov Substitution Principle, which basically says that inheritance should be used when a subclass object can be substituted for a base class object, and the code would still work the same. I have a colleague who is usually brilliant at recalling the meanings of the most obscure abbreviations used in a range of computing-related areas. If I come across one I don't know, I call out, "What does mean?" and he can nearly always tell me. He and I are also project leaders and OO designers and implementers of about 10 years experience. Neither of us knew what "LSP" meant. The principle itself seems rather obvious to me and I use it all the time, but I don't feel as though I've missed anything important in not knowing its name. Yes, the principle is sometimes called just "substitutability", as in C++ FAQs. Someone (Liskov?) decided someone needed credit for it. I don't think you've missed anything either. Back to top jeffc Guest Posted: Tue Oct 28, 2003 3:39 pm    Post subject: Re: Design by Contract for abstract base class? "kenandeva<no spam> @yahoo.com>" <"kenandeva Quote: My questions have to do with defining the contracts used to verify LSP--namely should they just be comments in a method or class abstract, or can/should they be actually included in the code via ASSERTs or contract verification methods. ASSERTs are pretty much a waste of time, since they only affect debug code (I've never been much of a fan of ASSERT). Comments would be good, but they can never be enforced (I know, I tried - that was my job for about 6 months one time.) Back to top jeffc Guest Posted: Tue Oct 28, 2003 3:42 pm    Post subject: Re: Design by Contract for abstract base class? "Ken" <kk_oop (AT) yahoo (DOT) com> wrote Quote: "jeffc" <nobody (AT) nowhere (DOT) com> wrote He might be confusing "pure abstract" with "pure virtual", or there might be an OO term that would translate in C++ terms to "a base class with a pure virtual function that has no function definitions". Or, as you said, he might not be aware that abstract classes can have function definitions while still not allowing any instances to be created. I'd ask the OP what his definition of "abstract class" is, at this point. Hi. What I was trying to refer to is a class that has only pure virtual methods and no data. What is the term for that in C++? In Java and UML it's an interface. I don't think there is a term for that in C++ because there's nothing to enforce it. An abstract class can have data. Quote: Anyway, perhaps that puts my original question in a clearer context? My understanding of C++ (based on Scott Meyers' Effective C++) is that multiple inheritance should only be done for interface base classes (using my definition of interface class above). Maybe I'm not the best person to ask because I'm not sure I agree with him. You might ask on comp.object. Even though you're asking about C++ specifically, that shouldn't throw them off. Back to top jeffc Guest Posted: Tue Oct 28, 2003 3:44 pm    Post subject: Re: Design by Contract for abstract base class? "David White" <no (AT) email (DOT) provided> wrote Quote: I haven't read it, but that sounds a bit odd to me. I've hardly ever used multiple inheritance for any purpose. It just seems unwieldy and inelegant to me, but if I were to use it I don't see why it should be restricted to interface classes. It can come in handy for "mix-in" classes. You will see many references to this on the web, e.g. http://archive.devx.com/free/mgznarch/vcdj/1998/augmag98/mixin1.asp Back to top jeffc Guest Posted: Tue Oct 28, 2003 3:45 pm    Post subject: Re: Design by Contract for abstract base class? "jeffc" <nobody (AT) nowhere (DOT) com> wrote Quote: "David White" <no (AT) email (DOT) provided> wrote in message news:Keknb.153$xm.8590 (AT) nasal (DOT) pacific.net.au... I haven't read it, but that sounds a bit odd to me. I've hardly ever used multiple inheritance for any purpose. It just seems unwieldy and inelegant to me, but if I were to use it I don't see why it should be restricted to interface classes. It can come in handy for "mix-in" classes. You will see many references to this on the web, e.g. http://archive.devx.com/free/mgznarch/vcdj/1998/augmag98/mixin1.asp Or more to the point for you http://archive.devx.com/free/mgznarch/vcdj/1998/augmag98/mixin2.asp Back to top Julián Albo Guest Posted: Tue Oct 28, 2003 5:05 pm    Post subject: Re: Design by Contract for abstract base class? jeffc escribió: Quote: ASSERTs are pretty much a waste of time, since they only affect debug code (I've never been much of a fan of ASSERT). Comments would be good, butthey An assert is a comment that is enforced at debug time. Regards. Back to top lilburne Guest Posted: Tue Oct 28, 2003 8:30 pm    Post subject: Re: Design by Contract for abstract base class? jeffc wrote: Quote: "kenandeva<no spam> @yahoo.com>" <"kenandeva news:bnkkci$dq2$1 (AT) bob (DOT) news.rcn.net... My questions have to do with defining the contracts used to verify LSP--namely should they just be comments in a method or class abstract, or can/should they be actually included in the code via ASSERTs or contract verification methods. ASSERTs are pretty much a waste of time, since they only affect debug code (I've never been much of a fan of ASSERT). Comments would be good, but they can never be enforced (I know, I tried - that was my job for about 6 months one time.) Someone came for an interview with us once and said they were just starting to use exceptions in their code, one of the interviewers growled "We don't like fucking exceptions, and you won't be fucking well throwing any here". I'll attempt to be more diplomatic but it may be hard to disguise my disgust. When we last looked into exceptions we discovered a 14-18% performance degradation due to the code that was being inserted to handle stack unwinding. Things may be different now, but at the time we found that alone to be an unacceptable price to pay. We are also deeply suspicious of the use of exceptions to enforce class contracts. We simply do not believe, for example, that failure to honour a precondition is an exceptional condition: it is a BUG. Throwing exceptions because function arguments are out of range, or invalid seems to be an abomination particularly prevalent amongst programmers schooled in java, or at least recent CS graduates. The problem with this style of programming is that you are forcing customers of your runtime system to pay a price for the fact that the caller couldn't or wouldn't honour a methods published contract. Our code is heavily laced with assertions. Each method will assert that its preconditions have been met and that the state invariant is valid, some parts of our code run 20x slower in debug than release due to such checks. Using exceptions for these checks would place that burden into the customer releases, that is totally unacceptable, and we would not consider code that did not perform such checks was of adequate quality. If someone passes me a point or vector in 3d space I expect it to be properly initialized not to hold some crappy value due to a default construction and I don't need to do millions of such checks in a customer release. One thing that does amuse is that those using exceptions the most, tend also to be those that think that inlining a set method will speed up their application, or worry over the speed of '++i' vs 'i++' when i is an int. I'm sure that there are plenty of valid reasons for using exceptions, I just don't think those reasons are as prevalent as people think, and they haven't been found in the applications we write. BTW the interviewee got the job. Back to top Ken Guest Posted: Wed Oct 29, 2003 1:39 pm    Post subject: Re: Design by Contract for abstract base class? lilburne <lilburne (AT) godzilla (DOT) net> wrote Quote: Our code is heavily laced with assertions. Each method will assert that its preconditions have been met and that the state invariant is valid, some parts of our code run 20x slower in debug than release due to such checks. Using exceptions for these checks would place that burden into the customer releases, that is totally unacceptable, and we would not consider code that did not perform such checks was of adequate quality. That last sentence threw me off. Too many nots for my little brain . Are you saying that code that performs the checks as exceptions is not acceptable? I do agree that exceptions are overused to identify "normal" error conditions--namely errors which are not due to a bug in the software. But if the error is actually a bug, it probably shouldn't be happening too often, and when it does--that path of the software shouldn't be used until it gets debugged. So I'm thinking that the performance hit of an exception might not be a problem here. Here's a follow up question: How do you handle contract definition in your abstract interface base classes? As I mentioned earlier in the thread, this is a concern with respect to enforcing LSP. I'm eager to know how folks handle that. Thanks so much! Ken Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language (comp.lang.c++) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.