ExtraLazyRpcClient::__construct()   A
last analyzed

Complexity

Conditions 1
Paths 1

Size

Total Lines 4
Code Lines 2

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 3
CRAP Score 1

Importance

Changes 1
Bugs 0 Features 0
Metric Value
c 1
b 0
f 0
dl 0
loc 4
ccs 3
cts 3
cp 1
rs 10
cc 1
eloc 2
nc 1
nop 1
crap 1
1
<?php
2
3
namespace ScayTrase\Api\Rpc\Decorators;
4
5
use ScayTrase\Api\Rpc\RpcClientInterface;
6
7
final class ExtraLazyRpcClient implements RpcClientInterface
8
{
9
    /** @var ExtraLazyResponseCollection */
10
    private $lazyCollection;
11
    /** @var LazyRpcClient */
12
    private $client;
13
14
    /**
15
     * ExtraLazyRpcClient constructor.
16
     *
17
     * @param RpcClientInterface $client
18
     */
19 4
    public function __construct(RpcClientInterface $client)
20
    {
21 4
        $this->client = new LazyRpcClient($client);
22 4
    }
23
24
    /** {@inheritdoc} */
25 4
    public function invoke($calls)
26
    {
27 4
        $collection = $this->client->invoke($calls);
28
29 4
        if (!$this->lazyCollection || $this->lazyCollection->getInnerCollection() !== $collection) {
30 4
            $this->lazyCollection = new ExtraLazyResponseCollection($collection);
0 ignored issues
show
Compatibility introduced by
$collection of type object<ScayTrase\Api\Rpc...nseCollectionInterface> is not a sub-type of object<ScayTrase\Api\Rpc...LazyResponseCollection>. It seems like you assume a concrete implementation of the interface ScayTrase\Api\Rpc\ResponseCollectionInterface to be always present.

This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass.

Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type.

Loading history...
31 4
        }
32
33 4
        return $this->lazyCollection;
34
    }
35
}
36