Guys i am a bit new to object modelling and hope you can guide me a bit on this one. I have a requirement where a Customer can have multiple Systems assigned to him. Depending on which system is selected, a different set of rules (in this case mandatory field checks) applies to the parent Customer object. The obivous structure for me here would be:
But then I am questioning the above... As every system generates a different set of checks, should I have 1 class per system inheriting from a base System class? Or is that not good design/overkill?
Also, where would the checks reside? I would probably place them in Customer but then it also gets messy because since I am placing logic specific to a system within the Customer class...
Any suggestions to get the above model a bit more structured?
In general, you need to ask yourself who's job is it to do what?
It is clearly not the job of SystemEdit to impose rules on CustomerEdit. Well-behaved objects don't impose rules on each other. But they can certainly be helpful!
The rules must be managed from within CustomerEdit itself, because it is the object affected by these changes.
However, you could end up with a lot of conditional code inside of CustomerEdit to deal with a large number of types of system, and so you need a way to simplify that task.
Your rules are mandatory field checks - which I take to mean that CustomerEdit.X is required only when a specific type of system is in the list. I'm assuming here that each SystemEdit knows (or could know) which fields are required, but as noted earlier, they can't force CustomerEdit to do anything.
But CustomerEdit could have a rule method that loops through the child list, asking each child if the specified field is required.
So some SystemEdit object would know that X is required. In CustomerEdit, when rules are checked for X, (if the value provided is string.Empty) the rule method would walk through the list of child objects, asking each in turn if X is required. If any answer yes, then the rule would fail, otherwise it wuold succeed.
This way every object is responsible for itself, but they all work together in a polite way to solve the problem.
Copyright (c) Marimer LLC