OOPhoto - Another Attempt At Learning Object Oriented Programming (OOP) In ColdFusion

Great Ben. Will be following your series on this every step of the way.

@Ben,

One of my earliest hurdles in the whole "grasping of OOP" thing, which Hal definitely helped define for me through his series of Occasional Newsletters, was getting past the data persistence. You are on the right track there: imagine, design, and architect the application without thought to the data. Start with interface and objects. Very difficult for those of us raised on the DB first and the interface to manage it second. If you don't, however, it greatly increases the difficulty of thinking of your objects and their necessary properties and methods as real objects (and not just mirrors of the DB schema).

Once you've got that conception in place, then the DB becomes little more than a mechanical exercise in determining what schema will accurately persist your objects' properties in a way that also offers high performance.

Hey, good luck. One of the things I hope will become bigger in the next release is cfinterface. It's not even useful in the current implementation except in certain introspection cases. They don't even mention it in the devguide...

Right now people use cfargument type="any" to pass in cfcs. We should be using cfargument type="objName"

In normal OO languages, interfaces are huge... but in CF since we can be completely sloppy with our var type declarations, people don't have as much of a use. But for now, remember cfArgument type="interfaceName" will be needed...

Cool Ben, I can't wait to see the project take shape!

~Brad

Ben, if you are interested, once you have your version of this application working, it might be worth putting it up for others to take and implement their own version of the model. I know Hal has problems with ORMs like Transfer because they depend on the database to generate their objects, but they are also the best thing we have at the moment (until we get something like Hibernate that can generate a schema from a domain model). I personally might be game to take a crack at this using Transfer once you have the controller and view done, just to show that in many cases the reduction domain model "purity" may be worth the advantage of not having to hand-code all the queries, factories, and composition relationships. It seems to me that there should be a point where purity is balanced by pragmatism. It might be interesting to see if that is the case here. Thoughts?

I would recommend that you at least follow the service layer pattern to create a stable API to your model. That way it will be easier for me or others to plug in alternate implementations, as well as easy for someone to write alternate UI for it (AJAX or Flex for example). You may already have been planning to do this but I just thought I would mention it.

No REST yet, I just mean that everything the model does is behind a service layer object. So if the controller needs the list of pictures it does something like <cfset pics = getPicService().getPictureList() />. The controller shouldn't be making any queries or calling domain objects directly. Everything should go through the service layer. Make sense?

It's a good practice because it means your controller has no logic other than to handle page flow, and all business logic is kept behind a stable interface. So if you start off running your own queries and I later want to add in Transfer, I only need to change things at the service layer or below and the controller and view should not have to change at all.

Not really, the idea would be to pass the form data into the service layer and let it do "whatever" with it. i.e.

<cfset pic = getPicService().getPicture(form.pictureID) />

This is to enforce encapsulation on the model. That way if you build a Flex UI it can also call the picService and pass in a picture ID. The service doesn't know or care where the picture ID comes from.

No you would indeed either pass the form scope directly or pass it as an argumentCollection. You definitely don't want to be doing anything like that in the controller. Further, if you already have the gallery ID you shouldn't need to manually set the name or description, that would be handled within the model by querying the database or the XML file. The service should be giving you back a fully populated, ready to use object.

This is great stuff Ben, I think you just started a modern day Pet Market application! I am looking forward to the series and to sharing my input.

Also remember that getters and setters are evil (http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html) and that ideally one would never call them at all. In practice one must usually call them when populating an object (unless one uses an ORM and the object is populated automatically by the factory) and when outputting object data for display (which is a strong argument for objects that can render themselves). I personally almost never actually all a getter or setter unless I have an object in a view and I am displaying its properties in a form or something. Every time you call a getter or setter you are drifting away from the real point of OOP, which is to *tell objects what to do*, not to *ask them for data about themselves*. If some code needs to ask an object for its internal data, that is a strong indicator that the logic should be moved into the object itself and the calling code should simply tell the object to do something with the data it already contains.

@Brian,

So, following that train, you would pass in the form scope, which is already a struct anyway, for instance when feeding an update or insert method, but when instantiating an object you would send simply the ID as Ben noted and then let the object's method return what? Ideally, would it return a query or would it return itself with pre-filled properties?

I have always been leery of getters/setters in CF simply because of the overhead, but I haven't always known enough to know why I avoid them.

TIA

Is your javascript going to attempt to be OO as well?

If I were using my own factory and I was creating a new object (it has no ID yet), I would pass the form scope into the service. The service would pass that structure to a factory. The factory would create an instance of the specified object, and loop over the form properties and attempt to call corresponding setters on the object to set the object's state. The factory would return a populated object, which the service would then probably validate and persist (to XML or a database or whatever) using a Gateway object.

