Create a project with the interfaces/annotations about mbassador HOT 4 CLOSED

Have a look at #153

from mbassador.

Thanks, I've read it.
Anyway, I think that my question is a bit different.
I explain it better.

I have a library, ContextALibrary, that has just some dependencies. In this project I've a ProcessManagerClass that uses my SystemEventBus interface to work.

The SystemEventBus is a custom interface that is defined in another library, EventBusLibrary.
I've done this because, I like to split interfaces from their implementation (so if one day my boss says "We have to use another EventBus because we have this request!" only the implementation of the SystemEventBus changes).

Its implementation with MBassador is in EventBusMBassadorLibrary.

Actually, to make the things working in the ContextALibrary I've had to add the annotations to the ProcessManagerClass, bringing in a way or another the MBassador as dependency. At first sight it is nothing so bad. But now:

• Option 1: ContextALibrary has a direct dependency to EventBusMBassadorLibrary, so whenever I change MBassador in EventBusMBassadorLibrary an update in ContextALibrary is done too
  • I've lost my separation between my interface and my implementation that uses MBassador
  • A change in one library could generate a waterfall of changes in several libraries
  • (I have classes that are useless in my library because I work just with the interfaces)
• Option 2: ContextALibrary has a dependency to MBassador, so no update is done in ContextALibrary if I change EventBusMBassadorLibrary
  • this options looks better, but every time I add both the libraries (ContextALibrary and EventBusMBassadorLibrary) I've to remember to exclude MBassador from one (hopefully ContextALibrary)

At the end, all comes from this book: https://www.amazon.com/dp/0321204654
It's suggested to split the interfaces from their implementations (and also the annotation, I would say). In this way you obtain a great separation between the different layers of the software.

from mbassador.

I do not fully understand the details of your use case from your description. However, I think that I have an idea of what you want to achieve. My advise is not to overcomplicate things. Design patterns are useful when applied to scenarios where they are actually helpful, not just because it is generally advisable to do X.

A very useful rule of thumb (IMHO) is to check whether the potential change that is the reason for introducing a design pattern is actually likely to occurs. Read section 'one last thing' for instance http://www.bloomy.com/support/blog/solid-software-one-thing

In your case: MBassador will not change within the forseeable future. The interface is very stable, there have not been bug reports in the last year(s) and I don't plan to put much more features in.

I will not change the library packaging and maintain two separate projects as for the time being. I might change my opinion later but I don't know yet, why I would :)

Sorry, if that is not the answer you wanted. You have to understand that all of the works on such a project happens in free time and is done for free as well. I have plenty of code to write in many projects.

from mbassador.

from mbassador.