Repositories are a special example of a class. They usually have a lot of methods designed to retrieve data from the database or the other storage. To mark this operation in the name of the method, we can use one of the common words: find, get, search. Are all them mean the same? In this article, I would like to show you a practical difference between getById and findById methods.

Find vs Get

It’s nothing wrong to use find and get words in methods' name interchangeably. Both of them have similar meanings and mark the intention properly. However, if we decided to differentiate them, we’ll get an extra benefit as the more meaningful and consistent code. Let me give you an example. Please see at the following:

interface ArticleRepository
{
    public function getById(int $id): Article;
    
    public function findById(int $id): ?Article;
}

Did you pay attention to the extra question mark in the second method’s header? If you already know what’s going on, you can stop reading here. You can also leave a comment under this article describing why you use this convention. Otherwise, you can continue reading.

As you can see, the only difference (besides the name of the methods) is the return type. This is related to the error handling mechanism — what should be done if the entity doesn’t exist?

Return null or throw an exception

First method, getById always returns an Article object. You may use this method in a workflow if you’re sure that the specific entity exists. E.g. when you have checked condition related to its existence. If for some reason the entity doesn’t exist, there is an actual unexpected situation and the method throws the exception.

If we could embody the getById method, it would be a kid who always gets what he wants. Otherwise, he will scream like a crazy. You should know beforehand how to deal with him.

On the other hand, findById either returns Article or null. It depends on the existence of the requested entity. You may use this method if you’re not sure if this entity actually exists, e.g. when someone requests a specific article through an API.

In this case, the findById method is more like a customer in a grocery store. He may ask for something and get it. Another time, he may ask for a blue tomato and get nothing. It happens.

Small improvements, big results

Although this proposal isn’t revealing and ground-breaking it makes the code more predictable and consistent. The more predictable and consistent code, the easier to read and understand it is.

Remember, that nothing works separately. If you want to improve the codebase of your project, you have to introduce a set of easy and useful standards and techniques. If you know polish, I encourage you to read my article “How to update standards in the aged project” 🇵🇱.

In our team, we successfully use this convention, sometimes in conjunction with return early approach. Our controller’s actions often have to return details regarding the requested entity. If the entity doesn’t exist, we handle it immediately. For instance:

public function actionShowArticle(int $id): Response
{
    $article = $this->repository->findById($id);
    
    if ($article === null) {
        return $this->errorResponse(StatusCode::NOT_FOUND);
    }
    
    return $this->response($article);
}

Or the other example, if you prefer exceptions:

public function actionShowArticle(int $id): Response
{
    try {
        $article = $this->repository->getById($id);
    } catch (EntityNotFoundException $e) {
        return $this->errorResponse(StatusCode::NOT_FOUND);
    }

    return $this->response($article);
}

The most important is to keep consistency in the behavior of findBy… and getBy… methods. The inconsistent code is untrustworthy, so each time, developers have to make sure that the method is implemented properly, instead of taking it from granted.

Summary

It’s all about the convention and standards. These things are useful as long as there are people who want to use them. If you feel, that this tip might be useful in your project, don’t hesitate to discuss this idea with your team.

Even in an old project, it’s still worth to propose and introduce improvements, to reduce a cognitive load of the code. The work with this code will be much easier and more enjoyable, for you and your teammates.

If you like this article, I’ll be grateful if you share it further. Thank you!

Featured photo by Aaron Burden on Unsplash..