Yes, use of getters, and setters to a lesser extent, needs some extra consideration.

If I am following correctly, your object can be initialised via init() but also can have any setters you need. For example, your User object may have functions:

init(firstName,lastName,dob)
setName(firstName,lastName)
setDateOfBirth(dob)

Your init() function would probably call setName() and setDateOfBirth(). The actual validation would occur in these two functions, not in the init() function.

So, your objects are not immutable, even though they are are passed initial values via init()

Your populate() function could still self document by listing out all of the possible arguments in the function, and then call populate(argumentcollection=data).

I don’t really think of populate() as being better or worse than setters. Each object should be modelled according to it’s needs. Sometimes setting values in one bunch is useful, sometimes providing setters is useful. And you can provide both if that helps.

In the makeDefaultUser() function, it may be implemented something like:

<cffunction name="makeDefaultUser" output="false">
<cfset variables.firstName = "First Name">
<cfset variables.lastName = "Last Name">
<cfset variables.dob = "">
</cffunction>

1. I understand, getters and setters should be avoided if possible, but practically there are many objects that requires setters, especially the beans.

2. validation on init() is limited for web app since validation is only done on instantiation… so how can I validate when I needed to update certain fields in the future after the object is loaded back from the DB?

a.) that’s for immutable object. How about object that represents a row in DB, and the user changed a field in a form? (e.g. shipping address?) I still need the setter(s)..

b.) populate() seems worse than setXXX(), ’cause u need to document what keys in struct are needed somewhere, and made the code less self-documenting.

c.) I don’t see how that’s better than having setFirstName() and setLastName()

d.) how can u use makeDefaultUser() to set first & lastname?

There are a couple of ideas to consider:

1) When you are designing your object you would not necessarily have setters for every field.

2) The validation probably doesn’t sit in the init() function. It’s likely that the init() would call the setters/other functions (some possibly private) which would in turn perform the required validation.

Couple of scenarios:

a) You may have an object with no setters – the only way to get data into the object is via init().

b) You may have an object with no setters – all data is set via a populate() function which takes a struct of values.

c) You have setters that set more than single values. Rather than setFirstName(name) and setLastName(name) you might have setName(first,last).

d) You only have setters for a limited set of fields. The other fields are modified by other functions. For example, firstName and lastName are set on init() but are modified by a function called makeDefaultUser().

This reminded me that if you don’t pass values via the init() function then your object needs to internally set itself to a valid initial state.

In our example above where a first and last name were required, the object might set default values of the first name and last name fields to be "First Name" and "Last Name" if that was appropriate. If having these default "place holder" values was not appropriate then these would need to be mandatory in the init().

Thanks for expanding on that part, great points.

What is needed is to really look at the essence of the validation problem. There are two ways in which the object can get to an invalid state:

1) when an individual property has an invalid value independently from the values of all other properties. i.e. "password has to be at least 6 characters long"

2) when the invalid state is caused by the relation between two or more properties, i.e. if property A is given, then property B must be non-empty.

Checking for case 1 is simple enough by putting the appropriate checks in "setter" methods; however case 2 is more complex since the logic, as Kevan points out, cannot just reside on the setters since the object will be invalid in the time between the setters for the two related properties are called.

In my opinion, this problem needs to be dealt at the time when the object is modeled. There is nothing in OO-land that says that you "have to" have a setter method for every single property in your object. If you know that the business rules for the object indicate that it should not be allowed to be in an invalid state, but at the same time the validity of the state involves cross-checking multiple properties, then your object should provide a way in which all these properties are entered at the same time. This is pretty much what Kevan did when he passed all the values on the Init() method. Now, using the init() is not the only way to do this. You can very well have a setter method that takes some sort of transfer object or value object that is just a container for multiple properties (without validation). You can even use a plain old "struct" type for this and keep things simple. This method ( init(), setMemento(), setState(), or whatever) would take this container of data, apply whatever validation rules are needed and then react accordingly either by accepting the values or throwing errors. This way the business logic that determines when the object is valid or not remains encapsulated within the object, but you ensure that your object will ALWAYS be in a valid and consistent state.

