Quick Thought On OOP Data Validation And Why Redundancy Is OK

Hi Ben,

I see where you're coming from, and I know it's hard to see these objects as "data types". One thing that helped me decide not to make my objects validate themselves was a simple thought I had about the DollarFormat() function in CF. Although this is not the same type of object that we create, I asked myself does DollarFormat() validate the data that I pass into it before it process the code? Or, do i make sure that I pass it a numeric value? We know that DollarFormat() always need a numeric/decimal/etc... value, we will never pass it a string or a bolean, etc... So why not do the same with our objects? Maybe we grab some data out of the database, instantiate the object, and let our object worry about business behaviors and that sort of thing.

Anyhow, it's just a thought, it's what helped me get over the mental hurdle that challenged me.

@Ben,

"Our calling code might check to see if the given value is between a given range, maybe $0 and $1,000,000... that's the business logic"

This type of validation is fine (for me anyway) to exist in the object since it is business logic. I guess what I was thinking when I heard the word validation was that it was validating a string, int, etc...

Ben,

Often, a form will be the energizing agent for creating a domain object. This is why I recommend having a "Form" class that has methods like: display(), populate(), and validate(). This has a lot of value and shows how objects can be used for simple but very useful things.

You can see in your example that an Account would need to protect itself against one level of badness -- it's expecting a numeric value and someone passed in an array -- but it can't be expected to know whether or not a numeric value is actually a duplicate of another account.

@Hal,

So where would you check to see if the account number is a duplicate of another account, assuming that someone submitted a new form?

Your form class needs to validate its data. Typically, it will delegate this to another class that knows how to validate stuff. You might have multiple validation classes. One of these guys will know how to check to see if the account number is valid, then return the results to the Form object that can then return a nicely formatted error to the form page.

It's very powerful, Ben. Depending on what/if any framework you're using, you can have the form post directly to the Form object's populate method, which will then call its validate method.

Just to be ornery, I'd argue that there's no such thing as "duplication of [validation] logic".

If the whole point of OOP is that you can take out one black box component and drop another in its place, or take a black box component and reuse it someplace else, then each and every object should be as paranoid as possible for what it accepts. If that means you perform the same check 5 times as you traverse the object chain, then so be it.

As long as the paranoia fits the scope of the object, then keep it in. (That is, if you have a function that hyphenates the account number, then while checking the length would be a valid check, checking to make sure it is a valid account number probably isn't.)

(Yes, yes, yes, I know you can make a counter argument to this where the validation is some expensive operation, but that's an edge case and an optimization problem, not a structure problem.)

I've been writing ActionScript 3.0 almost exclusively for the past year, with Cairngorm MVC, so I am totally drinkin OO Kool-Aid. I do no have much experience with CF OOP, so I might be totally off here, but, if you are simply validating the data-types of the properties in your constructor, why don't you strict data-type the input parameters of your constructor? In AS3, I would do this:

function Account(name:String, number:int, typeId:int, ownerName:String)
{
accountName = name;
accountNumber = number;
accountTypeId = typeId;
accountOwnerName = ownerName;
}

No validation necessary. Can you do something similar in CF?

Well, I went through a similar dilemma in designing my value objects in my Flex applications, and I decided as a general rule NOT to perform validation in the constructor, but, instead to have any additional - not front-end - validation be performed in a separate command class where the Account is created, and perhaps added to the Model - i.e. "CreateAccount". This works very well for me, keeping different types of logic separated, and keeping value objects simple - usually just properties. I feel this is a better practices for code portability and code readability.

@Rick: Preach it, brother!

I follow this practice both for instantiating Objects from data returned by WebServices, and for instantiating Objects on-the-fly based on user input.

For instance, I have a UI which allows a user to create a new set of report definitions and then run that report. As they create the Report using a step-by-step process, I run several pieces of validation - i.e. validating that percentages they enter on one step add up to 100. When they click the "Save Report Definitions" button, I call a command that creates a "Report" instance and validates things such as the name they gave the report is not already in use. I then call a WebService to "save" the report definitions to the database. The next time they load the application, that report definition is returned by a WebService, and this also creates a Report instance, but uses a different command, since no validation is necessary.

Also, in some cases, I create an instance of an Object with no data in it, and add data to it on the fly, either by calling commands to do so, or by simply setting a single property. By default, I write all my Objects with no validation in the constructor, so that I have this flexibility. I guess it depends on the type of application you are creating, and the platform which it is on, but I'm just sharing my general practices for OOP to give you food for thought....

@Ben: I guess I have to disagree with your logic. It *is* duplicated logic, and the problem will come in when you have to change that logic.

For example, your company acquires a new subsidiary, and their account numbers are a different length. Now you have to find all the locations you are validating your data -- two places! -- and change them. Or subclass Account to two new ones, legacyAccount and newWhizbangyAccount. Even though you can now pass an Account object around, you have validation that wants an account number of a specific length, scattered around your code. You now either throw away the one validation, or you have to know you are passing a specific account type.

For me, duplicated logic is the same as duplicated data -- it can cause problems, and you need to have a good reason to allow it (usually efficiency).

I agree our Account Object should do common sense validation. The Account Object needs to stand on its own two feet, blind to the intentions of the thing that called it.

Very interesting reading.

I hope this doesn't sidetrack the discussion (this is a great topic Ben!), but I wanted to ask about returning errors in objects. Do your object methods throw errors? Or do all of your methods have some type of return logic that is consistent for each method? For example, let's say there is a method called getFoo() that returns some piece of data from a database. There is a problem with accessing the database, and the query fails. How would you return control to the code that called getFoo()? I can see two ways: 1) throw an error and make the caller of getFoo() catch it or 2) have getFoo() return a structure (or something like it) with keys indicating whether getFoo() succeeded or failed and the return data or the error condition.

