How to represent mandatory business fields on a model structure?

Question

If we use type hinting, we can place an object mandatory:

public function myMethodThatDoFineStuff(MyObject $myobject) {

}

What if, we would like to place, not the all object but only some of it's attributes, to be mandatory ? Let's assume that our domain model will be better, if it better represents a certain domain.If this could make more sense on our business model (on our domain)? How should we do it ?

Our should we always place the ALL Object no matter what ?

EXAMPLE for clarification proposes:

Let's imagine that, in order to list books of a certain author we have this method:

public function listBookOfAuthor(Author $author) {

}

Now, let's imagine that the author object has 200 properties or so, BUT, in order to process the list of books, we only need their first and last name.

Should we receive the ALL $author object anyway ?

Answer 1

I would test for required properties in the following way:

public function listBookOfAuthor(Author $author) {

    if (empty($author->firstName)) {
        throw new listBookOfAuthorException('firstName must be defined');
    }

}

If you find you're doing this lots you could write some kind of parent class that includes a method for checking properties are present.

Answer 2

What if, we would like to place, not the all object but only some of it's attributes, to be mandatory ?

Technically you can create an interface with only those some attributes the function expects. Isolated this might look a bit like overhead but Interfaces are worth to play around a bit with, more in the manual how they work in PHP.

Just because it could make more sense on our business model ?

I know nothing about your business model, so I can't say if it makes sense or not. But I thought you were asking a programming question not a business one.

Our should we always place the ALL Object no matter what ?

Then you'll loose type hinting but you will be able to pass any object. Depends a bit how strict you want to write your code. If you use interfaces you're pretty flexible when refactoring the code (changing concrete object implementations), as well as with the stclass object. However with the stdclass object the function needs to verify what it get's first before processing on the functions input.