That said, having a load() or populate() method on the object itself is also a valid approach. The general idea is not to just pass a structure and then stuff that as instance data into the object, because that bypasses the setters which may contain additional logic beyond simply setting the property on the object. If one is all right with the tradeoff of ensuring that the incoming structure keys can be matched up with the names of setters on the object, it is usually possible to do all of this with a generic method call as I noted above.

I tend to follow the OO tenant to separate object construction from object use, which is why I would recommend using a factory. My approach of looping over the structure keys and calling corresponding setters is a shortcut, but it works in most cases. If the case arises where the structure keys do not match the names of the setters, this generic approach won't work and you'd need a more specific factory that knows how to take the structure and populate the object with it, possibly by calling setters directly rather than looping over the structure. Which is perfectly valid, it just means a bit more work.

@Brian,
I thought I had all this stuff down, but the service/factory/decorator etc. stuff still throws me.

OK, so you would do something like:

form -> service layer -> factory <-> object

the factory then sets everything into the object from the form data that was passed via the service layer.

then, once everything's set/processed

factory -> gateway -> persistence layer

This will be a cool thing to see how you and others implement this in their own way. If I have time to play around I may do this in MachII.

CoolJJ

Yes, you still want getters and setters on your domain objects (and I greatly prefer explicit getters and setters over generic getters and setters, for API clarity). You just want to avoid using them as much as possible. Getters and setters *are* better than directly accessing instance data because you can change or add logic within the getter/setter and not affect the calling code. The real reason to avoid using them where possible is because dipping into an object and asking it for it's data is the top of the slippery slope to procedural programming. Again, where one has code that "needs" instance data from another object, in most cases it is an indication that the calling code should be part of the object being called. I try to keep behavior as close to the data it relies on as possible.

You're arrow diagram is almost what how I would approach it, with a few changes:

form -> service layer -> factory <-> object

after creation, the factory returns the object to the service. So in the service it looks like:

object = getFactory().getInstance(arguments);

Then, to persist, I do something like:

object.validate()
if (object.isValid()) {
getGateway().save(object);
}

or, if you prefer the active-record approach where objects can save themselves:

object.save()

and the object validates itself and saves itself. Which means the domain object would compose a validatorFactory and a gateway, so that it can use those objects to validate itself and save itself.

Make sense? I'm a bit worried that I'm ripping open a can of worms here and making something more complicated than you had intended it to be for your exploration.

Really, as long as you keep model-related logic within the service layer or "below" (meaning a gateway or factory or whatever), I will be able to take your app and modify the implementation within the model without having to worry about the controller or view. That way you can put up your take on things and then I (and anyone else for that matter) might take your version and modify the model, and then give it back for you to compare.

Ouch - my brain hurts having read all the previous comments! I come from a background where the database defines the application so OOP is quite an alien way of thinking (and most databases are RDBMS not an ODBMS).
Good luck with the project Ben and thanks for sharing :)

@Ben, Brian;

May I say I enjoy the exchange you two have going here. I hope the two of you keep this going to the end. This is interesting and educating at the same time.

I stopped reading your blog posts. Almost all of your tutes involve some sort of sexual overtone, some of them are just flat out sexist and I got sick of explaining the racy pics to my female coworkers. "Look... it is tutorial on an advanced topic"... "yeah right".

Seriously. Not cool. And no I am not PC, but I do find a lot of it offending and demeaning to women.

Well, the site *is* called Kinky Solutions. If something is NSFW, I usually just end up checking it out at home. I'm not sure why this specific blog post would warrant your response. This seems to be one of the tamer examples. Plus, I really don't find anything sexist in this blog, just someone who really appreciates the female form :)

I like this! Looking forward to seeing how this app comes together and the input from the community.

@Brian, @Ben:

Using Brian's suggestion, assuming you pass the form scope to the service layer on save...

How do you initially cfparam the form values to begin with? Is cfparam not used? Is it better to do something like this:

