[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Goals, Requirements and API for journaled events

Am Mo., 31. Dez. 2018 um 10:24 Uhr schrieb Dominik Przybysz <

> Maybe also consider using DTOs as input parameter in Messaging interface
> methods, because it would make it easier for future extensions without
> method overloading e.g. instead of
> Subscription subscribe(String topic, Position position, Seek seek,
> Consumer<Message> callback);
> you can use
> Subscription subscribe(SubscriptionSpecification
> subscriptionSpecification);
> class SubscriptionSpecification {
>  String topic;
>  Position position;
>  Seek seek;
>  Consumer<Message> callback;
> }
> It would also allow for setting default values for parameters.

I have no strong opinion about this. What do others think?

> I would like to ask why tle Messaging interface has methods like
> positionFromString and positionToString? It looks like those methods should
> belong to the interface Position, isn't it? The same with the method
> newMessage. I don't see an obvious connection between method send and
> subscribe. Maybe consider splitting the Messaging interface into smaller
> ones?

Position as well as Message currently are interfaces. So we need some way
to create the provider specific objects. So I think positionFromString as
well as newMessage can only be on the interface the provider supplies as a
service. The method positionToString() can be on the Position interface of
course. I am fine with moving it.

Send and subscribe could live on different interfaces but the provider must
then offer services for both interfaces. A common interface is more
convenient when you want to inject the service into an object that wants to
send and receive but on the other hand having separate interfaces makes
each single interface more concise and easier to evolve. Like above I do
not have a strong opinion about this.


Christian Schneider

Computer Scientist