Organization of classes in PHP

Anything about handling the validation in itself will match your Is

-classes:

• Has it gone?
• What parts didn't go through?
• Should validation errors be logged somewhere?

Zend_Validate in Zend Framework provides such an approach, you might get some inspiration from it. Since this approach will allow you to implement the same interface in all validation classes, you can easily

• use the same syntax for validation, regardless of which data is validated
• it's easy to recognize what validation rules you have by checking for all named classes Is_Prime
  
  , Is_Image
  
  instead of checking for Math_Is
  
  , Image_Is
  
  everywhere.

Edit:
Why not use a syntax like this:

class Math {
    public function isPrime() {
        $validation_rule = new Is_Prime();
        return (bool) $validation_rule->validates($this->getValue());
    }
}

      

        
        
        
      

    

And thus also allow

class Problem {
    public function solveProblem(Math $math) {
        $validation_rule = new Is_Prime();
        if($validation_rule->validates($math->getValue())) {
            return $this->handlePrime($math);
        } else {
            return $this->handleNonPrime($math);
        }
    }
}

      

        
        
        
      

    

I think there is no "right answer" for the problem you mentioned. Some people will put Prime in Is and some will put Math. There is ambiguity. Otherwise, you won't be asking this question.

Now you need to somehow resolve the ambiguity. You can think of some rules and conventions that will tell which class / method goes there. But this can be fragile as the rules are not always obvious and they can get very complex, at which point they no longer help.

I suggest you create classes to make it obvious when you look at the names where some method should go.

Do not include your verification package. It's such a generic name that almost everything goes there. IsFile, IsImage, IsLocked, IsAvailable, IsFull - doesn't sound good, okay? There is no cohesion in this design .

It is probably best to do the component filter data at the subsystem boundary (where you need to enforce security and business rules), nothing more.

After making this decision, your example will become obvious. Prime belongs to mathematics. Is :: The image is probably too generic. I would prefer Image :: IsValid because you will probably have other methods of working with the image as well (more cohesion). Otherwise "Is" becomes a bag for everything , as I said at the beginning.

I don't think "is" at all belongs to class names. I think for methods.

abstract class Validator {}

class Math_Validator extends Validator
{
  public static function isPrime( $number )
  {
    // whatever
  }
}

class I18N_US_Validator extends Validator
{
  public static function isZipCode( $input )
  {
    // whatever
  }
}

class Image_Validator extends Validator
{
  public static function isPng( $path )
  {
    // whatever
  }
}

Math_Validator::isPrime( 1 );
I18N_US_Validator::isZipCode( '90210' );
Image_Validator::isPng( '/path/to/image.png' );

      

        
        
        
      

    

Is there a holy grail solution for organizing classes? Maybe a different paradigm?

No, this is the main drawback of the oop class. This is subjective.

Functional programming (Not to be confused with procedural programming) has fewer problems with this question, mainly because the basic building blocks are much smaller. Classless oop also performs better, being a hybrid of oop and functional programming.