try{

if (structKeyExists(FORM, "submit") {
/* save & validate form values */
GalleryService().saveForm(FORM);

} else if (structKeyExists(FORM, "cancel") {
/* Cancel Logic here */

} else {
/* populate the form scope with field values */
GalleryService().initForm(FORM);
}
}
catch(Any e) {
message = e.message;
}

....I think I'm still thinking way too procedurally. I imagine the controller would handle the error message and the cancel logic by using a different event for 'save' vs 'new'. If the save was valid, redirect to another event. If the save failed, reload the form. (The error message could optionally be handled by the standard view using ifDefined("errorMessage")

Would you also have a separate event for a new form vs. a saved form?

So... to cfparam or not to cfparam form vars?

@Dan,

Actually, the need for CFPARAM pretty much disappears if you're requesting and returning a bean to the view layer. In other words, if I open a form to edit a Person, then

personObj.displayFirstName()

will return "Jason", based on the ID passing to the DAO and filling the bean with the Person data, but if I open a form to create a new Person, then the bean will be empty, based on no ID or an invalid ID, and

personObj.displayFirstName()

will return "", which will leave my form field blank, as desired.

As for the action question, I normally do not make my Cancel links part of the form ... just link back to the View or the List or whatever. As for the Create vs Update action, I prefer to call a generic "save" action, and then let the Service determine whether it has a valid incoming ID (= update) or not (= insert).

Just my 2c

good stuff. thanks to all of you for spending so much time hashing this out.

@Ben,

Aha ... I was thinking only in terms of populating the form before submission. You're right that CFPARAM is definitely useful while processing the form submission, especially since strong-typing non-required arguments in object methods can present problems: a blank is a string, not a number or a date, etc. Guess I just read the whole thing backwards, since I often see CFPARAM used at the top of forms to force-populate defaults and so forth.

@Jfish, @Ben,

I entirely agree with Ben: I always use cfparam as a good practice for form submissions - however, I don't know how to populate cfparams at the top of the page without breaking OOP concepts. Unless you can ask the object to create it's own params. I agree with jfish that it would be way easier to display a form if you allowed the object to populate the defaults.

GalleryService().paramForm();
GalleryService().displayForm();

The params could be included within a displayForm call, but you would need to have it separated for processing the form as you wouldn't always need to redisplay the form.

@Ben:

But there's the problem. As the JavaWorld article illustrates, there will be crossover somewhere. Should the view know about the model or the model know how to render the model-relevant portion of the view? Maybe it would be best to have a service layer that builds the object relevant portion of the view depending on the target view (Flex, AJAX, HTML)

If I need to use OOP calls to output each little element of my view, am I getting any benefit of OOP or am I just complicating my procedural way of doing things?

Frankly, I'm not sure. I'm just playing devil's advocate a bit. This discussion is REALLY useful and timely to me. Thanks for putting it out there! :-)

@Ben and Dan,

I don't know that it really impacts OOP in any particular way, right? I think it's just another tool in data validation. Just thinking out loud here, but you push it into the handler, not the form; the form should be simply the 'view' that results from certain events. I'm thinking of an object service, which might be called from your controller 'on save':

[cfset personObj = createObject("component", "cfcs.PersonService").init().save(form)]

Then the relevant method of the PersonService might have your CFPARAM calls, like so:

[cfcomponent displayname="PersonService"]

[cffunction name="save" access="public" returntype="cfcs.Person" output="no"]
[cfargument name="args" type="struct" required="yes"]

[cfset var person = createObject("component", "cfcs.Person").init()]
[cfset var personDAO = createObject("component", "cfcs.PersonDAO").init(request.dsn)]
[cfset var argStruct = arguments.args]
[cfset var rtnMsg = structNew()]

[cfset rtnMsg["success"] = false]

[!--- for args that are optional ---]
[cfparam name="argStruct.personID" default="0"]
[cfparam name="argStruct.email" default=""]
[cfparam name="argStruct.zipCode" default=""]
[!--- and/or for checkboxes, which don't even exist in form scope unless 'true' ---]
[cfparam name="argStruct.isAdmin" default="0"]

[cfset person.setPersonID(argStruct.personID)]
[cfset person.setFirstName(argStruct.firstName)]
[cfset person.setLastName(argStruct.lastName)]
[cfset person.setEmail(argStruct.email)]
[cfset person.setIsAdmin(argStruct.isAdmin)]

[!--- send the bean to the DAO to persist to database ---]
[cfset rtnMsg = personDAO.save(person)]

[cfif not rtnMsg.success]
[cfthrow type="PersonService.save"
message="Error saving person to the database."
detail="#rtnMsg.error#"
]
[/cfif]

[cfreturn person]
[/cffunction]

[/cfcomponent]

Then, in the controller, the resulting 'person' object, now populated, can be used in a review screen or used to repopulate the form, as necessary. Didn't really wire up the error handling, due to time constraints, but you could drive back to the review vs refill form in a number of different ways.

@Ben:

...a further thought:

Am I correct in thinking that only HTML would need to call:
galleryService().displayForm()

Wouldn't Flex use some other method?

I imagine that the controller service could know what type (and source) of the view that was making the calls. Therefore the controller, based on it's own set of rules, could return the appropriately rendered form.

For example, if I had two pages that relied on the same service call, the controller could return different ones if needed. The view shouldn't be making that decision, should it? But it's still a lot for my procedural mind to embrace entirely.

@Dan,

Just saw the display comments ... couldn't agree more. I know that Ray mentioned (above) having the object model handle display, but it makes me edgy.

@Ben,

You are right: the controller handles the communication between Model and View. Those 2 know nothing about each other.

But in any case, we still have the same problem you just outlined: either the View has to know which properties of the bean to call per field ("oh, I'm First Name, so I need person.getFirstName") or else the object in the Model has to know what the view expects ("person.display() will just fill in the [body] of my View for me").

Sticky situation. Any other insights into this from others?

FWIW, several of the MVC frameworks provide a convenience methods that allows you to auto-populate beans from structs (form / URL scopes) by automatically calling a setter for each struct element.

That doesn't help with the multi-object edit page but it removes the need for most of what JFish is suggesting in the service layer.

Controller layer gets an empty bean (from the service layer), populates it from the user data (an event object in most MVC frameworks) and then uses the bean and the service to interact with, to get the operation done.

The difficult part in all of this is figuring out where to draw the line between the view-savvy controller and the model-savvy service layer if you are trying to create a service layer facade that could be reused for different front ends...

@Ben,

One approach I have taken is to have Manager classes that act as proxies to the actual DAO/gateway stuff, and they are smart enough to figure out what needs to be done. The controller passes data from the view to the correct method, and then the Manager decides what needs to happen from there: maybe create 5 movie beans and pass each one separately into the .addMovie(movie) method or pass the form struct to an .addMultipleMovies(form) method. Using Model-Glue, for example, the framework takes care of passing the raw data, since everything gets loaded into an Event which is passed through all parts of the request, and modelglue.xml acts as the controller, announcing which methods get executed during the request, and then determining which view(s) to end up with depending on the method results that were called along the way.

I have pretty much left cfparam behind because it isn't really necessary once you move to an OO approach. The idea being, say you have a User form. The controller will always get a User object and pass it on to the view for display in the form. You don't need cfparam at that point, the object will either have empty/default values for a new User, or the existing User's data, or the data that the user entered into the form but that failed validation within the User object prior to saving. The form doesn't care, all it knows is to call user.getFirstName(), it doesn't care whether that property is an empty string, or the existing user's name, or the value that the user just submitted.

Ben, I'm not sure I follow that. You're saying there is a "confirm" checkbox that actually doesn't do anything or isn't used in the model? Most systems I've dealt with that have, say, a "I have read the terms and conditions" checkbox is persisted in the model. I just can't think of a reason one would want a checkbox that actually was meaningless...if anything, wouldn't that be *against* usability rather than helpful?

Ben, it is great seeing you tackle this again. I hope you are more successful this time. I will definitely keep tabs here and chime in with any comments. This already has me thinking a lot about how I'm approaching things. A great read! Keep it up!

I suppose that in my opinion, if a checkbox like "I read the terms and conditions" is a business rule that must be enforced, then I wouldn't call its persistence redundant. But the issue isn't really whether that is saved to the database or not.

I wouldn't say that having fields like "confirmedPassword" or "confirmedEmail" in a User object is somehow a problem. Even if those properties aren't actually persisted, the whole point of the object is represent a useful abstraction. There's no rule that says every piece of information in an object has to end up in a database. If your use case requires an isConfirmed() method, or a confirmedPassword property, then by all means, use it. Assuming that one has a validate() method that would detect things like "passwords don't match", the object *has* to have those properties anyway, for the validation to be worth anything.

Let me respectfully disagree with my friend, Brian. It's not that what he's saying is wrong; it's that it's not terribly helpful to someone learning OO. It's premature.

I'd suggest you forgot about Transfer, service layers, factories, and AOP -- for now. You'll have time to integrate all that (minus Transfer, of course!) later but for now, the danger is that you'll be overwhelmed and not learn OO at all.

One eats an elephant a bite at a time, or so experienced elephant-eaters tell me.

I definitely agree Hal. A while back up in the comments I had said:

"I'm a bit worried that I'm ripping open a can of worms here and making something more complicated than you had intended it to be for your exploration."

So what you're thinking is the same as what I was worrying about. I agree that ORM shouldn't be a concern (I'm pretty sure I didn't mention Transfer but someone may have, its been a long thread).

I do think the advice to keep a stable boundary around the model by means of a Service layer would be worth attempting, but everything else can come later, as Hal points out. The only reason I say keep the Service layer is because it makes other refactorings so much easier because the changes are mostly limited to the Model. Which means you can try out all sorts of crazy ideas without making changes to your Controller or View.

Ahh I did mention that I might add Transfer to a version of his Photo app after he puts it out there, just to show how it might work! Blogs aren't great for long discussions heh.

Cool. I already want it. Thanks for posting