If Only Everything Were an Object
While it isn't really practical given the nature of ColdFusion, I sometimes wish we had the Smalltalk/Ruby approach of everything being an object. It would make fluent interfaces (which are cool but not essential) and abstract data types (which I now find I can't live without) much easier to implement.
It's not that you can't implement ADTs in ColdFusion, but I'm not really happy with the way I've implemented them, using a service layer and a strategy pattern. Same goes for validations, transformations and a number of other methods that I'd really like to be able to assign to my own custom data types. I’ll explain the approach I'm using later today and perhaps someone will be able to suggest a more elegant approach to solving this problem in ColdFusion . . .
But, if ColdFusion is a typeless language, isn't that the same thing? If nothing has to have an explicit type when being passed as a function parameter or a return value, isn't that basicaly and abstract data type?
Maybe I am not understanding what you mean (with my limited OOP experience)?
Not quite. Here is what I could do in some languages (they syntax is psuedo code - not the syntax of any particular language):
User.PhoneNumber = form.PhoneNumber;
If NOT User.PhoneNumber.isValid()
Throw Error
This would work because behind the scenes, the PhoneNumber attribute would be an object. I could give that object a type and a validation method so I would always be able to call that validation method for any PhoneNumber type attributes. Even better, in dynamically types languages where anything can be an object, I would be able to put in something that was NOT a valid phone number and it would be treated as unverified data, so I wouldn't get a Java style type mismatch so I'd be able to catch the problem (you entered your name not your phone number) and easily display a well formed error without having to do the equivalent of a try/catch.
Of course, I CAN do the same thing in ColdFusion. I just feel that it is syntactically and architeturally a little cludgy. I do the following (agai, using psuedo code rather than language specific syntax - but this one CAN be implemented in CF)
User.PhoneNumber = form.PhoneNumber;
If NOT User.isValid("PhoneNumber")
Throw Error
And I have a generic isValid() method (kind of like my generic getters and setters). That then calls a ValidationService singleton as follows:
Local.ValidationStatus = ValidationService.isValid(variables.get("PhoneNumber"),variables.dataType("PhoneNumber"))
Return Local.ValidationStatus;
And the validation service switches on the data type of the phone number to include the appropriate validation method. In that way I just have one validation metod for each abstract data type nicely encapsulated within a validation service and smply have to set the data type for each of my attributes when defining my business objects.
As to why I don't like this, it just seems to be a little more cludgy than the attribute itself being an object with a methiod.
Just a preference, I guess, but I'm ending up with all of these singletons (validation, transformation, etc.) that really apply to methods I'd like to associate to my attributes (if they were objects) and it just seems a little bit of a strange solution.
I'll post on this in more depth and perhaps someone will post a blindingly obvious better approach in CF I just haven't thought of!
I like that CF is dynamically typed too. I especially like that I can just throw any object into an argument and as long as it has the right methods it'll work without me having to specifically write an interface (or use inheritance). The joys of duck typing! However, while I love the fact that I can throw anything into a string and then control the validation, I prefer the approach of "unverified data" where I can put an alphanumeric string into an "int" object (say a quantity attribute) and it will simply allow me to call Quantity.isValid() to determine whether it is an int or not. In that way I get (to me) all of the benefits of a typeless language while still getting the ability to attach properties and methods to my attributes.
Of course, there are also a load of reasons I love CF (which is why I use it). I guess I'm mainly raising this to set the tone for my abstract data types and the other things Im doing and to see if anyone has a better way of doing what I'm trying to do within the structure of ColdFusion.
I still don't see your argument. What is the difference with have a IsValid method on every variable and just making your own validation method. Personally I like making my own because there is alot of times where I need to enhance my business rules. Yeah the argument of overloading the method works, but still I don't the difference.
Personally if someone wants a language that treats everything as an object I have to ask them what they are doing in programming in CF. What all the other languages out there that are already doing this and are WAY more mature in this area, I don't see why all of a sudden people want CF to start taking this route. My advice to you, dump CF and start programming in .Net, Ruby, Perl, whatever, just leave my CF alone.
Let me make it clear I am NOT suggesting CF goes this way. That would be crazy. I'm very happy with CF and I'm also always going to miss features in one language that aren't there in another. If I was programming in Ruby I'd be bitching about how hard it is to write a simple database call!
However, I'm just trying to show the conceptual approach of custom data types and to me the easiest way of thinking about it is that each attribute is an object with methods that can be customized to that data type. I think it is a little easier to think of that and then show my actual cludge (a ValidationService and TransformationServicw each as a singleton using a strategy pattern to implement the appropriate validation/transformation switched depending on the data type of the property passed in.
Realized I didn't cover your first point. Firstly, you WOULD be able to create your own custom data types and to set their default validations as well as being able to overload them. Secondly, it just saves SO much effort to just say HomePhone is a USPhoneNumber data type in larger applications as you often have a bunch of US phone number attributes, and now you can set common sense default display rules, transformations, validations and the like without any custom coding at all. Just declaritively specify once how a phone number should be displayed, edited, transformed and validated and that is all taken care of for you throughout the application. Copy a couple of easily reusable class files and the same rules are then available for using (or modifying) on your next project. It is a way to get scaffolding that can actually BE an apprlication rather than scaffolding that is simply trying to prototype an application.
Of course all this can be dne in CF without making attrbutes objects. It might have just been a little easier and less cludgy if CF happened to have that language feature.
Sean Corfield once mentioned that it is always a good idea to learn other languages as you learn new ways of thinking about problems (I still have a book on Haskell I've been promising myself to read since just after cf.objective last year!). It just means that without that background the approaches you use might seem a little strange!