I have base two classes, Operation and Trigger. Each has a number of subclasses which specialise in certain types of operations or triggers. A Trigger can trigger a specific Operation. Whilst an Operation can be triggered by a specific Trigger.I need to write the code that maps a given Operation to a given Trigger (or vice versa), but I'm not sure where to put it.In this case the code doesn't clearly belong to one class or the other class. So in terms of a single-responsibility principle I'm not sure where the code should belong.I can see three options which would all work. Whilst 1 & 2 are appear to just be a choice of semantics, 3 represents a different approach entirely.On the trigger, e.g. bool Triggers(Operation o). On the operation, e.g. bool TriggeredBy(Trigger t). In an entirely new class which manages the mapping, e.g. bool MappingExists(Trigger t, Operation o).How should I decide where to place the shared mapping code in respect of a single responsibility principle?How to manage single responsibility when the responsibility is shared?Edit 1.So the actual code looks like this. All the properties, are either a string, Guid, collection<string>, or enum. They are basically just represent small pieces of data.Edit 2.The reason for the return type of bool. Another class is going to consume a collection of Trigger and a collection of Operation. It needs to know where a mapping exists between a Trigger, and an Operation. It will use that information to create a report.
How to manage single responsibility when the responsibility is shared?
object oriented;single responsibility
I would think about it this way: how is it determined which Operation causes which Trigger to be triggered. It has to be an algorithm which can change over time, or evolve into multiple algorithms. Putting it in either Trigger or Operation classes imply that those classes will be able to handle such scenarios in the future. Note, that I do not see it as simple as a mapping since there may be more to it.My choice would be to create a class with appropriate methods, such as GetOperationForTrigger(Trigger t). This allows the code to evolve into a set of such classes the choice of which can depend at runtime or other variables (e.g. strategy pattern).Note that the main assumption in this line of thinking is to write minimal code (i.e. three classes today) but to avoid major refactoring if the functionality needs to be extended in the future by not making the assumption that there will always be exactly one way to determine which Trigger causes which Operation.Hope this helps. Although the response is similar to user61852, the reasoning is different. As a result, the implementation will differ (i.e. have explicit methods instead of overriding equals, so the number of methods can evolve over time based on the needs).