<h5><span style="color: green;">The good</span></h5>
<ul>
<li>array() is php built-in type</li>
<li>popular in PHP world</li>
<li>maps easily to Zend\Config-style configuration</li>
<li>can silently ignore unknown parameters <sup>used together with adapter-pattern</sup></li>
</ul>
<h5><span style="color: red;">The bad</span></h5>
<ul>
<li>does not hint at what config params are available</li>
<li>(usually) silently ignores unknown parameters</li>
<li>validation may be performed every time instance is created <em>(note: a number of components do not validate config options but rely on native error reporting of PHP functions)</em></li>
<li>requires multiple accessors to manage all config options <em>(note from Matthew: depends on the architecture of the component; not all delegate to accessors)</em></li>
<li>not all config options can be modified at runtime because of lack of accessors (if forgotten/omitted deliberately)</li>
<li>no way to enforce hard-dependencies at language level (inter-component)</li>
<li>Requires accessors to change or read configuration (even for simple, not validated scalar values)</li>
<li>Accessor dependence can result in injecting configured objects into their depedencies to share configuration (breaches single responsibility principle/separation of concerns and Law of Demeter).</li>
</ul>
<h5><span style="color: green;">The good</span></h5>
<ul>
<li>we can enforce hard-dependencies</li>
<li>we retain familiar array-style for optional dependencies</li>
</ul>
<h5><span style="color: red;">The bad</span> <span style="color: gray;">(repeated ones in gray; see notes from previous section as well)</span></h5>
<ul>
<li>component will refuse to work without hard-dependencies <sup>(no way to include defaults without Dependency Injection)</sup></li>
<li>validation of soft-parameters is performed every time instance is created</li>
<li><span style="color: gray;">does not hint on what config params are available</span></li>
<li><span style="color: gray;">(usually) silently ignores unknown parameters</span></li>
<li><span style="color: gray;">requires multiple accessors to manage all config options</span></li>
<li><span style="color: gray;">not all config options can be modified at runtime because of lack of accessors (if forgotten/omitted deliberately)</span></li>
<li><span style="color: gray;">Requires accessors to change or read configuration (even for simple, not validated scalar values)</span></li>
<li><span style="color: gray;">Accessor dependence can result in injecting configured objects into their depedencies to share configuration (breaches single responsibility principle/separation of concerns and Law of Demeter).</span></li>
</ul>
]]></ac:plain-text-body></ac:macro>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$config = new Zend\Component\Config();
$config->optionA = 1;
$config->optionB = 2;
$component = new Zend\Component($config);
// – or directly if we know available config params and want to create from array –
$config = new Zend\Component\Config(array(
'optionA' => 1,
'optionB' => 2,
));
$component = new Zend\Component($config);
// – or directly on the constructor –
$component = new Zend\Component(array(
'optionA' => 1,
'optionB' => 2,
));
]]></ac:plain-text-body></ac:macro>
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[
$component = new Zend\Component($config); // ... will instantiate adapter when needed
]]></ac:plain-text-body></ac:macro>
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[
<h5><span style="color: green;">The good</span></h5>
<ul>
<li>hinting of config parameters in IDEs (even with detailed usage info)</li>
<li>all config-parameters are named and can be given default values</li>
<li>config-classes can be subclassed to introduce defaults (or some custom processing)</li>
<li>validation is performed by config class, not functional class (SoC)</li>
<li>validation is performed once per config (as opposed to once per instance)</li>
<li>configuration can be referred (shared) among instances</li>
<li>backward-compatible with array configuration</li>
<li>easier documentation generation</li>
<li>DI-friendly</li>
<li>Can be treated as a generic "parameter bag" (configuration not necessarily bound to one object alone. e.g. shareable with adapters).</li>
<li>Supports both access styles: public params (which are simple, fast) and setters (if validation is required) (<a href="http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+better+configuration+for+components">examples here</a>)</li>
</ul>
<h5><span style="color: red;">The bad</span></h5>
<ul>
<li>no way to enforce hard-dependencies via PHP's type-checking</li>
<li>more memory required per-configuration blob</li>
<li>increased code verbosity compared to arrays if using object setters/getters (though this is the same scenario if using setters/getters on the created main object)</li>
</ul>
This style is important with sub-objects (adapters, providers, renderers...)
--> See "with adapters"
*/
$config = new Zend\Component\Config();
$config->optionA = 1;
$config->optionB = 2;
$component = new Zend\Component($config);
// – or directly if we know available config params and want to create from array –
$config = new Zend\Component\Config(array(
'optionA' => 1,
'optionB' => 2,
));
$component = new Zend\Component($config);
// – or directly on the constructor –
$component = new Zend\Component(array(
'optionA' => 1,
'optionB' => 2,
));
]]></ac:plain-text-body></ac:macro>
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[
]]></ac:plain-text-body></ac:macro>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
// constructor :
class Component
{
/**
@param Adapter $adapter Hard-dependency, adapter to use
@param Config|null $config Config object holding all parameters or null to use defaults.
*/
function __construct(Adapter $adapter, Config $config = null)
}
$adapterConfig = new Zend\Component\Adapter\AdapterType\Config();
$adapterConfig->adapterOptA = 'foo';
$adapterConfig->adapterOptB = 'bar';
$adapter = new Zend\Component\Adapter\AdapterType($adapterConfig);
$config = new Zend\Component\Config();
$config->optionA = 1;
$config->optionB = 2;
$component = new Zend\Component($adapter, $config);
]]></ac:plain-text-body></ac:macro>
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[
<h5><span style="color: green;">The good</span> </h5>
<ul>
<li>hard-dependencies can be enforced at compiler-level</li>
<li><span style="color: gray;">hinting of config parameters in IDEs (even with detailed usage info)</span></li>
<li><span style="color: gray;">all config-parameters are named and can be given default values</span></li>
<li><span style="color: gray;">config-classes can be subclassed to introduce defaults (or some custom processing)</span></li>
<li><span style="color: gray;">validation is performed by config class, not functional class (SoC)</span></li>
<li><span style="color: gray;">validation is performed once per config (as opposed to once per instance)</span></li>
<li><span style="color: gray;">configuration can be referred (shared) among instances</span></li>
<li><span style="color: gray;">backward-compatible with array configuration</span></li>
<li><span style="color: gray;">easier documentation generation</span></li>
<li><span style="color: gray;">DI-friendly</span></li>
<li><span style="color: gray;">Can be treated as a generic "parameter bag" (configuration not necessarily bound to one object alone. e.g. shareable with adapters).</span></li>
<li><span style="color: gray;">Supports both access styles: public params (which are simple, fast) and setters (if validation is required) (<a href="http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+better+configuration+for+components">examples here</a>)</span></li>
</ul>
<h5><span style="color: red;">The bad</span></h5>
<ul>
<li>component will refuse to work without satisfying hard-dependencies <sup>(no way to include "default adapter" without Dependency Injection)</sup></li>
<li><span style="color: gray;">more memory required per-configuration blob</span></li>
<li><span style="color: gray;">increased code verbosity compared to arrays if using object setters/getters (though this is the same scenario if using setters/getters on the created main object)</span></li>
</ul>