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
