Announcement Announcement Module
Collapse
No announcement yet.
Best Practices with services and domain objects when wanting inheritance Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Best Practices with services and domain objects when wanting inheritance

    Say you have some domain objects that inherit from each other. For example, at the top you have an abstract class called TopParent, and then two classes extend it, LevelOneChild and LevelOneChild2, and then one class extends LevelOneChild called LevelTwoChild. All these classes just hold some data, and there are some operations that need to be performed on the data. We're trying to have this business logic in singleton services as much as possible. We've discussed different ways of doing this, and I'm just wondering if there's a best practice for this situation.

    What we have discussed is that we mirror this hierarchy in some singleton objects. For example, we would have services called TopParentService, LevelOneChildService, LevelOneChild2Service, and LevelTwoChildService, with the same hierarchy as listed above. Methods would be implemented differently based on where they are in the hierarchy.

    Now, what is the best way of calling these methods?

    One thought was to create a service that basically just takes as a parameter the domain object (TopParent). In the code, it would always return a TopParentService, but it would return the correct instance based on what instance the TopParent is. Then you just call the desired method, and through polymorphism, the correct business logic is run on the data contained in the domain object. The problem with this is that there will be a whole bunch of unrelated methods thrown in all together in these classes. It could get long and ugly pretty quick.

    The other thought was to create these singleton objects like I just explained, except you would create several of these hierarchies based on the business logic that needs to be done. This prevents the problem listed in the first option, in that all the methods would be specific to the set of business logic that needs to be run, and not all lumped together in one class. The problem with this is having to create a bunch of these hierarchies all throughout the different sets of business logic.

    I hope this situation I've described makes sense. Please ask for clarification if needed. I just want to know what anyone's thoughts are on accomplishing this. We just thought of those two ways, but maybe there's a better way of doing it all. I'm open to any suggestions. Thanks.
Working...
X