OOPhoto - Modeling The Domain In Steps (Round I)

@Ben

Don't be afraid of the ColdFusion query type!!! I see this all the time when people start off, where they want to return arrays of objects.

The CF Query type is very powerful, wicked fast, scalable, and the best way to return large sets of records.

This is the reason, for instance, that the Transfer ORM returns a query from list() methods, and a CFC from get() methods.

Yes we can create Iterators (like the IBO), and sure they're useful, but go down that route only when absolutely necessary.

One of the major advantages to CF is cfquery and the query type. There's no reason to abandon that if you start going OO, else we're really nothing more than Java Lite. :(

Well, I'm more of a noob to OOP than you are so I'll phrase my comments as questions, that way they are easier to ignore. : )

Should the service layer be broader and more abstract? Maybe a single "Photography" service rather than a gallery and photo and comment services? These don't seem like a service layer, but more like abstract domain objects that are being extended by the concrete gallery, photo, and comment objects.

Also, perhaps since the get and set methods will be generic (not sure that is the right term) should they exist once in the single service layer rather than in each object?

Should the methods you have in your service objects actually be pushed deeper into the business (domain) objects? For example the getByID in the photo service actually be accessed as Photography().Photo().getByID().

Very curious to see how this turns out...

Ben,

A few general comments.

1) You are using 'get' an awful lot in your method names which is often a symptom of looking at your objects as nothing more than data. Object Orientation is more about modeling behaviour than about getting data. From looking at your initial spec, it looks like in some cases the more appropriate noun is load and in others it is find. It might be a point to consider what the true behaviour of your method is.

2) I am not a big fan of the getById method. Another way to do this would be to make a find() function that takes a filter object. The filter object would be a bean that takes parameters and provides intelligence on what is being used for criteria.

The advantage here is that when you implement a 'tags' functionality and you want to provide a method to get the photos for a specific tag, you can simply edit your filter object and whichever consumers of the filter object need to know about the tags. Thus keeping your service layer intact and preventing an explosion of methods everytime you wish to open up another functionality for finding a photo.

Here is an example of a filter object I happen to have on disk.

http://cfm.pastebin.com/f41d04cbb

3) Your generic functions 'get' and 'set' are a little indirect. Proper OO is about building a sensible contract between objects. Using a generic set and get really eliminates that contract and can make working in team environments much harder. Where does the property list go? Since the object can theoretically accept any piece of data, who knows what can be requested from that object? is it documented somewhere? Who maintains the documentation? Are they really doing it? etc...

Using methods gives an easy way to add behaviour to your objects. Lets look at a simple example:

http://cfm.pastebin.com/f6a759557

see the methods at the top? getFormattedSavingsPercent, calculateSavings, getFormattedDiscPrice and so on? This is much better implemented using methods, than the generic get or set. else there is a million places that reference the key to the generic get that can be hard to debug when something isn't working. Most implementations of generic get return an empty string when the key passed isn't found. While sensible, it turns the work back to the programmer to understand the data and know whether that is appropriate or not for the circumstances. Maybe easier done in development where the data is controlled, than in production once the data grows and represents real world situations.

Anyways, this is food for thought. There are many paths to greatness and there are many ways of feline depilation. :)

Dan Wilson

Dan has some interesting points, but the idea here is to learn for yourself and try things out. Don't be too concerned with what I, or Dan, or about anyone else says about your experiment. I mean, if someone sees something that is absolutely going down a bad path, we should mention it and let you consider it. But overall, part of learning OO (at least for me) was and still is trying things out and seeing what works and what doesn't.

I don't have too much of a problem with methods that have "get" in them. Sure, if loadX() or findY() makes sense, go right ahead. But as long as the method is, at its heart, about having the object DO something, I'm less concerned with the method name. getByID() or find() or findByID() all reveal the intent of the method. Use whatever works for you, as long as it is clear.

I do have to go with Dan on the aversion to generic get() and set() methods. This is a topic where some people love them and some people don't, and I definitely don't. The problem is that if one were to look at the API for, say, your Photo object, they would have absolutely no idea what properties to specify for the get() and set() calls. get('cthulhu')? set('foo', 42)? If you want to keep things dynamically typed that's fine, but it is so trivial to write, or more likely generate with a snippet or a bean creator, the getters and setters that I just don't see any reason not to do so.

