Timeline for share method logic along classes without inheriting from abstract class

6 events

when toggle format	what		by	license	comment
Apr 10, 2017 at 15:16	answer	added	Frank Hileman		timeline score: 0
Apr 10, 2017 at 14:10	answer	added	svidgen		timeline score: 6
Apr 10, 2017 at 13:09	comment	added	Ben Cottrell		Yes, very similar to a collection - the interface for .NET collections are probably a useful source of inspiration for managing objects which are logically related to each other. If your Add/Remove methods belong to that separate collection class, then (If I understand your question correctly) you would no longer need to find ways of sharing that behaviour between your different stored objects, as those objects wouldn't 'care' about how to add/remove/etc.
Apr 10, 2017 at 12:54	comment	added	Vincent		@BenCottrell do you mean create a sperate class which contains the collection (A kind of list class) which handles the links between classes?
Apr 10, 2017 at 12:44	comment	added	Ben Cottrell		The source of complexity seems to be that each object is responsible for adding and removing its own links to the rest of the topology. Have you considered moving the Add/Remove behaviour out to a 'collection' class instead, so that the 'data' objects do not need to know or care about Add/Remove/etc? For example, consider the way that `List<T>` or `Dictionary<K,V>` doesn't put any burden on the objects which you add/remove to those collections.
Apr 10, 2017 at 11:54	history	asked	Vincent	CC BY-SA 3.0