DqlQueryBuilder::orderBy()   A
last analyzed

Complexity

Conditions 1
Paths 1

Size

Total Lines 4

Duplication

Lines 0
Ratio 0 %

Importance

Changes 0
Metric Value
dl 0
loc 4
rs 10
c 0
b 0
f 0
cc 1
nc 1
nop 2
1
<?php
2
3
declare(strict_types=1);
4
5
/*
6
 * This file is part of the Explicit Architecture POC,
7
 * which is created on top of the Symfony Demo application.
8
 *
9
 * (c) Herberto Graça <[email protected]>
10
 *
11
 * For the full copyright and license information, please view the LICENSE
12
 * file that was distributed with this source code.
13
 */
14
15
namespace Acme\App\Infrastructure\Persistence\Doctrine;
16
17
use Acme\App\Core\Port\Persistence\DQL\DqlQueryBuilderInterface;
18
use Acme\App\Core\Port\Persistence\QueryInterface;
19
use Acme\PhpExtension\Helper\ClassHelper;
20
use Doctrine\ORM\AbstractQuery;
21
22
final class DqlQueryBuilder implements DqlQueryBuilderInterface
23
{
24
    /**
25
     * @var array
26
     */
27
    private $filters = [];
28
29
    /**
30
     * @var int
31
     */
32
    private $hydrationMode = AbstractQuery::HYDRATE_OBJECT;
33
34
    public function build(): QueryInterface
35
    {
36
        $dqlQuery = new DqlQuery($this->filters);
37
        $dqlQuery->setHydrationMode($this->hydrationMode);
38
39
        return $dqlQuery;
40
    }
41
42
    public function create(string $entityName, string $alias = null, string $indexBy = null): DqlQueryBuilderInterface
43
    {
44
        $alias = $alias ?? ClassHelper::extractCanonicalClassName($entityName);
45
46
        $this->reset();
47
48
        return $this->select($alias)->from($entityName, $alias, $indexBy)->setMaxResults(self::DEFAULT_MAX_RESULTS);
49
    }
50
51
    public function setParameter($key, $value, $type = null): DqlQueryBuilderInterface
52
    {
53
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...Interface::setParameter of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
54
    }
55
56
    public function setMaxResults(int $maxResults): DqlQueryBuilderInterface
57
    {
58
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...nterface::setMaxResults of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
59
    }
60
61
    public function select(string ...$select): DqlQueryBuilderInterface
62
    {
63
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...uilderInterface::select of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
64
    }
65
66
    public function distinct(bool $flag = true): DqlQueryBuilderInterface
67
    {
68
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...lderInterface::distinct of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
69
    }
70
71
    public function addSelect(string ...$select): DqlQueryBuilderInterface
72
    {
73
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...derInterface::addSelect of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
74
    }
75
76
    public function delete(string $delete = null, string $alias = null): DqlQueryBuilderInterface
77
    {
78
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...uilderInterface::delete of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
79
    }
80
81
    public function update(string $update = null, string $alias = null): DqlQueryBuilderInterface
82
    {
83
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...uilderInterface::update of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
84
    }
85
86
    public function from(string $from, string $alias, string $indexBy = null): DqlQueryBuilderInterface
87
    {
88
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...yBuilderInterface::from of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
89
    }
90
91
    public function indexBy(string $alias, string $indexBy): DqlQueryBuilderInterface
92
    {
93
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...ilderInterface::indexBy of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
94
    }
95
96
    public function join(
97
        string $join,
98
        string $alias,
99
        string $conditionType = null,
100
        string $condition = null,
101
        string $indexBy = null
102
    ): DqlQueryBuilderInterface {
103
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...yBuilderInterface::join of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
104
    }
105
106
    public function innerJoin(
107
        string $join,
108
        string $alias,
109
        string $conditionType = null,
110
        string $condition = null,
111
        string $indexBy = null
112
    ): DqlQueryBuilderInterface {
113
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...derInterface::innerJoin of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
114
    }
115
116
    public function leftJoin(
117
        string $join,
118
        string $alias,
119
        string $conditionType = null,
120
        string $condition = null,
121
        string $indexBy = null
122
    ): DqlQueryBuilderInterface {
123
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...lderInterface::leftJoin of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
124
    }
125
126
    public function where(string $predicates): DqlQueryBuilderInterface
127
    {
128
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...BuilderInterface::where of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
129
    }
130
131
    public function andWhere(string $predicates): DqlQueryBuilderInterface
132
    {
133
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...lderInterface::andWhere of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
134
    }
135
136
    public function orWhere(string $predicates): DqlQueryBuilderInterface
137
    {
138
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...ilderInterface::orWhere of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
139
    }
140
141
    public function groupBy(string $groupBy): DqlQueryBuilderInterface
142
    {
143
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...ilderInterface::groupBy of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
144
    }
145
146
    public function addGroupBy(string $groupBy): DqlQueryBuilderInterface
147
    {
148
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...erInterface::addGroupBy of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
149
    }
150
151
    public function having(string $having): DqlQueryBuilderInterface
152
    {
153
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...uilderInterface::having of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
154
    }
155
156
    public function andHaving(string $having): DqlQueryBuilderInterface
157
    {
158
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...derInterface::andHaving of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
159
    }
160
161
    public function orHaving(string $having): DqlQueryBuilderInterface
162
    {
163
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...lderInterface::orHaving of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
164
    }
165
166
    public function orderBy(string $sort, string $order = null): DqlQueryBuilderInterface
167
    {
168
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...ilderInterface::orderBy of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
169
    }
170
171
    public function addOrderBy(string $sort, string $order = null): DqlQueryBuilderInterface
172
    {
173
        return $this->addFilter(__METHOD__, \func_get_args());
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->addFilter(...D__, \func_get_args()); (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...erInterface::addOrderBy of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
174
    }
175
176
    public function useScalarHydration(): DqlQueryBuilderInterface
177
    {
178
        $this->hydrationMode = AbstractQuery::HYDRATE_SCALAR;
179
180
        return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (Acme\App\Infrastructure\...octrine\DqlQueryBuilder) is incompatible with the return type declared by the interface Acme\App\Core\Port\Persi...ace::useScalarHydration of type self.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
181
    }
182
183
    private function addFilter(string $methodName, array $args): DqlQueryBuilderInterface
184
    {
185
        $this->filters[] = [$methodName, $args];
186
187
        return $this;
188
    }
189
190
    private function reset(): void
191
    {
192
        $this->filters = [];
193
        $this->hydrationMode = AbstractQuery::HYDRATE_OBJECT;
194
    }
195
}
196