On Wed, 21 Nov 2007 09:35:46 -0800, Abhijit Gadkari <[EMAIL PROTECTED]> wrote:
>Correct me if I am wrong, this is what I understood > > > >A. If you override, do it because you want to extend the existing >functionality but not to replace the existing functionality from the base >class > you need to distinguish between what the method promises to do and what it actually does. what it promises to do may be much less than what it actually does. so you can extent functionality as long as it does not break the original contract....in C# there are no explicit contracts (except the signature), so method names are the best clue to what the method does. So if you name a method in a base class or interface 'Add'....the programmer that uses this code expects it to add (in some languages, see spec#, you can explicitly define this contract)....if it doesn't obey the contract, then substitutability is broken. Your 'Add' example is pretty tightly specified, so there's not too much scope for changing what gets returned....but you could validly override and do something else...e.g. log stuff to a file, write debug info...etc...as long as it also returns the sum of the two numbers passed. > > >B. override will break the substitution > no.....but you should not break the contract/intention of the base method. > > >C. Avoid functional polymorphism for example, as suggested renaming Add (int >one) to times2 or double. Or so to say don't use same name / signature >override that will confuse the client > functional overriding is fine...though I personally don't do it much....but if you're going to name a method something, then it should be descriptive of what it does....if it isn't, you're inviting people to make assumptions that are not valid...and then write bugs. > > >D. Avoid magic number / hack in override method / function > not sure what this means. > > > >On Nov 21, 2007 4:57 AM, Mark Nicholls <[EMAIL PROTECTED]> wrote: > >> On Tue, 20 Nov 2007 13:36:41 -0500, Abhijit Gadkari >> <[EMAIL PROTECTED]> wrote: >> >> >I was doing some code review. I saw something interesting Liskov >> >implementation. [for more info, check out >> >http://en.wikipedia.org/wiki/Liskov_substitution_principle] >> > >> >Here is the sample implementation of the same. >> > >> >namespace ToTest >> >{ >> > class Liskov >> > { >> > public Liskov() >> > { >> > //do nothing >> > } >> > >> > public virtual int Add(int one,int two) >> > { >> > return one + two; >> > } >> > } >> > >> > class DerievedLiskov :Liskov >> > { >> > public DerievedLiskov() >> > { >> > //do nothing >> > } >> > >> > /// <summary> >> > /// <para>to add the number to itself.For Example - Add(4,0) will >> >result 8</para> >> > /// </summary> >> > /// <param name="one"></param> >> > /// <param name="two"></param> >> > /// <returns></returns> >> > public override int Add(int one, int two) >> > { >> > if (two == 0) >> > { >> > return one + one; >> > } >> > else >> > { >> > return base.Add(one, two); >> > } >> > } >> > >> > public int Add(int one) >> > { >> > return one + one; >> > } >> > } >> >} >> > >> >Now, I know there is no validation here. But the point is about >> >substitution principle. Here we have Add method in the base class. An >> >override in derived class will substitute it. >> >> yes....but the problem is what does the client code expect to happen when >> it calls "Add(int one, int two)"....on a liskov object.... >> >> now if the client just expects no more than the signature i.e. you pass 2 >> ints and get one back...then the substitution is technically 'correct'.... >> >> but I expect the client code would expect much more than this.... >> >> if it were me I would expect the result to be the sum of the two >> parameters passed....clearly the override does not do this...so >> substitution is actually broken, and the code is incorrect, the compiler >> doesn't warn you, because it doesn't know...but basically it is at best >> bad practice and at worse a bug. >> >> >> > >> >SO if we want to change the behavior of Add method such that it will >> >accept only one integer and will return the result as int added to itself >> >[i.e. 3+3=6],we have two options as coded in the DerievedLiskov. Which >> one >> >is beter from oo design point? >> > >> >> so from an OO perspective the override is bad/wrong...it breaks (any >> sensible interpretation of the) substitution. >> >> the additional method 'Add' is a much better solution...but I would call >> it 'double' or 'times2'. >> >> >Thanks. >> > >> >Abhi >> > >> >=================================== >> >This list is hosted by DevelopMentor(R) http://www.develop.com >> > >> >View archives and manage your subscription(s) at >> http://discuss.develop.com >> >> =================================== >> This list is hosted by DevelopMentor(R) http://www.develop.com >> >> View archives and manage your subscription(s) at >> http://discuss.develop.com >> > > > >-- >-- >Abhijit Gadkari >Enterprise Architect >Santa Ana,CA-92705 >blog:http://soaas.blogspot.com/ > >=================================== >This list is hosted by DevelopMentor® http://www.develop.com > >View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
