Ben Nadel offers some comfort, from 2008, and a very articulate, substantive discussion regarding the value of OOP in Coldfusion. I'm not up-to-date on where his mindset has evovled to in the past 3 years, but some very knowledgeable people have spoken up against pure OOP, and I feel like the distinction between data display versus behaviors hits the nail on the head.
http://www.bennadel.com/blog/1385-Object-Oriented-Programming-And-ColdFusion-What-s-The-Point-.htm
It feels good to have concrete validation of what I have been so dyspepsic over, instead of feeling like a boy crying wolf all the time.
But how to integrate the two worlds? Recently, I've found that working with value objects can do some good, not only in instances where the data has associated behaviors either, but also when the models are used in various places throughout the site, and you want one consistent access mechanism, but are not using the same data access routines (i.e. stored procedure calls) to populate the value objects each time.
We work on a reporting site for a "sporting" organization. You can build reports based on different players in the sport. So taking to heart the concept of encapsulate what varies (I think that's how it goes), a report is an abstract concept that has an abstract concept of subject. We have 3 main types of subjects currently in our app, and about 100 or so different reports. People can build lists of favorite subjects in the sport, but they don't always know the specifics of the player, and may need to distinguish between one or more player who share the same name or other details... So there is a search interface that might return more than one subject. So that is at least 3 different places where I need to deal with subjects in the application: reports, search results, and favorites lists.
In this case, setting up an interface that represents what all the subjects have in common, which isn't much (an ID, a subject type, a subject name/means of identification), allows me to create a contract between the lower, less specialized/more generalized parts of the site and the specific details of both a given subject and a report. A page is always a page, but if a page is a report, then I know I have access to a subject and to that subjects type, ID, and name--onrequeststart and the site header doesn't any longer have to determine who the subject is based on the what report is being requested and build a name for each different subject based on the various pieces of data needed for identifying it.
Additionally, when I populate a subject for a report, 99% of the data is the same as when I populate it for a favorites list or for search results, but sometimes there is more or less data about the subject depending on the context. Additionally, since we try to limit trips to the database, sprocs might be composites of more than one sproc, in which I return the base data, as well as the stuff unique to this context all in one shot. Having a SubjectService provides one common interface to populating the subject value objects with as much, or as little data as needed.
So all in all, OOP has worked out exceptionally well for me in the last few months that I have really started trying to use it based on best practices and design conventions. But last week, for some reason I started to really take it all too far and try to push everything into value objects, because, well, everything should be done consistently. Truth be told, starting out with this stuff, when an approach isn't sitting right with me, instead of trusting my 12 years of experience as a programmer, I figure I must be doing something wrong, not getting it, etc... Then I do a 180 and think "no, I'm not going to let all this new-fangled shiny codes the kids are into nowadays undercut my august skills." Anyway, seeing experts in the community struggle with the same thing is reassuring.
No comments:
Post a Comment