I've an object that can be one of three different 'modes'. It can be an employee, a student, or a private individual - just for an example. Each one of these has a different set of business rules so when the object is created I ask what 'version' of the object is required and set the validation rules as the object is being created.
This is happening on the web in a wizard, so when the person goes onto step 2 if they decide to back track and change the mode from employee to student I want to be able to clear out the current validation rules and place a different set in there.
The current validation rules object doesn't have a 'clear' method.
Is there a way to make this work? I don't wanna use inheritance because the differences between these three types is only 3-6 rules out of 20.
Dude, that idea rocks!
Thanks a bunch - I can see how that would be much more flexible in the long run and much easier to work with over all. Thanks a bunch.
MadGerbil:I've an object that can be one of three different 'modes'. It can be an employee, a student, or a private individual - just for an example. Each one of these has a different set of business rules so when the object is created I ask what 'version' of the object is required and set the validation rules as the object is being created.
My wife is BOTH an employee of a university and a student. In addition, in some of her dealings with the university, she is acting as an employee (reporting grades for her students), in others she is acting as a private individual (donating books to the university library from our own library).
So, I have to ask you, are you sure that a person can only be one of those three things at any one point in time? Or is mode representing the role the person is acting within at a given point in time?
The concerns brought up by some posters in this thread are all valid; and that is because I wasn't very thorough in describing the object with which I'm working.
I have a check object (like a purchase order) and the type of payee can be student, employee, or business - so address I wish to collect may have some different options based upon whether or not I'm collecting a single name (for a business) or a first and last name for an individual.
Obviously I don't want to show the first name/last name field on a voucher that is of type Business - nor do I want to validate those fields. (or the validation should always return true)
The type of payee is important only for the address and some reporting purposes and the type of payee is a property of the object itself - not so much a description of separate objects. That is to say, I don't have a student object, an employee object, and a staff object because there is no need for that.
So the concerns brought up in this thread are valid - if I were actually trying to somehow merge a student/employee/business into one object. In that case, inheritance would make more sense and with that the business rules would obviously work themselves out.
I had an object that was used to display a variety of different transaction types. Each transaction type had its own set of properties (some of which were used by more than one transaction type).
I only wanted my UI control to display the relevant properties for that transaction type (plus the headers). So, I set up my object with a set of Show<PropertyName> booleans. If the property applied to that transaction type, I set the Show<PropertyName> for it to true, otherwise I set it to false. All the logic to set those booleans was in one function, and each property that might change what I could do called it after setting the new value. (Plus, of course, the Fetch routine for loading it from the database.)
For the items in the control, I set the visible property on or off based upon the show property. Worked very well. Was even able to turn rows on or off (inserts/deletes just needed to show new data, updates needed to show new and old values) using this trick.
You could also put logic in the set properties to verify that the property is applicable before accepting the value, in case you don't trust your GUI programmers. I never do - even if it's me. :)
Copyright (c) Marimer LLC