Zend_Validate good strategy to avoid repetition of code

I'm am currently building two custom validators that extends Zend_Validate_Abstract which are named respectively Lib_Validate_TimeAfter and Lib_Validate_TimeBetween. The names a pretty straight forward, the first one is used to test if a date/datetime/time comes after an other one and the second is used to test if a date/datetime/time comes between two other date/datetime/time.

Both of those validators would rely on the same method named _buildDate($value) which take a value in the form of a datestamp, a hourstamp(either hh:mm or hh:mm:ss), a timestamp or an ISO_8601 timestamp and convert it in a usable date format.

Since I dont want to repeat myself and copy/paste the method in both of my validator, I was looking for the best way to do it.

The avenues I am looking at right now would be to develop somekind of class helper that my validators would be able to use (kind of messy way of doing things since it add unessesary dependencies) or I could add an other layer of abstraction by building an other validator that validate date/datetime/time and then extend my two validators on that since I could share the method _buildDate($value), but then I don't think I would really need the validator.

So, what would be a good way (I am not really looking for the "Way of the gods" of doing thing) to structure that kind of code to avoid repetiti开发者_如何学编程on (DRY)?

---

You might want to build one validator instead of two, where you can pass in a dateBefore, dateAfter which are both optional. If you pass only dateBefore, your $value will be valid if it is after that date, if you pass in both, it will have to be between them and if you pass in only dateAfter, the value will have to be before that date.

This would be flexible, clear, generic, less code and even cover one more case.

---

What about a class Lib_Validate_Common which extends Zend_Validate_Abstract which has your common method. And Lib_Validate_TimeAfter and Lib_Validate_TimeBetween extends Lib_Validate_Common .