Even though we want to avoid using getters and setters as much as we can, the bottom line is that something, somewhere has to know what it can set or get from the object. At minimum, to populate it, and probably to display it in a page or a form. From an API standpoint, set() tells me nothing, but setDateCreated() tells me everything. If one goes too far down this path, one could envision a single AnyObject that only has a get() and set() method and that can hold anything. Again, just my opinion, and others may weigh in since this topic makes the rounds on blogs and message lists with some frequency. But my advice would be to just write the getters and setters.

Overall I think what you've laid out looks very good. Keep it up!

Of course by the end of that comment I forgot my own advice from the beginning of it. If you really feel like trying out the generic get() and set() approach, by all means try it out. That way you can see for yourself if you prefer it or not!

Regarding the question early in the post about leaving any kind of "sort column" out of the photo object model, it seems right to me that you should leave it out as you're currently planning. That piece of data would only come into play when dealing with multiple objects, whether you're just returning an array of the objects based on the sort order or altering the sort order (which requires altering more than one single sort order value).

To be honest, I think generic get/set are just fine as long as they match up to cfproperty or documentation. As I've pointed out before they're used quite extensively in Objective-C and Cocoa (under the name KVC) which has been around for ages before modern Java, DAOs, and any of this other "OO" nonsense. ;)

[person valueForKey:@"name"];
[person setValue:@"Elliott" forKey:@"name"];

These of course either directly access instance members or call the send "name" or "setName:" messages to the objects.

Of course these throw exceptions if the key doesn't exist.

I'm personally a huge fan of generic get/set in the sense that it saves typing code, and also allows much more dynamic access later (without resorting to cfinvoke/ isCustomFunction combinations).

However, I think returning an empty string on an object is a bad idea. The way I implement such functions is that they throw exceptions if the property doesn't exist, as an object shouldn't be regarded as just a "struct" with arbitrary properties. Of course something like a facade is a different matter, in those cases I use get/set that throws an exception, or returns a default value passed as the argument.

sessionFacade = ...;
sessionFacade.get("SomeKey",defaultValue);
sessionFacade.get("SomeKey"); // exception!

An even more powerful aside to this is KVO which is Key Value Observing. There's two ways we can do this. If we always require users of the API to use get() and set() then when some internal property changes we can broadcast events about different properties changing. If, however, we don't use get/set then we need to sprinkle KVO event broadcasting all over the API. OnMethodMissing can kind of solve this, but it also breaks typed arguments and return types.

Both of these ideas have been around for a really really long time, and are tried and tested in OS X, NeXT, GNUStep, and WebObjects software everywhere.

(Note WebObjects is written in Java now and is still using KVC)

http://www.macresearch.org/cocoa_for_scientists_part_xi_the_value_in_keys
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/KeyValueCoding.html
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html

Anyway, without rehashing this age old argument over and over again, I want to put it out there that this is not some kind of cardinal sin of OO design, in fact, it's quite common in some places. You decide if you want to use it or not, but don't listen to anyone telling you that it's somehow inherently wrong. :)

Ben, sorry for the topic that may be drifting away from the real point of the blog entry. Feel free to tell me to stay on topic and I will, I swear! Just say the word and I can take this debate over to my blog. ;-)

Elliot, I don't really see how what you're talking about lines up with how CF does things though. There's no way to enforce a type using CFProperty; what if I call set('age', 'foo')? There are ways to try to detect this but the get() call starts getting very complicated. You'd have to get the metadata for the CFC, look at the properties, find the matching one, look at the type, and confirm that the type matches what was passed.

Also, the CFProperty tags do nothing in terms of API. Looking at a CFC's interface (for example, using cfdump), even with the CFProperty tags in place, I still have no idea what I can and can't pass to the generic methods. I'd have to physically open it up or do a getMetaData() call on it to figure anything out.

