Completed
Push — v2 ( 5d3e3a...8090aa )
by Joschi
22:56
created

ItemList::__construct()   A

Complexity

Conditions 1
Paths 1

Size

Total Lines 5
Code Lines 3

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 4
CRAP Score 1

Importance

Changes 0
Metric Value
cc 1
eloc 3
nc 1
nop 1
dl 0
loc 5
rs 9.4285
c 0
b 0
f 0
ccs 4
cts 4
cp 1
crap 1
1
<?php
2
3
/**
4
 * micrometa
5
 *
6
 * @category Jkphl
7
 * @package Jkphl\Micrometa
8
 * @subpackage Jkphl\Micrometa\Ports\Item
9
 * @author Joschi Kuphal <[email protected]> / @jkphl
10
 * @copyright Copyright © 2017 Joschi Kuphal <[email protected]> / @jkphl
11
 * @license http://opensource.org/licenses/MIT The MIT License (MIT)
12
 */
13
14
/***********************************************************************************
15
 *  The MIT License (MIT)
16
 *
17
 *  Copyright © 2017 Joschi Kuphal <[email protected]> / @jkphl
18
 *
19
 *  Permission is hereby granted, free of charge, to any person obtaining a copy of
20
 *  this software and associated documentation files (the "Software"), to deal in
21
 *  the Software without restriction, including without limitation the rights to
22
 *  use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
23
 *  the Software, and to permit persons to whom the Software is furnished to do so,
24
 *  subject to the following conditions:
25
 *
26
 *  The above copyright notice and this permission notice shall be included in all
27
 *  copies or substantial portions of the Software.
28
 *
29
 *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
30
 *  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
31
 *  FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
32
 *  COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
33
 *  IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
34
 *  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
35
 ***********************************************************************************/
36
37
namespace Jkphl\Micrometa\Ports\Item;
38
39
/**
40
 * Item list
41
 *
42
 * @package Jkphl\Micrometa
43
 * @subpackage Jkphl\Micrometa\Ports
44
 */
45
class ItemList implements ItemListInterface
46
{
47
    /**
48
     * Items
49
     *
50
     * @var ItemInterface[]
51
     */
52
    protected $items;
53
54
    /**
55
     * Internal pointer
56
     *
57
     * @var int
58
     */
59
    protected $pointer;
60
61
    /**
62
     * ItemList constructor
63
     *
64
     * @param ItemInterface[] $items Items
65
     */
66 1
    public function __construct(array $items = [])
67
    {
68 1
        $this->items = array_values($items);
69 1
        $this->pointer = 0;
70 1
    }
71
72
    /**
73
     * Return the current item
74
     *
75
     * @return ItemInterface Item
76
     */
77
    public function current()
78
    {
79
        return $this->items[$this->pointer];
80
    }
81
82
    /**
83
     * Move forward to next element
84
     *
85
     * @return void
86
     */
87
    public function next()
88
    {
89
        ++$this->pointer;
90
    }
91
92
    /**
93
     * Return the position of the current element
94
     *
95
     * @return mixed Position of the current element
96
     */
97
    public function key()
98
    {
99
        return $this->pointer;
100
    }
101
102
    /**
103
     * Checks if current position is valid
104
     *
105
     * @return boolean The current position is valid
106
     */
107
    public function valid()
108
    {
109
        return isset($this->items[$this->pointer]);
110
    }
111
112
    /**
113
     * Rewind the item list to the first element
114
     *
115
     * @return void
116
     */
117
    public function rewind()
118
    {
119
        $this->pointer = 0;
120
    }
121
122
    /**
123
     * Return an object representation of the item list
124
     *
125
     * @return \stdClass Micro information items
126
     * @api
127
     */
128
    public function toObject()
129
    {
130
        return new \stdClass();
131
    }
132
133
    /**
134
     * Return a JSON representation of the item list
135
     *
136
     * @return string Micro information items
137
     * @api
138
     */
139
    public function toJson()
140
    {
141
        return json_encode(new \stdClass());
142
    }
143
144
    /**
145
     * Return the first item, optionally of particular types
146
     *
147
     * @param array ...$types Item types
148
     * @return ItemInterface Item
149
     * @api
150
     */
151
    public function item(...$types)
152
    {
153
        return $this->items(...$types)[0];
154
    }
155
156
    /**
157
     * Filter the items by item type(s)
158
     *
159
     * @param array ...$types Item types
160
     * @return ItemListInterface Items matching the requested types
161
     * @api
162
     */
163
    public function filter(...$types)
164
    {
165
        return new static($this->items(...$types));
0 ignored issues
show
Bug Best Practice introduced by
The return type of return new static($this->items(...$types)); (Jkphl\Micrometa\Ports\Item\ItemList) is incompatible with the return type declared by the interface Jkphl\Micrometa\Ports\It...emListInterface::filter of type Jkphl\Micrometa\Ports\Item\ItemInterface[].

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...
166
    }
167
168
    /**
169
     * Return all items as an array, optionally filtered by item type(s)
170
     *
171
     * @param array ...$types Item types
172
     * @return ItemInterface[] Items matching the requested types
173
     * @api
174
     */
175
    public function items(...$types)
176
    {
177
        // If particular item types should be filtered
178
        if (count($types)) {
179
            return array_filter(
0 ignored issues
show
Bug Best Practice introduced by
The return type of return array_filter($thi...sOfType(...$types); }); (array) is incompatible with the return type declared by the interface Jkphl\Micrometa\Ports\It...temListInterface::items of type Jkphl\Micrometa\Ports\Item\ItemListInterface.

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...
180
                $this->items,
181
                function (ItemInterface $item) use ($types) {
182
                    return $item->isOfType(...$types);
183
                }
184
            );
185
        }
186
187
        return $this->items;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->items; (Jkphl\Micrometa\Ports\Item\ItemInterface[]) is incompatible with the return type declared by the interface Jkphl\Micrometa\Ports\It...temListInterface::items of type Jkphl\Micrometa\Ports\Item\ItemListInterface.

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...
188
    }
189
}
190