Cheers,

Oscar

Thanks

Thanks for your thoughtful responses to my comments. Regarding the issue of objects being in an invalid state, I’m not concerned because I have total control over the system and the data. It isn’t possible for an object to be persisted to the database in an invalid state, so it’s also not possible for one to be retrieved in an invalid state. I can see how if this scenario doesn’t apply (e.g., data can be populated from outside your system) that you’d have to have a way of dealing with that. It’s just that I don’t have that concern so I don’t need to solve a problem that doesn’t exist for me.

Yes, I am thinking this through more after Bob’s comments.

I suppose the main role of the extra object is to act as a data transformer. As Bob mentioned, the forms and objects may not have a one to one relationship – one form could result in many objects, or one form could represent only part of an object.

Perhaps this extra object has similarities to a Gateway that transforms database data into objects. In this case transforming form data into objects, but also provides validation.

Found this link which appears related:
http://www.scribd.com/doc/10894361/Transformation-Interface-Design-Pattern-Andy-Bulka

Thanks

Thanks for your comments – you mentioned quite a few things I hadn’t considered and gave me some great things to think through.

> The problem I have with the UserForm object is that I might have many
> forms which interact with the User object …

In the case where the user data is used in a multiple form contexts then I would consider the UserForm would then represent a part of the form rather than a whole form. It would be used to validate those couple of fields within the larger context.

> Another point is that the logic dictating whether data for a user is
> valid can change based on the context …

That’s a good point, hadn’t thought about it. I would still consider that there would only be one UserForm object which is responsible to being aware of all of the possible fields, but you could perhaps supply a NewRegUserFormValidator or UpdateRegUserFormValidator to the init() which knows how to validate it in specifc contexts?

> Maybe I’m not even using a form to update the User.
> Maybe the user can update their name via email.
> Should I still call the object used in that situation a "form" object …

The data could come from a variety of sources – forms, email, imported data, etc. But perhaps the idea is still the same because it is still just a collection of fields, but maybe I need a more abstracted name if it is used in various ways. This object is essentially taking external data and transforming it into an object, perhaps UserTransformer? Not sure. I agree the name needs some thought but perhaps the idea is still ok.

> I feel that the logic that represents the business rules that
> determine whether data is valid for a User should be linked
> to the User object in some way, not to "form" objects.

Yes, I agree. If we consider than an object can only exist in a valid state, then there must be validation logic within the object that ensures this, e.g. thowing errors when attempting to change the object into an invalid state. In this scenario, the validation would be handled by attempting to set the data and catching errors – now *this* I am a stuck on. Seems a bit clumsy, but it does prevent duplicating the logic in the separate object.

> I store all of those business rules in metadata …
> I have actually developed a complete system to do that,
> which is available as open source software.

That is an awesome mighty effort Bob! Yes, your validation library would fit perfectly wherever needed. I will have to take a closer look!

For anyone reading, it is here
http://validatethis.riaforge.org/

> Perhaps OO purists will call me names for this, but I think this
> "an object cannot be in an invalid state" thing is a red herring.
> I prefer not to worry about "rules that must be followed",
> but rather concentrate on allowing fundamental OO design principles
> to guide me, and take a practical approach …
> I know that I’m never going to get a User object that isn’t invalid.
> If a User object is populated with data from an external source,
> then it gets validated and if it isn’t valid it gets discarded.
> There is no danger of an invalid User somehow ending up
> floating around my system.

Through your comments I realised that an objects data can potentially come from anywhere; form, email, imported file, database, etc. With objects that are populated from a database though, there is a possibility that the objects could come in invalid, perhaps because to another process had changed the data. If objects were required to validate themselves then this would mean that validate() would need to be called for each object read from the db?

If the object could only exist in a valid state then it would bomb out as soon as the object was being read. If the object can exist in an invalid state then any errors would show up later, perhaps as side effects elsewhere in the system?

Thanks

Kevan