Completed
Push — master ( b035c8...ddcf44 )
by Paweł
02:10
created

FloatType::setValue()   B

Complexity

Conditions 10
Paths 11

Size

Total Lines 35

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 19
CRAP Score 10

Importance

Changes 0
Metric Value
cc 10
nc 11
nop 2
dl 0
loc 35
rs 7.6666
c 0
b 0
f 0
ccs 19
cts 19
cp 1
crap 10

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
declare(strict_types=1);
3
4
namespace Wszetko\Sitemap\Items\DataTypes;
5
6
use Wszetko\Sitemap\Interfaces\DataType;
7
8
/**
9
 * Class FloatType
10
 *
11
 * @package Wszetko\Sitemap\Items\DataTypes
12
 */
13
class FloatType extends AbstractDataType
14
{
15
    /**
16
     * @var int|float
17
     */
18
    private $minValue;
19
20
    /**
21
     * @var int|float
22
     */
23
    private $maxValue;
24
25
    /**
26
     * @var int
27
     */
28
    protected $precision = null;
29
30
    /**
31
     * @return float|null
32
     */
33 7
    public function getMinValue(): ?float
34
    {
35 7
        return $this->minValue;
36
    }
37
38
    /**
39
     * @param float $minValue
40
     *
41
     * @return \Wszetko\Sitemap\Items\DataTypes\FloatType
42
     */
43 33
    public function setMinValue(float $minValue): self
44
    {
45 33
        $this->minValue = $minValue;
46
47 33
        return $this;
48
    }
49
50
    /**
51
     * @return float|null
52
     */
53 7
    public function getMaxValue(): ?float
54
    {
55 7
        return $this->maxValue;
56
    }
57
58
    /**
59
     * @param float $maxValue
60
     *
61
     * @return \Wszetko\Sitemap\Items\DataTypes\FloatType
62
     */
63 33
    public function setMaxValue(float $maxValue): self
64
    {
65 33
        $this->maxValue = $maxValue;
66
67 33
        return $this;
68
    }
69
70
    /**
71
     * @return int|null
72
     */
73 7
    public function getPrecision(): ?int
74
    {
75 7
        return $this->precision;
76
    }
77
78
    /**
79
     * @param int $precision
80
     *
81
     * @return \Wszetko\Sitemap\Items\DataTypes\FloatType
82
     */
83 33
    public function setPrecision(int $precision): self
84
    {
85 33
        $this->precision = $precision;
86
87 33
        return $this;
88
    }
89
90
    /**
91
     * @param int|float|string|null $value
92
     * @param array                 $parameters
93
     *
94
     * @return \Wszetko\Sitemap\Interfaces\DataType
95
     */
96 7
    public function setValue($value, ...$parameters): DataType
97
    {
98 7
        if (is_null($value)) {
99 1
            $this->value = null;
100
101 1
            return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (Wszetko\Sitemap\Items\DataTypes\FloatType) is incompatible with the return type declared by the interface Wszetko\Sitemap\Interfaces\DataType::setValue 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...
102
        }
103
104 7
        if (is_string($value)) {
105 3
            if (is_numeric($value)) {
106 3
                $value = floatval($value);
107
            } else {
108 3
                return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (Wszetko\Sitemap\Items\DataTypes\FloatType) is incompatible with the return type declared by the interface Wszetko\Sitemap\Interfaces\DataType::setValue 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...
109
            }
110 7
        } elseif (!is_numeric($value)) {
111 3
            return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (Wszetko\Sitemap\Items\DataTypes\FloatType) is incompatible with the return type declared by the interface Wszetko\Sitemap\Interfaces\DataType::setValue 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...
112
        }
113
114 7
        if ($this->getMinValue() !== null && $value < $this->getMinValue()) {
115 3
            return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (Wszetko\Sitemap\Items\DataTypes\FloatType) is incompatible with the return type declared by the interface Wszetko\Sitemap\Interfaces\DataType::setValue 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...
116
        }
117
118 7
        if ($this->getMaxValue() !== null && $value > $this->getMaxValue()) {
119 3
            return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (Wszetko\Sitemap\Items\DataTypes\FloatType) is incompatible with the return type declared by the interface Wszetko\Sitemap\Interfaces\DataType::setValue 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...
120
        }
121
122 7
        if ($this->getPrecision()) {
0 ignored issues
show
Bug Best Practice introduced by
The expression $this->getPrecision() of type integer|null is loosely compared to true; this is ambiguous if the integer can be zero. You might want to explicitly use !== null instead.

In PHP, under loose comparison (like ==, or !=, or switch conditions), values of different types might be equal.

For integer values, zero is a special case, in particular the following results might be unexpected:

0   == false // true
0   == null  // true
123 == false // false
123 == null  // false

// It is often better to use strict comparison
0 === false // false
0 === null  // false
Loading history...
123 5
            $value = round($value, $this->getPrecision());
124 5
            $value = number_format($value, $this->getPrecision(), '.', '');
125
        }
126
127 7
        parent::setValue($value, $parameters[0]);
128
129 7
        return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (Wszetko\Sitemap\Items\DataTypes\FloatType) is incompatible with the return type declared by the interface Wszetko\Sitemap\Interfaces\DataType::setValue 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...
130
    }
131
}