Martijn Dashorst <martijn.dashorst <at> gmail.com> writes:
> Like it or not, propertymodels already break encapsulation, the law of
> demeter and refactoring without having to resort to private accessors.
> So if you go all OO, these things should never be used, especially
> since there is a perfect OO alternative:
When using PropertyModel, one does sacrifice static type checking for
better expressive power (using a property name instead of getObject()
plus setObject()). However, the point is that this kind of tradeoff
is not uncommon. For example, regular expression gives us expressive
power, but at the same time we lose static type checking (compare
the regular expression "a{3,5}" to its type safe equivalent
"new Repeat(new Atom("a"), 3, 5)").
In contrast, directly accessing the private fields of a class in order
to save the work of generating the accessors is not a tradeoff that
I've seen any where.
> According to the best of my knowledge this was implemented because of
> speed. Instead of having to search through methods hooking into the
> fields saves quite some time.
For a Java bean class, most likely every field is to be read sooner
or later. According to this argument of speed, we should simply
use public fields for all Java bean classes? As I said before, I
don't see why Wicket code is in a special position to have this
access, while other code (eg, domain code) using that Java bean
class shouldn't.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
