Completed
Pull Request — master (#77)
by Michael
11:21
created

XoopsHandlerRegistry::getInstance()   A

Complexity

Conditions 2
Paths 2

Size

Total Lines 8
Code Lines 5

Duplication

Lines 0
Ratio 0 %

Importance

Changes 1
Bugs 0 Features 0
Metric Value
c 1
b 0
f 0
dl 0
loc 8
rs 9.4285
cc 2
eloc 5
nc 2
nop 0
1
<?php
0 ignored issues
show
Coding Style Compatibility introduced by
For compatibility and reusability of your code, PSR1 recommends that a file should introduce either new symbols (like classes, functions, etc.) or have side-effects (like outputting something, or including other files), but not both at the same time. The first symbol is defined on line 28 and the first side effect is on line 18.

The PSR-1: Basic Coding Standard recommends that a file should either introduce new symbols, that is classes, functions, constants or similar, or have side effects. Side effects are anything that executes logic, like for example printing output, changing ini settings or writing to a file.

The idea behind this recommendation is that merely auto-loading a class should not change the state of an application. It also promotes a cleaner style of programming and makes your code less prone to errors, because the logic is not spread out all over the place.

To learn more about the PSR-1, please see the PHP-FIG site on the PSR-1.

Loading history...
2
/**
3
 * XOOPS Kernel Class
4
 *
5
 * You may not change or alter any portion of this comment or credits
6
 * of supporting developers from this source code or any supporting source code
7
 * which is considered copyrighted (c) material of the original comment or credit authors.
8
 * This program is distributed in the hope that it will be useful,
9
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
10
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
11
 *
12
 * @copyright       (c) 2000-2016 XOOPS Project (www.xoops.org)
13
 * @license             GNU GPL 2 (http://www.gnu.org/licenses/gpl-2.0.html)
14
 * @package             kernel
15
 * @since               2.0.0
16
 * @author              Kazumi Ono (AKA onokazu) http://www.myweb.ne.jp/, http://jp.xoops.org/
17
 */
18
defined('XOOPS_ROOT_PATH') || exit('Restricted access');
19
20
/**
21
 * A registry for holding references to {@link XoopsObjectHandler} classes
22
 *
23
 * @package             kernel
24
 *
25
 * @author              Kazumi Ono    <[email protected]>
26
 * @copyright       (c) 2000-2016 XOOPS Project (www.xoops.org)
27
 */
28
class XoopsHandlerRegistry
29
{
30
    /**
31
     * holds references to handler class objects
32
     *
33
     * @var array
34
     * @access    private
35
     */
36
    public $_handlers = array();
37
38
    /**
39
     * Deprecated, use getInstance() instead
40
     */
41
    public function instance()
42
    {
43
        return XoopsHandlerRegistry::getInstance();
0 ignored issues
show
Coding Style introduced by
As per coding style, self should be used for accessing local static members.

This check looks for accesses to local static members using the fully qualified name instead of self::.

<?php

class Certificate {
    const TRIPLEDES_CBC = 'ASDFGHJKL';

    private $key;

    public function __construct()
    {
        $this->key = Certificate::TRIPLEDES_CBC;
    }
}

While this is perfectly valid, the fully qualified name of Certificate::TRIPLEDES_CBC could just as well be replaced by self::TRIPLEDES_CBC. Referencing local members with self:: assured the access will still work when the class is renamed, makes it perfectly clear that the member is in fact local and will usually be shorter.

Loading history...
44
    }
45
    
46
    
47
    /**
48
     * get a reference to the only instance of this class
49
     *
50
     * if the class has not been instantiated yet, this will also take
51
     * care of that
52
     *
53
     * @static
54
     * @staticvar   object  The only instance of this class
55
     * @return XoopsHandlerRegistry Reference to the only instance of this class
56
     */
57
    public static function getInstance()
58
    {
59
        static $instance;
60
        if (!isset($instance)) {
61
            $instance = new static();
62
        }
63
        return $instance;
64
    }
65
66
    /**
67
     * Register a handler class object
68
     *
69
     * @param string $name     Short name of a handler class
70
     * @param XoopsObjectHandler &$handler {@link XoopsObjectHandler} class object
71
     */
72
    public function setHandler($name, XoopsObjectHandler $handler)
73
    {
74
        $this->_handlers['kernel'][$name] =& $handler;
75
    }
76
77
    /**
78
     * Get a registered handler class object
79
     *
80
     * @param string $name Short name of a handler class
81
     *
82
     * @return XoopsObjectHandler {@link XoopsObjectHandler}, FALSE if not registered
83
     */
84
    public function getHandler($name)
85
    {
86
        if (!isset($this->_handlers['kernel'][$name])) {
87
            return false;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return false; (false) is incompatible with the return type documented by XoopsHandlerRegistry::getHandler of type XoopsObjectHandler.

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...
88
        }
89
90
        return $this->_handlers['kernel'][$name];
91
    }
92
93
    /**
94
     * Unregister a handler class object
95
     *
96
     * @param string $name Short name of a handler class
97
     */
98
    public function unsetHandler($name)
99
    {
100
        unset($this->_handlers['kernel'][$name]);
101
    }
102
103
    /**
104
     * Register a handler class object for a module
105
     *
106
     * @param string $module   Directory name of a module
107
     * @param string $name     Short name of a handler class
108
     * @param XoopsObjectHandler &$handler {@link XoopsObjectHandler} class object
109
     */
110
    public function setModuleHandler($module, $name, XoopsObjectHandler $handler)
111
    {
112
        $this->_handlers['module'][$module][$name] =& $handler;
113
    }
114
115
    /**
116
     * Get a registered handler class object for a module
117
     *
118
     * @param string $module Directory name of a module
119
     * @param string $name   Short name of a handler class
120
     *
121
     * @return XoopsObjectHandler {@link XoopsObjectHandler}, FALSE if not registered
122
     */
123
    public function getModuleHandler($module, $name)
124
    {
125
        if (!isset($this->_handlers['module'][$module][$name])) {
126
            return false;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return false; (false) is incompatible with the return type documented by XoopsHandlerRegistry::getModuleHandler of type XoopsObjectHandler.

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...
127
        }
128
129
        return $this->_handlers['module'][$module][$name];
130
    }
131
132
    /**
133
     * Unregister a handler class object for a module
134
     *
135
     * @param string $module Directory name of a module
136
     * @param string $name   Short name of a handler class
137
     */
138
    public function unsetModuleHandler($module, $name)
139
    {
140
        unset($this->_handlers['module'][$module][$name]);
141
    }
142
}
143