Vyacheslav,
When you analyze code full of generic stuff like tuples and closures, it is
much harder to understand what is going on and navigate the code.
Good coding: GridDhtAtomicCache - specific interface for callback. Easy to
navigate and understand.
interface UpdateReplyClosure extends
CI2<GridNearAtomicAbstractUpdateRequest, GridNearAtomicUpdateResponse> {
...
}
Bad coding: CacheContinuousQueryHandler.AcknowledgeBuffer - overcomplicated
generic, no JavaDocs, nullable semantics. Complexity out of nothing.
@Nullable synchronized IgniteBiTuple<Map<Integer, Long>,
Set<AffinityTopologyVersion>> onAcknowledged(GridContinuousBatch batch) {
...
}
On Tue, May 16, 2017 at 1:22 PM, Vyacheslav Daradur <daradu...@gmail.com>
wrote:
> Vladimir, thank you for this suggestion.
> As newcomer in the Ignite I agree with you, sometimes it is very hard to
> understand huge classes which contain sets of inner classes.
>
> >> 1) Inner classes (both static and non-static)
> Completelly agree, especially classes which will be serialized.
>
> >> 2) Usage of generic tuples
> Why or in what cases?
>
> >> Tuples and closures should be replaced with concrete classes, specific
> to your case.
> Can you give an example?
>
> 2017-05-16 13:01 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>:
>
> > Igniters,
> >
> > Ignite is known to be complex product. Partially this complexity comes
> from
> > ... complex problems we are trying to resolve. But partially it comes
> from
> > how we write our code. I noticed several anti-patterns which makes our
> code
> > hard to manage:
> >
> > 1) Inner classes (both static and non-static)
> > 2) Usage of generic tuples
> > 3) Usage of many classes from our "lang"package - closures, predicates,
> > etc..
> >
> > When combined these anti-patterns makes our classes huge, leaky in terms
> of
> > abstractions, hard to follow and refactor. I would like to propose to
> > restrict usages of these constructs as much as possible in non-test code.
> > Classes should be top-level by default, unless "inner" semantics are
> > absolutely necessary or saves a lot of code. Tuples and closures should
> be
> > replaced with concrete classes, specific to your case.
> >
> > Thoughts?
> >
> > Vladimir.
> >
>
>
>
> --
> Best Regards, Vyacheslav
>
