Hey Steve,
Long time no chat! Hope you're doing well?
OK, trivial example, I get firstName and lastName back and I want to display
fullName. If I don't have an object where I can put a getFullName() method, I
have to either iterate over the query in a service class to preprocess or
duplicate the #firstName# #lastName# code in every view which is fine until I
want to add middleInitial to everywhere I display the full name and then
becomes a PiTA in terms of maintenance.
Of course, if all we ever did was to display a fullName, this would be
overkill, but I find complexity usually grows. For example, I have a location
object in a current app. You enter an address, but you can call location.lat
and location.lng which return the lat and lng. Inside the location bean you
have:
def lat
if(!...@lat)
latlng = GeoKit::Geocoders::GoogleGeocoder.geocode("#{self.full_address}")
self.lat = latlng.lat
self.lng = latlng.lng
end
latlng.lat
end
It's ruby code, but you get the idea. I'm populating the latlng from a Google
geocoding lookup. The alternative approach of pre-processing your query to
populate all of the lats and longs works, but the more calculated properties
you have, the more complex and difficult to maintain those pre-processing
routines become.
Such preprocessing routines also violate (to me) the single responsibility
principle. Sure, they are responsible for "preprocessing the query to generate
calculated values", but that's a big responsibility that could include
concatenating fields, pulling from third party web services and who knows what
else to create the fully populated queries with all of the calculated
properties.
I just default to objects with smart getters and seldom find myself regretting
it.
Also much easier to unit test the calculations.
Best Wishes,
Peter
On Jan 7, 2011, at 3:25 PM, Steve Bryant wrote:
> Peter,
>
> Would you mind expanding on that a bit? How does the use of a query prevent
> encapsulation? I realize that the data is read-only, but that doesn't mean
> that the code that produced it wasn't well-encapsulated.
>
> Or am I missing something fundamental?
>
> Thanks,
>
> Steve
>
> On 1/7/2011 1:31 PM, Peter Bell wrote:
>> Well, I certainly wouldn't use a query object. I'm not a fan as there is no
>> possibility of encapsulation of any possibly business logic.
>
> --
> You received this message because you are subscribed to the Google Groups
> "CFCDev" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/cfcdev?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en.
