Comments on: Multiple-inheritance, composition and single responsibility principle in .NET http://damieng.com/blog/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net?utm_source=rss&utm_medium=rss&utm_campaign=multiple-inheritance-composition-and-single-responsibility-principle-in-net A .NET developer in Redmond Tue, 31 Aug 2010 00:16:37 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Stealf http://damieng.com/blog/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net#comment-27741 Stealf Wed, 14 Oct 2009 07:38:24 +0000 http://damieng.com/blog/archive/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net.aspx#comment-27741 This is a bit of a late reply but I had essentially the same idea as this and agree that it would be a great addition to the language. http://social.msdn.microsoft.com/Forums/en/csharplanguage/thread/5120d5ef-97ec-4de6-ab6c-9a7b5dfc50de This is a bit of a late reply but I had essentially the same idea as this and agree that it would be a great addition to the language.

http://social.msdn.microsoft.com/Forums/en/csharplanguage/thread/5120d5ef-97ec-4de6-ab6c-9a7b5dfc50de

]]> By: Damien Guard http://damieng.com/blog/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net#comment-5529 Damien Guard Tue, 11 Dec 2007 13:33:00 +0000 http://damieng.com/blog/archive/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net.aspx#comment-5529 What I'm proposing with this post is compiler magic that would signal that an interface a class claims to support should be automatically wired up to a private instance variable where no specific implementation of a method or property exists in the class. Having a get method isn't any better than a read only property, I was just closely following what the IEnumerable / IEnumerator pattern is to see what the result would look like. I think we are after the same thing. We want to be able to define a class, say it supports interface X and that we will be forwarding all methods and properties for that interface to our own private method except any we specifically write - in our case Add. Other alternatives to the specific Add on collection problem you mention would be to force the collection property to be of a <a href="http://damieng.com/blog/2006/06/14/observing_change_events_on_a_listt" rel="nofollow">listening type</a> we can hook into or to internally hold the concrete collection but expose it out through a proxy object on one of our properties that calls us back using internal methods. [)amien What I’m proposing with this post is compiler magic that would signal that an interface a class claims to support should be automatically wired up to a private instance variable where no specific implementation of a method or property exists in the class.

Having a get method isn’t any better than a read only property, I was just closely following what the IEnumerable / IEnumerator pattern is to see what the result would look like.

I think we are after the same thing. We want to be able to define a class, say it supports interface X and that we will be forwarding all methods and properties for that interface to our own private method except any we specifically write – in our case Add.

Other alternatives to the specific Add on collection problem you mention would be to force the collection property to be of a listening type we can hook into or to internally hold the concrete collection but expose it out through a proxy object on one of our properties that calls us back using internal methods.

[)amien

]]> By: John Chapman http://damieng.com/blog/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net#comment-5526 John Chapman Tue, 11 Dec 2007 12:51:36 +0000 http://damieng.com/blog/archive/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net.aspx#comment-5526 I'm failing to see the big accomplishments of this post. A big issue to me is the fact that when you don't implement the interface you lose your ability to validate and monitor the actions taking place with the collection. If someone calls Add() your class doesn't have any hooks to validate that added reference. I think in this case actually implementing the interface on your class is relatively minor yet offers a lot of added benefit, such as being able to reject invalid assignments. Plus, I was confused by something else. How is using a read only property any different from using a get method to return the collection? I fail to see how one approach is superior to the other. They both compile down to the exact same thing. The property becomes a get_ method and the method stays as a method of your name. How is this any different? I hope you don't mean the names are different so it doesn't have to be a list of product prices. If that is the concern change the property to List, and you have the same result. Is there something I'm missing? I’m failing to see the big accomplishments of this post. A big issue to me is the fact that when you don’t implement the interface you lose your ability to validate and monitor the actions taking place with the collection. If someone calls Add() your class doesn’t have any hooks to validate that added reference. I think in this case actually implementing the interface on your class is relatively minor yet offers a lot of added benefit, such as being able to reject invalid assignments.

Plus, I was confused by something else. How is using a read only property any different from using a get method to return the collection? I fail to see how one approach is superior to the other. They both compile down to the exact same thing. The property becomes a get_ method and the method stays as a method of your name. How is this any different? I hope you don’t mean the names are different so it doesn’t have to be a list of product prices. If that is the concern change the property to List, and you have the same result. Is there something I’m missing?

]]> By: steve http://damieng.com/blog/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net#comment-1961 steve Tue, 07 Aug 2007 00:26:24 +0000 http://damieng.com/blog/archive/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net.aspx#comment-1961 Hey, and you've found a use for the 'goto' keyword again. That in itself has to be a positive thing ;)<br /><br />I think like all mantras the 'compose over inherit' principle is correct in moderation. There are plenty of scenarios where composition leads to harder to maintain code, simply because in just about all languages it has to be manually wired up. This is of course its power as well, and I'm not sure you can get the full benefit of the technique without incurring this. At the very least I think you'd need to be able to direct the delegation via a factory method for the contained object (lazy creation) to avoid hard-coding the composed type.<br /><br />Many modern C++ techniques also echew inheritence in favour of templated composition through <a href="http://en.wikipedia.org/wiki/Policy-based_design">Policy Based Design</a>. Again this works very well for some things, particularly low-level utility classes as opposed to higher-evel library APIs. Each technique has its place. Hey, and you’ve found a use for the ‘goto’ keyword again. That in itself has to be a positive thing ;)

I think like all mantras the ‘compose over inherit’ principle is correct in moderation. There are plenty of scenarios where composition leads to harder to maintain code, simply because in just about all languages it has to be manually wired up. This is of course its power as well, and I’m not sure you can get the full benefit of the technique without incurring this. At the very least I think you’d need to be able to direct the delegation via a factory method for the contained object (lazy creation) to avoid hard-coding the composed type.

Many modern C++ techniques also echew inheritence in favour of templated composition through Policy Based Design. Again this works very well for some things, particularly low-level utility classes as opposed to higher-evel library APIs. Each technique has its place.

]]> By: Rik Hemsley http://damieng.com/blog/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net#comment-1960 Rik Hemsley Tue, 07 Aug 2007 00:11:15 +0000 http://damieng.com/blog/archive/2007/08/06/multiple-inheritance-composition-and-single-responsibility-principle-in-net.aspx#comment-1960 You could call a static method on another class from your ctor. This method would add simple versions of the IList methods where they don't already exist.<br /><br />This breaks Intellisense and might destabilise the universe.<br /><br />I can't think of a better way to do it (in a not-exactly-dynamic language). Have you seen an implementation elsewhere?<br /> You could call a static method on another class from your ctor. This method would add simple versions of the IList methods where they don’t already exist.

This breaks Intellisense and might destabilise the universe.

I can’t think of a better way to do it (in a not-exactly-dynamic language). Have you seen an implementation elsewhere?

]]>