I started discussing this issue with Dmitriy on StackOverflow and would like to continue it here.
Getters and setters exist for a reason. Dumb DTOs are considered an anti-pattern by many - not that much different from C structs. Getters can have logic, and entities can have completely transient calculated fields. E.g. an entity, InsuranceApplication has a List<Person> of applicants, which in turn has a List<String> of phones. I want to find all applications, where the 5th oldest applicant's 3rd phone starts with the area code "310". One could have written a complex (and slow) query to do it at runtime, or have a getter calculating it and cache/store that value with the "query fields" (especially if they are indexed). Essentially those getters are custom SQL functions. We all came from relational databases, but please stop thinking in SQL. Relational tables don't have getters or any object-oriented logic. Smart NoSQL entities do. You don't always need to have a "declared" physical field in NoSQL. What is the issue? Dmitriy pointed out that getters are called repeatedly during serialization and perhaps queries. Their values are never cached and reused. I mitigated it in my framework by caching those fields internally, but you don't want to require programmers to do those tricks, because they'll forget. The less code (at the higher level), the better. Please treat getters as methods, rather than formality to comply with OOP "encapsulation". The same applies to setters, which can have logic and side effects (setting more than one field). -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Calculated-getters-tp1100.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
