OOPhoto - If Object.Validate(), Why Not Object.Save()?

"You may think I am making too big a deal of such a small decision, but really it is quite appropriate."

I've read, listened to, and talked to more than a few very skilled application architects that would disagree with the notion that this is making a lot out of a small decision.

Or that this is a small decision.

I would consider the Wikipedia article on "syntax sugar"

http://en.wikipedia.org/wiki/Syntactic_sugar

I tend to look for solutions that generally follow that model of building a quick "high level" method, like obj.save() through the use of "intelligent defaults" with "low level" methods underneath. The idea is to provide methods of writing concise code without giving up any of the flexibility offered by the verbose alternative.

I struggled with these very same issues in my journey into OOP and the answer is (of course) "it depends." The object.save() idiom is popular in other languages (see "active record pattern"). For CRUD apps (which most essentially are), it's probably fine. The use of a service layer is a "J2EE enterprise" pattern, and a lot of communities outside of Java and CF get on fine without them apparently. Are they "less OO" for it? I don't think so (but I'm no expert). Check out this comment by Elliott Sprehn on Brian Kotek's blog:
http://www.briankotek.com/blog/index.cfm/2008/7/16/UML-Diagram-of-My-General-Model-Structure#cC222FBDC-3048-C277-11FD46BBED32C2D0

Your gut tells you to put the Save function in a service object, not your bean object because you know that you may save the same data in multiple ways (xml, database, rss), and you may want to change how the data is saved at run-time (eg. in response to user preferences).

I'd suggest treating your validate function in the same way:
- you may want to validate the data in multiple ways, against different rules depending on what you are currenlty doing with the data (e.g. allowed characters for a specific data base, vs. correct numeric percision to meet a business need).
- you may want to reuse the rules for different data sets
- you may want to change which rule are applied at run-time. (Strategy pattern)

Ben, just because you have a convenience method where you can ask an object to persist itself doesn't mean that the object "knows" about how to persist itself. What you have here is two ways to do the same thing:

user.save();
or
gateway.save(user);

Because internally the user will be calling other objects (like a service or an ORM) to actually perform the save, these are virtually identical. The main benefit to being able to ask the object to persist itself is the level of control you have. If the object itself has control when you call user.save(), it means you have have your own logic there if necessary. This can be harder to do if you go the gateway.save(user) route. So I prefer to be able to call save() on the object. Not because I think one syntax is really superior on its own, but just because of the level of control it offers.

And again, none of this is really going against OO theory. Objects are indeed supposed to be idealized versions of things. What is wrong with asking an object to persist itself? The object doesn't know HOW or WHERE it is persisting itself. It could be an XML file, a database, a remote web service call, a RAM disk....who cares? Certainly not the object.

Its the same if you were to ask an object to render itself. The object itself doesn't know about HTML. It just knows that something configured it with a renderFactory or something, and that it will pass itself into that to actually do the rendering.

"Bob, here's your address. Is it valid?"
"Yes."
"Bob, persist yourself somewhere!"
"OK."
"Bob, render a summary of yourself."
"Happy to."

Nothing wrong here! :-)

Ben,

As I'm looking at what you're saying, I see your point about Problem.Solve(). But isn't that typically because you *think* about problems? Typically, you have to apply outside information (how to detect relevant information, formulas to use, etc.) for that to happen. In my mind, Object.Save() is completely internal - it doesn't have to have any information about how to go about saving; it's just saying "Okay, put myself into some sort of box here."

(I'm now looking at this and asking if it makes sense - I'm not quite sure. What's your opinion?)

I konw that I personally am a fan of the object knowing how to persist itself in most situations, though I'm sure that there can be other situations that a service object to persist another object would be preferable. That being said, I tend to have my objects understand how to persist themselves to the application's storage medium.

As for the comment about "database, xml, rss", in this case I call that transformation. All of my objects support reflection, enabling me to transform a given object, and it's state, at any time necessary.

Okay, that makes sense, I think. I'm getting the picture of an object kind of floating along, chanting, "I'm chocolate ice cream, I'm chocolate ice cream!" All the while, there's a Service Monster hanging over it, saying "Feed Me!" and waiting for the object to give it chocolate ice cream. :-)

But by the same token that the object knows all about itself, doesn't it also have to know that it can be persisted/validated/saved?

Ben when you say "Hey, do I already have a tub of this at home?" "Should I be buying another", I think you're asking the wrong question, because in that case you're talking about two different instances of two different objects (homeIceCream vs. storeIceCream).

With a User, we're talking about the same instance (let's pretend for a moment that the objects exist in memory forever). So if I say "Bob do you contain valid state?", that is a valid question and I think it's perfectly fine to expect Bob to be able to answer that question.

