Page 2 of 2

Posted: Thu Nov 04, 2004 3:50 pm
by The Monkey
timvw wrote:for my Database Table class I ended up with following methods:
- create // accepts array with key=value pairs
- read // accepts sql where clause, offset and limit
- update // accepts array with key=value pairs (need the primary key)
- delete // accepts array with key=value pairs (need the primary key)

then i also have:
- getDataDictionary // returns a hash with the fields in the db table
- getValidator // returns an instance of a class that does validation
- getFormatter // returns an instance of a class that does formatting


validator has methods:
- validate_create
- validate_read
- validate_update
- validate_delete

formatter has methods:
- pre_create
- post_create
- pre_read
- post_read
- pre_update
- post_update
- pre_delete
- post_delete
I've been thinking about this for some time now, and although your approach makes sense, I feel that fact of your first class "relying" on two other classes seems to somewhat defeat (Or at least try to circumvent) the entire point of OOP.

What I feel is needed (for my project) is an Query class that can stand on its own. When it comes to validating / formatting data, you could always have the Validator / Formatter class "extend" the Database Table class, but this then leaves the Database Table class as somewhat useless.

The approach I am taking is to have the Query, Validator, and Formatter classes completely seperate from each other. When I need to format some data to prepare it to be queried, I would run it like such:

Code: Select all

<?PHP
$query = new Query();
$format = new Format();

$formatted_data = $format->create($data);
$query->create($formatted_data);
?>
This keeps everything seperate, and my $query->create method simply does it's job: to create an entry using the pre-formatted data it is given.

Any thoughts?

- Monkey

Posted: Fri Nov 05, 2004 4:23 am
by timvw
The Monkey wrote: I've been thinking about this for some time now, and although your approach makes sense, I feel that fact of your first class "relying" on two other classes seems to somewhat defeat (Or at least try to circumvent) the entire point of OOP.
I don't really see where i'm trying to defeat OOP? In my eyes, the getFormatter and getValidator are examples of strategy pattern. They allow me to plug the wanted business rules into the Table.
The Monkey wrote: What I feel is needed (for my project) is an Query class that can stand on its own. When it comes to validating / formatting data, you could always have the Validator / Formatter class "extend" the Database Table class, but this then leaves the Database Table class as somewhat useless.
At first i had the validation and formatting functions in the Table class, but i factored them out.

For example, if i want to extends the Table class with a validation rule that does regular expression testing, each class that wants to use this would have to add the lines that do the testing...

To overcome this copy-pasting, OOP is a valid solution:
I only need to edit RegExpValidator and plug it into all the classes that want it.
The Monkey wrote: The approach I am taking is to have the Query, Validator, and Formatter classes completely seperate from each other. When I need to format some data to prepare it to be queried, I would run it like such:

Code: Select all

<?PHP
$query = new Query();
$format = new Format();

$formatted_data = $format->create($data);
$query->create($formatted_data);
?>
This keeps everything seperate, and my $query->create method simply does it's job: to create an entry using the pre-formatted data it is given.

My Create function only allows data that is in the wanted format, and only if that data that is valid. Everything else it would reject ;) Your create method would also allow unformatted/unvalidated data.

Code: Select all

function create($what)
{
  $what = $this->formatter->preCreate($what);
  if ($this->validator->validateCreate($what))
  {
    $query = $this->dmlCreate($what);
    if ($this->dbmsQuery($query))
    {
       $this->formatter->postCreate($what);
       return true;
    }
   }
   return false;
}

Posted: Fri Nov 05, 2004 7:35 am
by BDKR
The Monkey wrote: I've been thinking about this for some time now, and although your approach makes sense, I feel that fact of your first class "relying" on two other classes seems to somewhat defeat (Or at least try to circumvent) the entire point of OOP.
I don't really believe this is the case. He's taken well defined behaviours and place them into Classes based on the principal of Responsibility Driven Design. Now his design may seem to indicate some reliance on the other objects, but that in itself isn't too bad. Too much coupling ( http://c2.com/cgi/wiki?CouplingAndCohesion ) is a bad thing, but in something like a lib, it's unavoidable. Evenstill, it's better to have multiple objects working together and passing messages as opposed to a God object.

Another nice thing about this approach is that as long as the classes and methods are well named (something I've not allways done a good job at :oops: ), it's easier to grok for someone coming in from the outside. Especially if each class represents only one behaviour.

Cheers

Posted: Fri Nov 05, 2004 9:20 am
by The Monkey
Yes, my problem with his approach is the reliance on other objects. It was my understanding that this was usually a no-no; however, once he explained the way his function worked more fully, I understood more how his objects interacted.

Another thing I assumed was that his method requires declaring $format and $validate global in each and every function located in his query class. I found that when I did that, it was chaos. :oops: Tim's method is far cleaner.

Again, the objection I had was his reliance on foreign objects, but what you both have said makes sense.

- Monkey