Ask Ben: Working With Lists In An Object Oriented Programming Application

I think this is what you need, but I'm actually just some jerk who may have no clue what the hell he's doing and all...

First, make sure you are using a framework which loads your object CFCs into the application scope (i believe most of them do). I think that would speed up object creation.

Second, separate DB calls into a separate CFC. (Eventually you should break these into CRUD and Gateway, but one step at a time). They should also be in application scope.

You have two choices for the Read operation: One function that always returns an array of objects or two functions, one to return a single object, the other to return an array of objects. Honestly, it doesnt matter (unless you want to really start developing true integration with Flex and display models... then it just gets easier to always return an array..)

So you mentioned you are not doing a flat DB query. i.e. you would need to call data from multiple tables to fill your needs. Just do it. Write a query that gets all your data sorted by object. So, if you had to get all clients and their addresses (and there could be >1 address per client), then grab the whole thing, ordered by client, address (with joins and where clauses of course).

Also, I'm assuming in your client object, you'd have an array to store the addresses (so it's an array of address Objects which defaults to ArrayNew(1)).

Then you loop through your query and group the loop statement by the sorted objects (i use cfoutput instead of cfloop because it's easier to loop inside queries you are already looping through... if that makes sense). In this example, I'm assuming you have a function in your cfc called init which returns 'this' (the variable).

<pre>

<cfset var clients = arrayNew(1)/>
<cfset var tmpClient = ""/>
<cfset var tmpAddress = ""/>

<!--- loop through each row grouped by client --->
<cfoutput query="q" group="clientId">

<!--- create client object --->
<cfset tmpClient = createObject("component", "beans.clientBean").init(
firstname = q.firstname,
lastname = q.lastname,
etc = q.etc
) />

<!--- loop through addresses from DB --->
<cfoutout>

<!--- create this address --->
<cfset tmpAddress = createObject("component", "beans.address").init(
city = q.city,
state = q.state
soForth = q.soForth
) />

<!--- attach this address to the client object --->
<cfset ArrayAppend(tmpClient.address, tmpAddress) />

</cfoutput>

<!--- finished sublooping, now add the client to array --->
<cfset ArrayAppend(clients, tmpClient) />

</cfoutput>

<cfreturn clients />

</pre>

if any of this shows up wrong, i apologize... (Ben, make the comments box wider and taller, will ya? maybe a nice widget from the YUI library or something that floats the text box in an expanding container?).

Here's the key, this code COULD be right under your query in your CRUD cfc. OR, since you may be doing multiple Read queries based on different where clauses (but with the same Select statement) you can make this a separate function that is call if needed before returning the array of objects.

Just a few notes... you should have getters and setters for each property of the bean. Also, you can create functions in the bean to add and remove items from each Array of Objects. So you would ideally have "addAddress" as a method (in the bean) and you would use <cfset tmpClient.addAddress(tmpAddress) /> to add the address to the client object.

OK, that was my longest post anywhere for a while. I hope this helps!

One thing to keep in mind when tackling collections of objects, is that size does matter, and even in OO languages other than CFML (i.e. - Java, C#, Ruby, etc.), you probably won't find yourself creating a collection with 1000+ objects, at least I don't, and I work on some fairly large systems. It's just not performant.

The representation of data as an object is really only useful when behavior is associated with that object through methods, events, etc. If you're simply using an object as the equivalent of a struct (Value Object pattern), you really don't gain much of a benefit in this case. That being said, when trying to show a list of members in a collection, especially with gobs of members, you really are solving a reporting problem. When dealing with reports in an OOP mindset, the report itself can be considered your object and the data associated with that report is a property of that object. Since CF has a native datatype for query, this is usually a great datatype for the property of your report object. To render the report, based on how you like to architect your software, the report object would have a render method, or you could have something else render it, which would produce the list you want to show to your user.

Using the report-like objects does become tedious however when you start to use CRUD-based tools and scaffolding. In these cases, I found it more useful to look into using things like paging to reduce the size of the collection you have to deal with or, if performance isn't an issue, just don't worry about it at all.

In the end my take is, if the user wants to see 1000+ members in a collection, it's probably because they want to look at it from a reporting perspective and your object model should reflect that. If they want to find a member in a collection, the user would rather have good UI tools to help them find that member, rather than see a list of all 1000+ members.

Just my thoughts, feel free to brandish me now :'(

Ben, what if you needed to output your IBO like a <cfoutput query="myqry" group="bff_name"> #bff_name# <cfoutput> rest of query </cfoutput></cfoutput> ?

@Brad:
What Ben said +1. I think you've really hit on something there that could help a lot of us struggling with OO in CF. Squillions of objects in a collection = reporting = different domain - nice!

I just want to point out (and getting away from what the OP was asking) that sometimes the fact that an object is in a collection is important, even if we don't care right now about the other objects in the collection. The collection may be a business object in its own right with its own business rules , and where we are dealing with collections of value objects or of strictly composed child objects, the object lifecycle will be controlled by the parent object via the collection.

The actual implementation of these ideas in CF may end up not looking much like what I've described above, but I find it handy to keep the principle in view.

@Ben, Jaime - To add to that, consider the example of a populated collection of User objects. What's to say you don't create an object called Group which is a derivation, or abstraction, of a List-like collection. You can give the object Group behaviors like bulkAddPermission(). Search is another great example of where custom collections are nice. Consider paging being a behavior of a SearchResults collection for objects of type SearchResult. SearchResults could abstract paging from the DB in a getPage() method, or be greedy and cache a large dataset internally for querying later. By using an object for SearchResults, the behavior of paging is encapsulated and closely associated with its semantics.

A lot of people have a different approach to software design but the way I figure, keep it simple by building for the basics. Use objects to emulate the problem domain you have to solve, don't just come up with a solution to solve the problem at hand. The customer will always help you grow your application from there :) The closer you emulate their problem domain with your software, the more flexible your software will surprisingly become to maintain and enhance. Again just my take on it.

As always great post Ben, keep up the great work.