Back to the ice cream example, even there I don't think what you're talking about is validation, but rather exposing object behavior. If I have a Product object and I say "Hey Book, has the user already purchased a copy of you?", again I think an idealized Book would be able to answer that question! It definitely would mean that internally the Book would probably go ask a Service to check for an existing purchase from that user, etc. But the key here is just adding useful behavior to the object. If it makes things easier to be able to ask a Book if the user already bought a copy, then by all means, make it so! book.alreadyPurchased() is a perfectly acceptable thing to ask a book if your application benefits! :-)

That's true. Idealized really equates to usefulness. Consider:

Should I be able to ask a user object if their user name is already in use? I would say it's certainly fine.

I heard this one somewhere and thought it was very interesting. Consider a ClassRoom object and a Student object. In the real world, if the Students don't know where their next class is, some other object, maybe a Teacher or a SchoolMap object, would have to be asked about directions to the next class for every Student to tell them where to go. This would be a procedural approach. But in OO land, there's no problem saying student.goToNextClass() and have the Student be able to determine themselves how to do that.

This is done in real life all the time. As I understand it, places like UPS have very robust object models where a Package determines the best route for it to take to get to a customer. This involves all sorts of game theory and decision trees, where things like available space, package shipping level, cost, mode of transportation, etc. all play into the determination. Each package essentially "bids" on ways to get where it needs to go, and whatever route is the cheapest and meets the needs of that package wins. Clearly in real life a Package can't do any of this, but we're talking about the ideal Package. It doesn't get much better than saying "Package, figure out the best way to get where you need to go and then go there"!

I'm certainly not an expert - but I'd say that an "idealized" object is one that simply does what we need it to do. (which may vary between applications) Which means that, provided we've thought hard enough about what the objects really need to do, we're not "guessing" about what an idealized object is - we've validated our understanding of the object's functionality enough that we don't have to assume that our ideas are beneficial, we know they are.

A book can't, in the real world, know that you already have a copy of it at home. And, for some applications (a bookstore inventory program, for example), an idealized Book (a Book object) wouldn't need to know that. But for another program, the ideal Book might be one that knew whether you had a copy of it or not. Perhaps the difficulty is in the belief that you can have an objectively idealized Book, rather than a Book that is idealized for a given purpose?

Just random thoughts.

I think Brian's point Bob is basically correct (even though that's not how I currently program). Basically, as far as objects go, we can pretend that they have an inkling of an idea that they can be rendered, validated, and persisted.

Sure, they don't know anything about HOW they get rendered, validated, or persisted. But when they were created, they were handed a persistence service object (or maybe, later on, a new persistence object was handed to them), and they just save themselves using that service layer. You swap out these services based on the strategy pattern (or at least, the way I understand the strategy pattern) as needed.

I remember this was a discussion Hal Helms was having a long time ago, about whether an object could display itself. It's something he wanted to try to do, but felt that conventional OO logic was against him.

One of the questions we also have to ask, is -- does choice of language matter? Is it easier in one language to pass the object off to a service layer vs. having an internal persistence call, or does it not really make any difference in terms of construction.

I'm interested to see the ongoing conversation surrounding this.

Uh, guess that should be "Brian's point about Bob". Sorry.

Ben, I think that maybe you're asking two different questions, and rolling them into one is getting confusing.

The first question is, "What do I want my object to be able to do?" Technically, that corresponds to, "What do I want in my object's API?"

It sounds like you'd like to be able to ask an object to save itself, by calling myObject.save(), so save() should be part of the object's API.

The second question is, "How should that behaviour be implemented?", meaning exactly where should the code to do the save be located. You could choose to write that code in the object itself, allowing it to talk to an ORM for example, or you could implement it elsewhere (e.g., in a gateway) and then inject the gateway into the object. The choice is up to you.

So really, those two questions can be asked and answered independently, giving you your cake and allowing you to eat it too. At least that's how it seems to me.

Bob

The object doesn't have to know anything about saving itself - it just has to know exactly where to find that information, or, where to pass itself to complete the requested operation.

I've found a good way to handle this is to pass in, via the object service, a pointer to your DAO to every instance of the object, and set that pointer as an instance variable. So in the object bean, you might have something like this:

<cffunction name="init">
<cfargument name="dao" hint="reference to this objects DAO">
<cfset variables.dao = arguments.dao>
</cffunction>

And then...when the save method is called, the object passes itself to the dao:

<cffunction name="save">
<cfset variables.dao.save( this ) />
</cffunction>

I wasn't going to post anything else here after having made myself look like an ass before. :P

