This discussion is archived
1 Reply Latest reply: Dec 26, 2011 1:56 PM by jschellSomeoneStoleMyAlias RSS

How to separate business logic from polymorphic entities

906212 Newbie
Currently Being Moderated
I know the title might sound awkward but I couldn't find the right way to describe my point.

Here is an example of the problem:

Let's say I have two entites Bike and Car inherting from the Vehicule interface.
Now let's say I have a business process (like fix vehicule) implemented in multiple services that's exactly the same for all vehicles except one tiny bit of code.

My problem is how do I reuse this common code?
I have a few ideas for implementing this but I don't know what the best practices are (I wont talk about the instance of opertator which shouldn't be used).
In the following examples I have a FixVehiculeService service that calls SomeService1, then SomeService2 and finally a SomeService3 that implements the custom methods.

*1/ Duplicate the services:*

Here the logic would be implemented in parameterized classes:

FixVehiculeService<T>
----+ SomeService1<T>
--------+ SomeService2<T>
------------+ SomeService3<T>

Then the classes would be instanced with the proper type.

FixVehiculeService<Bike>
----+ SomeService1<Bike>
--------+ SomeService2<Bike>
------------+ SomeService3<Bike>

FixVehiculeService<Car>
----+ SomeService1<Car>
--------+ SomeService2<Car>
------------+ SomeService3<Car>


Pros:
+ Type validation you need to call FixVehiculeService whit the proper type

Cons:
- Duplicates the architecture (lot of spring config).




*2/ Visitor pattern:*

In this pattern the dispatch is implemented directly inside the entity (the Vehicule interface would describe the visit method).

FixVehiculeService<Vehicule>
----+ SomeService1<Vehicule>
--------+ SomeService2<Vehicule>
------------+ SomeService3<Vehicule>
// Vehicule.visit(SomeService3)

Pros:
+ Single instanciation of the architecture.

Cons:
- The entity layer references the business layer.
  • 1. Re: How to separate business logic from polymorphic entities
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    903209 wrote:
    Now let's say I have a business process (like fix vehicule) implemented in multiple services that's exactly the same for all vehicles except one tiny bit of code.

    My problem is how do I reuse this common code?
    How many variations now? How many realistically (not wildly optimistic and bounded by reality) in the future?

    If the answer is very few then create one class with some switch logic.

    If many then how realistically likely is that in the future that the common logic will remain the same?
    If it is likely then myself I would create a business base class with appropriate children.
    If you cannot state that it is likely then I would break the common functionality into helper (class) code and create a distinct business class for each modeled entity. It would then use the helper. Advantage to this is that when the common functionality is no longer common it doesn't introduce external dependency problems.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points