search

bennidi / mbassador

Powerful event-bus optimized for high throughput in multi-threaded applications. Features: Sync and Async event publication, weak/strong references, event filtering, annotation driven
MIT License
955 stars 146 forks source link

Create a project with the interfaces/annotations #158

Closed LukMas closed 6 years ago

LukMas commented 6 years ago

Hi!

I would like to have a project where all the main interfaces/annotations are collected and separated from their implementation. In this way I can create a project that depends just upon the basic interfaces/annotations, without having to deal with the whole mbassador project.

bennidi commented 6 years ago

Have a look at #153

LukMas commented 6 years ago

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:

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.

bennidi commented 6 years ago

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.

LukMas commented 6 years ago

The project I work it's big enough (and it needs a long refactoring step) that applying any patter before gives just a bit of help to don't improve its "entropy". Anyway, my request was far more a "I would like" then a real problem. I understand that you're really busy and that doing this is far away from your priorities. So don't say sorry; it's already a lot the fact that you offer us, for free, such a great piece of software.

Thank you for your time.

On Fri, May 18, 2018, 16:24 Benjamin Diedrichsen notifications@github.com wrote:

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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bennidi/mbassador/issues/158#issuecomment-390223762, or mute the thread https://github.com/notifications/unsubscribe-auth/AS74CAIfYioiSFB3kvuvaB6bvvvKB-tNks5tztmcgaJpZM4UEM4t .