AbstractReflectionClassMetadataLoader::loadData()   C
last analyzed

Complexity

Conditions 11
Paths 100

Size

Total Lines 46
Code Lines 25

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 29
CRAP Score 11.0324

Importance

Changes 0
Metric Value
dl 0
loc 46
ccs 29
cts 31
cp 0.9355
rs 5.2653
c 0
b 0
f 0
cc 11
eloc 25
nc 100
nop 1
crap 11.0324

How to fix   Complexity   

Long Method

Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.

For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.

Commonly applied refactorings include:

1
<?php
2
3
/*
4
 * This file is part of the Ivory Serializer package.
5
 *
6
 * (c) Eric GELOEN <[email protected]>
7
 *
8
 * For the full copyright and license information, please read the LICENSE
9
 * file that was distributed with this source code.
10
 */
11
12
namespace Ivory\Serializer\Mapping\Loader;
13
14
/**
15
 * @author GeLo <[email protected]>
16
 */
17
abstract class AbstractReflectionClassMetadataLoader extends AbstractClassMetadataLoader
18
{
19
    /**
20
     * @param \ReflectionProperty $property
21
     *
22
     * @return mixed[]|null
23
     */
24
    abstract protected function loadProperty(\ReflectionProperty $property);
25
26
    /**
27
     * {@inheritdoc}
28
     */
29 1288
    protected function loadData($class)
30
    {
31 1288
        $reflection = new \ReflectionClass($class);
32 1288
        $result = $this->loadClass($reflection);
33 1288
        $properties = [];
34
35 1288
        foreach ($reflection->getMethods() as $method) {
36 1276
            if ($method->class !== $class) {
37
                continue;
38
            }
39
40 1276
            if (($methodName = $this->validateMethod($method->name)) === null) {
41 1276
                continue;
42
            }
43
44 504
            $data = $this->loadMethod($method);
45
46 504
            if (is_array($data)) {
47 286
                $properties[$methodName] = $data;
48 34
            }
49 644
        }
50
51 1288
        foreach ($reflection->getProperties() as $property) {
52 1276
            if ($property->class !== $class) {
53
                continue;
54
            }
55
56 1276
            $data = $this->loadProperty($property);
57
58 1276
            if (is_array($data)) {
59 1276
                $name = $property->getName();
60
61 1276
                $properties[$name] = isset($properties[$name])
62 672
                    ? array_merge_recursive($properties[$name], $data)
63 672
                    : $data;
64 638
            }
65 644
        }
66
67 1288
        if (!empty($properties)) {
68 1276
            $result['properties'] = $properties;
69 638
        }
70
71 1288
        if (!empty($result)) {
72 1276
            return $result;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $result; (array) is incompatible with the return type declared by the abstract method Ivory\Serializer\Mapping...etadataLoader::loadData of type array|null.

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...
73
        }
74 12
    }
75
76
    /**
77
     * @param \ReflectionClass $class
78
     *
79
     * @return mixed[]
80
     */
81 1288
    protected function loadClass(\ReflectionClass $class)
82
    {
83 1288
        return [];
84
    }
85
86
    /**
87
     * @param \ReflectionMethod $method
88
     *
89
     * @return mixed[]|null
90
     */
91 480
    protected function loadMethod(\ReflectionMethod $method)
92
    {
93 480
    }
94
95
    /**
96
     * @param string $method
97
     *
98
     * @return string|null
99
     */
100 1276
    private function validateMethod($method)
101
    {
102 1276
        $prefix = substr($method, 0, 3);
103
104 1276
        if ($prefix === 'get' || $prefix === 'set' || $prefix === 'has') {
105 504
            return lcfirst(substr($method, 3));
106
        }
107
108 1276
        $prefix = substr($prefix, 0, 2);
109
110 1276
        if ($prefix === 'is') {
111 200
            return lcfirst(substr($method, 2));
112
        }
113 1276
    }
114
}
115