My gut tells me every method except init() should return some value or structure. It gets back to the concept of an object as a black box.

Thoughts?

Thanks,
Marc

@Ben,

Thanks for your insight. So do you define the types of errors thrown by a method as part of some kind of system contract?

Ending a session and starting a new

My end consumer is already logged in. Session.UserID

Placed and order, now they are done.

<cfquery datasource="Generic" name="PurchaseOrders">
SELECT *
FROM Orders
WHERE WeborderID = '#url.WebOrderID#'
</cfquery>

<CFSET getitbaby = Session.UserID>
<CFSET STRUCTCLEAR(APPLICATION)>
<CFSET STRUCTCLEAR(SESSION)>
<CFLOOP INDEX="x" LIST="#GetClientVariablesList()#">
<CFSET DELETED = DELETECLIENTVARIABLE("#x#")>
</CFLOOP>
<CFCOOKIE NAME="cfid" EXPIRES="NOW">
<CFCOOKIE NAME="cftoken" EXPIRES="NOW">
<CFCOOKIE NAME="cfglobals" EXPIRES="NOW">

<CFSET Session.UserID = getitbaby>

This works if only they click the button I created for them.

<cfquery datasource="Generic" name="thechecker">
SELECT *
FROM Loger
WHERE ID = #Session.userID#
</cfquery>
<cfif thechecker.Admin eq 1>
<cfinclude template="includes/Header1.cfm">
<td width="693" align="left" valign="middle">
<table align="center" border="0" bordercolor="336699" cellpadding="3">
<tr>
<td>
<cfform action="admin.cfm">
Your Order is complete
<input type="hidden" name="theid" value="#Session.UserID#">
<input type="submit" value="Continue With This Program" style="font-family:Verdana; font-size:10px; font-weight:bold;">
</cfform>

Any way around this?

Exploring :-)

@Ben

The problem with throwing errors like that is that you can't generically catch them.

Account.Init.Number.InvalidArgument

With this you can cfcatch Account errors, or Account.Init errors, or even Account.Init.Number errors, but you can't catch InvalidArgument errors generically.

CF can catch errors based on dot notation, so you'd be better off doing it in reverse.

InvalidArgument.Number.Account.Init

Now you can cfcatch type="InvalidArgument" and catch errors from anywhere in the call chain, instead of needing to explicitly catch each one.

Not sure why you want the class name and method name in there though. That'll be in the stacktrace. :)

hum... this is sort of back to the original post idea of redundant validation, but also shows how we have tackled error/sucess/warning feedback. i definitely think each object should be a blackbox (imho) and not rely on anything outside to function. we have grappled with how to do that consistently and on large scale and have finally accepted and implemented the idea of using a metadata repository to help us systemize validation/encryption/advanced validation/glossaries/et cetera.

We have moved to incorporating a generic DAO coupled with a DataDictionary (DD) that contains metadata about field types so that we can consistently apply both basic and advanced validation. It, along with another wrapper that builds a display widget for the form type (ajax based, and it also handles concurrency issues just like Blaze/LiveDS does) , takes care of end user validation (at the form entry level) and server side validation at the db commit. It handles custom formatting (phones/ssn/accounts whatever) as well as de/encryption for secure fields, passes along end user help and error messages from the dd glossary. They also (all our functions/methods actually) always pass back a structure that includes status (success/failure/warning) and end user messaging which can then be displayed to end user if relevant. sometimes they throw, but usually only in true error situations, otherwise they *fail* but return detailed structure.

The meta information is abstracted enough that ANY process not going through the DAO (which are few) can still easily apply the same rules, validation and formatting pertaining by asking the DD for help on what to do.

For complex objects or process points (let's say at account creation) a third wrapper (business function) would validate complex biz logic and relationships (like if this value exists, then these other values must exist as well) before talking to the DS/DAO (which perform the other validations and feed this back to the business function on fail/warning). This top level biz logic is either contained in the complex object and/or in a workflow system.

In short, the DD approach has helped us immensely in making sure our blackbox strata always apply the same basic/advanced validation in a systematic and scalable way. Objects don't worry about (or trust) other objects validation (they are paranoid). Our coding standards tell us how to consistently feed success/failure info through the objects so they can communicate effectively.