1

I am creating a web application and I am injecting a SystemManager interface in it. All of my business logic resides behind it and pages just have to request data from it. I would like to create a generic implementation which would get a method signature and based on the annotation it would invoke the correct method in the system.

The implementation of this interface acts like a facade pattern - it just calls methods on different objects.

The current implementation is

SystemManager.java

void executeA();

void executeB();

SystemManagerImpl.java

void executeA(){
   SystemA.exectueA();
}

void executeB(){
   SystemB.exectueB();
}

But I would like to replace it with some generic solution like

SystemManager.java

@SystemA
void executeA();

@SystemB
void executeB();

SystemManagerImpl.java

void genericMethod(){
   // based on the annotation of the method received I am calling correct System class and invoking correct method
}

I dont think this is possible but still I am open to suggestions.

Paul Bellora
  • 54,340
  • 18
  • 130
  • 181
Boris Horvat
  • 563
  • 2
  • 13
  • 28
  • Well, one thing to avoid when structuring your question is talking about how you can't structure your question at the very beginning. The very first sentences are visible when mousing over the question title and should contain content that will hopefully make people decide to click. – millimoose May 19 '13 at 20:22
  • Also, it's not clear what `genericMethodImpl()` should actually do. Can you provide a non-generic example of what the behaviour should be when you call `SystemManager.executeA()`? – millimoose May 19 '13 at 20:26
  • http://stackoverflow.com/questions/1805200/retrieve-java-annotation-attribute might be helpful. – m0s May 19 '13 at 20:34
  • Are you trying to call genericMethod but pass in an annotated interface? – greedybuddha May 19 '13 at 20:48
  • 1
    I'm calling designwank. How does it make the code any better to move the delegation target to the interface? You save exactly repeating the method name once per method. Remember that your `SystemManagerImpl` class still has to implement all the methods from its interface. (Unless you use a dynamic proxy, which just adds another cryptic layer on top of things.) Furthermore, isn't the point of using a facade the fact that choosing where a method is delegated is up to the implementation? Putting this information into the interface seems violating the purpose of the pattern. – millimoose May 19 '13 at 21:18
  • Dynamic proxy sounds like that thing I might be looking for. I dont really agree that putting this information into interface would break it as facade doesnt usually have interface so I would argue that interface and implementation work together to create a facade. I define in interface what method should be called on what target and then in implementation I dynamicly connect everything (if it is possible using dynamic proxy that is) – Boris Horvat May 19 '13 at 21:44
  • 2
    If your SystemManager is a huge God class containing every business methof of your app, and all it does is delegating to other services, then you'd better remove it entirely, and inject the services it delegates to directly into your controllers. – JB Nizet May 19 '13 at 22:01
  • @BorisHorvat No idea about "usually", although I doubt it since coding against interfaces is a best practice. Besides, your facade *clearly* has an interface. An interface and its implementation have no business working together - the interface should be unaware of how many implementations there are or what they do. I also agree with the god class objection. A facade layer is pointless if you're not using it for operations that need the cooperation of multiple services (e.g. save X to DB, then send out notifications), or where you need to multiplex between alternative service implementations. – millimoose May 19 '13 at 22:30
  • To elaborate on my point: the interface should say "this is what implementations *must* do, **and** I don't care how they go on about this". Adding annotations that specify delegation targets leaks information (a lot of it) about the implementation into the interface: that the implementations delegate to other objects, and even which objects they delegate to. That couples the two very much and exposes a lot of information to clients. (Now, you could argue that an implementation of SystemManager could exist that just ignores those annotations and does whatever, but that's pretty unlikely.) – millimoose May 19 '13 at 22:36
  • Considering that this class is just a method dispatcher so to say I cant imagine another implementation to exist in the future. However I do agree with the argument presented. I dont really agree with removing the class as I dont see the point in injecting multiple service when I can inject just one that delegates the methods. God object is an object that knows too much or does too much which isn't really the case as this class doesn't do anything and it has know business knowledge it only knows who can do it – Boris Horvat May 19 '13 at 23:58
  • Your system could be small now, but it could evolve and enlarge. If that's the case, your God class will have hundreds of methods. This is already a problem. Finding the right one in such a number is complex. Finding good names for new methods can be problematic. It also makes it hard to identify which part of the system a given controller uses. It would make sense for the OrderController to depend on the Orders and Products services. But if it only depends on SystemManager, it's harder to know its real dependencies. And finally, the dispatcher doesn't seem to add any value. – JB Nizet May 20 '13 at 05:56
  • Hm...I see what you are saying but I guess that I dont really agree in this example. Saying that dispatcher doesn't add any value would be saying that Faced pattern doesnt add any value. Its value is in the fact that external systems have one point of reference instead of 10. However I guess this is beyond to scope of my questions. Still I will reconsider the design. But for now I guess proxy is what I was looking for. – Boris Horvat May 20 '13 at 16:09
  • @BorisHorvat The Facade pattern doesn't dictate there being one uberfacade for everything. If you want a facade layer, it makes more sense to have one facade per controller, or some other sort of front-end module. That way, you'd have the service layer "dispatch" calls to DAOs to perform operations that go across entities, and the facade layer would dispatch operations to related services. It also means that a facade would contain all the "user-facing" operations for a given frontend module. (Whereas services are usually grouped by the "primary" model element they operate on.) – millimoose May 20 '13 at 16:50

0 Answers0