Thanks guys for the response. Thanks Kryzsztof for your work with the tutorials!
Patrick: Just to clarify, the problem I'm trying to solve is to intercept behavior on the base class (Pet). I don't believe the interceptors can intercept overridden routines from the base? I think the example provided may not be best, but maybe another goal might be to inject logging for a specific *base *method, Is that doable? Krzysztof: The composition over inheritance was a great idea; I also looked at the Decorator pattern as another way to solve. However, the final business problem I'm trying to solve is simply providing customization of generation of large # of records. Using the decorator/composition, I believe the subclasses may have to implement/forward a large # of calls, which would be overkill for many situations. We've solved this (with some limits) using the Template pattern, where sub-class just override specific record generation routines that need customization logic. The problem stem when we need to tweak some of the base methods, that are also overridden in sub-classes. Any other ideas I could try? On Sun, Dec 9, 2012 at 4:54 PM, Krzysztof Kozmic <[email protected] > wrote: > This will solve your problem: > http://en.wikipedia.org/wiki/Composition_over_inheritance > > > -- > Krzysztof Kozmic > > On Saturday, 8 December 2012 at 7:24 AM, Pingmustard wrote: > > I'm not sure if DynamicProxy can solve the design dilemma I have, but > since the framework looked promising, I thought I might ask the question.. > > I'm designing an object hierarchy. To keep the idea simple, say I have a > Pet class, and a Dog sub-class (eventually, I'd have MANY sub-classes of > Pet statically defined). Pet provides a default virtual talk() method, but > I'd like to somehow be able to change/swap the base talk() if necessary > (maybe I don't like the default "Oops" string). Here's the sample > classes: > > public class Pet > { > public string Name { get; set; } // interceptors will not > capture this guy b/c it's missing virtual (aka overridable) > public virtual int Age { get; set; } > public virtual bool Deceased { get; set; } > > public virtual string talk() > { > return "Oops"; > } > public override string ToString() > { > return string.Format("Name: {0}, Age: {1}, Deceased: {2}", > Name, Age, Deceased); > } > } > > public class Dog : Pet > { > public override string talk() > { > base.talk(); > return "Woof!"; > } > } > > > One possible solution to this dilemma is I could have the Pet.talk have a > dedicated side routine that could be intercepted, and make it a development > guideline to not directly call this routine ("talk_ex"): > > public virtual string talk() > { > return talk_ex(); > } > > > public virtual string talk_ex() > { > return "Oops"; > } > > However, this isn't optimal since all base class I design would have to > remember and manually code in this style (let alone expose the "ex" > routines to sub-classes unnecessarily). I'm hoping DP might have a > better way to solve this problem? I'm designing this from scratch, so > any suggestion is welcome! > > Thanks! > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/castle-project-users/-/_aEAVrxC4nIJ. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
