Hi,
It was mate, actually there was a missing word in my saying, I meant:
I agree about changing only non idempotent classes in a 1st approach.
That's obviously _NOT_ service and events, but could be also few helper and
worker classes.
All the utility classes should be checked and non idempotent methods (if any)
extracted
To be clear: an idempotent class is a class which does not change the state.
For utilities That depends on its methods not on the class.
I agree about steps by steps approach
Jacques
Le 23/04/2020 à 06:46, Girish Vasmatkar a écrit :
Hi
I am unsure if this needs to be extended or applied to the service classes
because even though the service classes do not appear to maintain state,
they conceptually relate to the business domain and hence are not a worthy
candidate. Moreover they are executed within a context and don't qualify as
typical helper or utility classes.
We should be all for this change but probably exempt service classes from
it and restrict this change to Helper/Utility classes. Also, it will be
helpful if we bring this about in phases.
+1 for helper/utility classes.
Best,
Girish
On Wed, Apr 22, 2020 at 11:55 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Le 22/04/2020 à 19:58, Jacques Le Roux a écrit :
I have still to read the articles an understand the Lombok project and
how we could possibly use it
I'm thinking about https://projectlombok.org/setup/gradle but I have no
ideas yet to what it entails, someone knows?
Jacques