The same goes for custom logic. The generic set or get has no easy way to actually apply additional logic to it beyond just setting or retrieving the value. At that point you'd need to add a custom getter or setter, and have the generic method look for an existing one and call it instead of handling the call. Which makes the generic methods even more complicated, and you still have to write the custom method as well as the cfproperty tags.

Things seem to get out of hand very quickly. By the time one has written all the cfproperty tags as well as the logic to handle the generic get and set methods, they could have written the actual getters and setters and have moved on. And given how utterly trivial it is to generate getters and setters at a single keystroke or with a bean generator tool, the argument about saving typing just doesn't hold water with me. I can generate a bean, even one that has 100 properties, in just a few seconds.

As for dynamic access, writing an invokeMethod() method is just a few lines of code and you have all the dynamic access you'll need. I use this often.

regards,

Brian

...this is straying from the main point, so I'll keep this short. The prior comment about 'Java lite' caught my attention.

What are the actual benefits of Coldfusion over Java that we should embrace on these OO projects to not only avoid 'Java lite', but truly get the best of both languages? Once upon a time the benefits were clear to me, but lately there's been a lot of effort to use Coldfusion as if it were Java so it's getting murky in my mind. The "Query" point above makes sense as it's a really great feature.

Hopefully, when you complete this adventure in OO you'll have a much clearer understanding of what works from each camp.

Thanks for blogging this project. It's making me think. :-)

@Ben, to me the idea of throwing an error if an invalid property is requested is just one more strike against the idea. If you want to be able to handle the error and keep going, now you'd have to wrap all of your calls to set() or get() in try/catch blocks, right? Thoughts? Is that a concern to you or are you coming from the standpoint that this would be revealed in unit testing?

@Brian

This is no different than the runtime exception thrown when getFooBar() doesn't exist.

obj.get("FooBar")
obj.getFooBar()

both fail in the exact same way, at runtime with an exception.

Do you wrap every single call to a getter and setter with a try/catch in case that object doesn't have the method?

Both are also susceptible to the exact same typo bugs.

If we were to dynamically invoke a getter...

obj.invokeMethod("get" & arguments.property);

this will fail in the same manner as:

obj.get(arguments.property);

Generic get/set are really not that different than the explicit get/set in any usage context. Documentation, maybe, but in terms of usage, not really.

Clearly I don't wrap all method calls with try/catch blocks, but I would argue that calling a method that doesn't exist would be less likely than calling get() and passing in an invalid property name. But the difference isn't very big and this is what unit tests are for.

Something else to think about: If (or when) we get an IDE that supports true code completion, everyone with generic methods is probably going to think hard about switching back to explicit methods. I hope that Adobe will give us this in a CF IDE and if they do, that it isn't far away.

It's true that using a dynamic method invoker could also generate an exception if an invalid dynamic property name were passed into it, but the difference there would be that the error trapping would be localized to one place (the invokeMethod() method).

I'm not an OO programmer either, so I'm just guessing as to the best approach.

If the idea is to think of objects as "sets of behaviors" rather than "sets of data", then the Sort aspect wouldn't be part of the Photo object because the Photo can't sort itself: the Photo has no sorting behavior. So the sorting would have to be handled by something else, probably either the PhotoGallery object or (more likely) the PhotoGalleryService.

How exactly you would want to go about doing it, though, is unclear to me. While that "service.commit" example you gave does seem a bit "forced" at first glance, it does seem to be one valid way of going about it.

I thought you were going to hold off on the sorting options for version 2? I mean, for this version, you could just return the array of photos in whatever order the database gave them to you (which would probably be roughly chronological order).

I just meant that I understood why you felt odd about the idea of passing a sort value along with the Photo object to your Service.commit() function (rather than having that sort value somewhere in the Photo object already).

It certainly seems to me that that method would work and I can't think of anything wrong with it, but again not being an OO programmer there may well be some existing design pattern that might be better.

Just ran across your interesting OOP blog so I'm a little late to this discussion. Well, maybe really late;>)

"I don't believe in using UUIDs as identifiers." This brings up the question of how you prevent someone using the back button on their browser and creating multiple galleries, instead of updating the current gallery. I know how I would prevent this using a UUID, but not with an auto-incrementing PK.

Any thoughts on how to prevent "back button duplication"?

Doug