Timeline for Altering the state of a composed class by its composing classes. Is there any rule or principle for not doing so?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 13, 2020 at 9:04 | comment | added | Darius | I was doing some refactoring to the code and that got me thinking about this dilemma. For me, refactoring sounds always like a good idea but right now, it seems like it conflicts with what would be a convention. Convention which stands in the way of me doing the refactoring. | |
| Aug 13, 2020 at 9:02 | comment | added | Darius |
If you are saying that there is a convention inferred from of the way the most libraries are designed and it can be supported with facts(like your first reason points out), then I am pleased to adopt this approach. However, calling item.Translate(), item.Merge() or item.Delete() looks promising when considering the legibility and aesthetics of the code.
|
|
| Aug 13, 2020 at 9:01 | comment | added | Darius |
I agree with what you are saying regarding collections but the relationship between a collection and its elements is that of aggregation, not composition. Correct me if I'm wrong. In my case, elements are strictly part of only one "collection", that's why I named that method 'Delete' and not 'Remove'. Under the hood, I could have IDisposable implemented on GeoEntity and call Dispose(true) on GeoEntity.Delete(). When your drawing something with a pencil and want to make a correction, you generally erase(delete) the wrong and redraw. This is what I mean by 'Delete'
|
|
| Aug 12, 2020 at 16:08 | comment | added | Doc Brown | There is some truth here, but some of the arguments are IMHO debatable: (1) misses that "element.Delete()" was misnamed, it is actually a remove operation which internally calls "collection.Remove(element)" internally, which includes additional cleanup. That's intended behaviour, nothing wrong here. (2) The current design does not prevent this - an element now has intentionally a primary container, but it can still be part of a second one like an undo stack. (3) This is C#, the deletion is done by the garbage collector when needed, the "Delete" we see here is a misnamer, as I wrote. ... | |
| Aug 12, 2020 at 14:50 | comment | added | Erik Eidt | To me, a substantial issue here is that the interface is incomplete and too hypothetical: constructors are missing parameters, and there are missing collection manipulation methods. I like to think that one could work through issues from the perspective of the consuming client (who needs an (ideally simple) model for how things are supposed to work), without necessitating implementation (though implementation would likely help the OP realize some issues). | |
| Aug 12, 2020 at 14:50 | comment | added | Erik Eidt | +1: I share the same concerns about elements belonging to multiple collections, and bucking established conventions of collections. | |
| Aug 12, 2020 at 13:22 | history | answered | Karl Bielefeldt | CC BY-SA 4.0 |