OOP-builder "massive" parameters

Many frameworks love magic and complex multi-level arrays to pass parameters. That the first, that the second is evil from the point of view of a truly lazy programmer who loves IDE and the docks are always at hand, rather than poking into the Internet / body of the called method. We can defeat this as a sample by taking method parameters from one framework and creating an OOP builder.

What is a “massive” parameter?

This is a parameter that a certain system forces us to have in the form of an array of a certain structure. This is not YAML and not XML, but the associative array of a certain complex structure.

What for?

Tar "massive" parameters

We do not have documentation here and now. We can make a mistake in writing the key and do not understand it right away. In order to add a key that we do not know / have forgotten, you need to open the docks. We do not use bare SQL, where it is quite easy to replace it with AR `s or with the same query builder` s in 90% of cases of banal CRUD operations? In general, bare arrays are more computer-oriented than convenient for tracking people.

Where did they come from?

There is a hypothesis that at first any framework is the maximum config connection to the database - what's so complicated? Never mind! But then it begins to grow into one, the other, the third, etc. It turns out a multi-level monster, in order to understand which, you need to jump here and there in the help. Similarly, when the authors do not have enough imagination to make a flexible interface when calling the method, they all come to the same arrays.
')

Authorities speak to the topic

Write programs primarily for people and only the second for computers.
Steve mcconnell

What ultimately improves our clarity, facilitates changes and debugging. Even when we work in the same project - context switching takes place.

But what about the overhead on all these OOPs?

Of course you will say - but what about us on the production overhead? Obviously, the bare array is faster than a certain builder. To this you can answer that people invented caching, tmpfs, builds, etc. - this is not a real problem. For example, very few people in their right mind give away uncompressed js / css or do not use opcode cache on a loaded resource. So, different deployment hooks are also possible here, which generate ready-made files or caching in the style:

$result = $someConfig->getFromCache(__FILE__ . __LINE__) or $result = $someConfig->...->get(); 

And still

When developing, we should focus on the task, not on reading the docks. Similarly, if we switch to a new framework, it is much easier for us to understand the code and its details in place, rather than reading the docks. Rather, we will read docks - but they will be where they are needed and when they are needed - for example, when you hover on a method.

What does it look like?

 //   --       $conditions = array( 'conditions' => array( 'Model.field' => 123, 'Model.field5 BETWEEN ? AND ?' => array(5, 5), 'Model.field8 NOT LIKE' => '%8%', ), 'recursive' => 1, 'fields' => array('Model.field1', 'DISTINCT Model.field2'), 'order' => array('Model.created', 'Model.field3 DESC'), 'group' => array('Model.field'), 'limit' => 100, 'page' => 1, 'offset' => 10, 'callbacks' => true, ); // -- --     ,          $conditions = $this->findParams ->conditions ->is('Model.field', 123) ->between('Model.field5', 5, 5) ->notLike('Model.field8', '%8%') ->up() ->recursive(1) ->fields('Model.field1', 'DISTINCT Model.field2') ->order('Model.created', 'Model.field3 DESC') ->group('Model.field') ->limit(100)->page(1)->offset(10) ->callbacks(true) ->get() ; 

Fig. 1. In the auto-add-on we see all the possible parameters and here - their descriptions. In yaml, xml, raw arrays, we don't have all this.

How is it arranged and where is it to feel?

Sources on github: main module and module for CakePHP . The example for CakePHP is simply taken as the first available one. This is not a query-builder, but rather an array-param-builder. Something like a wrapper over a monstrous parameter of one of the methods.
Code examples in tests that can be run by phpunit from the project root:

• github.com/garex/oopconfig/blob/develop/tests/OopConfig/SomeConfigTest.php
• github.com/garex/oopconfig-cakephp/blob/develop/tests/CakePHP/FindParamsTest.php

Expansion is possible for any subject area - see the CakePHP module as a sample. Current versions are far from production-quality and are more a concept than a ready-made tool. However, infrastructure and expansion points are present.

Changelog

title: Config with a human face? Bilder! OOP-builder "massive" parameters
content: Entered the concept of "massive" parameter, removed the concept of "config"