James Perkins skrev:
Hello All,
I realize this article is kind of old, but I found it interesting none the

I just can't figure out how you can get around getters and setters. I
understand it makes more sense to build a method to calculate a discount or
something like that, but what I don't understand is how you create an object
based on data from a database?
I think the title is badly chosen.

As far as I can see he is arguing for two things:

1) Methods should be declared to return _interfaces_, not classes. Then the methods creates an object of a class which implements the interface. The interface can remain unchanged, while the chosen class may be changed as needed.

Example: "public List getResults()" versus "public ArrayList getResults()".

The first one defines the return type to be an interface where any particular implemention may be chosen - ArrayList, SortedList, etc.. The caller doesn't care and doesn't need to know. The second one defines the return type to be an ArrayList, and nothing else will do (except a subclass). This is inflexible and freezes the ArrayList type in perpetuity.

2) Work should be done by the responsible object holding the necessary data, and not by pulling all the data out of the objects with getters in a method in a different object and setting the result back in a third object.

So you would not do something like.

invoice. setDeliveryCity(recipient.getCity());
but something like


where the setAddressFromRecipient method knows about the details of the invoice address, and knows how to get the address from a person.

The appropriate location is the object who knows the best (I cannot remember the pattern name for it :( ).

The database row can be reasonably handled as a Map. It is very tedious to build a custom class with getters and setters for each field (requires to build up a bytecode representation and get a classloader to create it) but it can be done.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.