But in retrospect I will add a couple more comments. Brian's description of the idealized package object at UPS is the underlying motivation behind my creation of the CacheBox project, which I've only barely started working on (none of the code works yet). I wanted to create a system by which you could create a naive CacheBox which can internally determine whether or not various caching services are available and what its own best strategy for caching is, independent of the rest of your system. So that while you might initialize it with an "occupancy" (limit of the number of objects in cache), you're not spending any time working on configuring or developing the service layer that performs the actual caching. You just say "here's my cache -- cache, store this x" and the CacheBox then determines the best available strategy (which may even change periodically throughout the day based on usage trends and available resources). I would love to get some more folks involved in that project as well to help me figure out methods for strategy selection, resource analysis, etc. :)

I will however also throw out another comment in the "this may sound egotistical" category with regard to persistence. While it's all fine and good to say that you want the flexibility and separation of concerns to be able to save any given object so XML or various other places that are *not* in a database, any of those things (yes, even XML) are very obscure edge-cases and easily dealt with on the rare occasion that they crop up with any number of various strategies from "okay, I usually call object.save(), but I'll call xmlPersistenceLayer.save(object) here instead", to inheritance (com.myCompany.xmlPersistedX -> extends com.myCompany.X) to a decorator which gets wrapped around the original object and replaces the original persistence methods. The latter two solutions even allow you to reuse existing integration code.

Which is why in my mind, I don't see an advantage in terms of "separation of concerns" to avoiding object.save(), because well over 99% of the time the object is going to be saved to a database.

Avoiding it simply because you *might* (but in all probability won't), means you're creating more work for yourself simply because there's a remote possibility that you might actually need to do more work. So the options are "more work all the time" or "more work on rare occasions". I opt for "more work on rare occasions" personally... ymmv of course. :)

And speaking of alternatives... creating an XMLFacadeAgent.cfc for the DataFaucet ORM which would behave like a SQL-Agent but interact with an XML file under the hood is another in a long string of cool projects I don't have the time to work on right now. Would love to see someone else give it a shot tho! :)

This has turned out pretty long, so I'll start with my conclusion:
1. save() does not belong on the bean
2. validate() does belong on the bean - but not as much of it as you think.

OK, my reasoning:

I don't think bean.validate() needs to know about more than just the bean. Things like uniqueness checks belong to the collection(s) to which you are trying to add the bean. A bean can be OK to add to one collection and at the same time not OK to add to a different collection. In some circumstances for "collection" you can read "database table".

WRT save(), I like to think of persistence scopes as being in the spectrum of variable scopes. We're familiar with function local, source file, package, request, application etc. scopes. A datasource is just another scope. So, if I have a local variable in a function, and I want it to go into the Request scope, in general I won't do that inside the function - I'll return the value and the caller can then put the result where they want it. In the same way, I have whoever owns the reference to my bean decide where to put it, perhaps into a persistent scope by saving it.

As an exercise, rename your bean.save() function to bean.addToPersistentScope() and see how you like it. Maybe add bean.addToRequestScope() and bean.addToApplicationScope(). Not so pretty IMHO.

An extension to this thought is transitive persistence. If I put a value into a struct that is in the Application scope, that value is then also in the Application scope. I don't need to explicitly assign the value to the Application scope, in fact I don't even need to know that the struct is in the Application scope.

In the same way, if I add a bean to a persistent collection, or set a bean as a property of a persistent parent, then my bean should also be persisted. I shouldn't need to explictly save it. So the only beans that ever get explicilty saved are what the domain-driven design folk would call an aggregate root - some top level bean that has no parent.

It takes a pretty serious ORM framework to do all of this seamlessly. Transfer isn't there yet, Hibernate is further along but still not quite there. In the meantime we have to add some of the plumbing ourselves. I just keep that end goal in sight, and don't expect the plumbing to look like anything other than plumbing. But right now that end goal tells me:

1. save() does not belong on the bean
2. validate() does belong on the bean - *and* on the collection, *and* a couple of other places that I won't go into again.

One of the problems with these types of questions is precisely that the answer changes based on the context. A user object should do what that specific application needs it to do. A different application will have different needs.

Should you be able to ask a persistent object to save itself? Much as I don't like the Active Record pattern, it does have the convenience that once you have a business object, you can do whatever you need with it and then tell it to save changes without needing to reach back to the (user) service to handle the save operation. That becomes useful when you have code that asks a (user) service for a user object and then passes that off to another service (S) which may or may not perform some operations on that user. If save() is only on the user service, you have to tie your S service to that user service - which increases dependencies.

I view validation in much the same way: I'd rather just go to the object and ask it "Are you valid?" and not have to care about where the actual validation logic really lives.

Going back to the ice cream example, the model that springs to mind is shopper.shouldPurchase(product) and the shopper object is responsible for deciding whether to purchase the product or not. However, there is no one true way to approach this problem - it all depends on what elements are important to model in your scenario and what behaviors are important.