Calculated getters

classic Classic list List threaded Threaded
2 messages Options
Alex Rogachevsky Alex Rogachevsky
Reply | Threaded
Open this post in threaded view
|

Calculated getters

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).
Sergi Vladykin Sergi Vladykin
Reply | Threaded
Open this post in threaded view
|

Re: Calculated getters

So what is your problem? Sorry, I don't understand it from your email..

Sergi

2015-08-22 5:48 GMT+03:00 Alex Rogachevsky <[hidden email]>:
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.