Embrace Inheritance
In the last week I've been working on writing a tutorial for our MvcTools component. For this tutorial I've also written a very simple "HelloMvc" application , not only to have something to write the tutorial about, but also to test how the component would do in a more real life situation, outside of the unit testing framework.
I realized during the development of this sample application, is that while writing software, you can never really implement things so that it does exactly what everybody wants and expects. During the development of our MvcTools component we're run into a few of those occasions. One of those is the naming conventions our default controller uses for action's methods. In our first implementation we would always require the method naming of "doActionName()".
Some of our users might want to do something else, but would now have to rewrite the whole class. That is of course unnecessary, as Object Oriented programming excels at reuse of code. However, in order for inheritance to work, all the functionality need to be separated as much as possible into their own methods.
In the re-factored version we now have split out the method name algorithm to its own method, createActionMethodName(). This allows for easier customization of code by inheriting from this class and just overriding this method. It also makes testing easier, as now it is possible to test the name generating algorithm. To illustrate this, we actually found an issue while writing the tests for this new method.
Comments
Hi Derick! I would have some notes on the second solution:
-
I am not sure if it is a good practice to automatically expand the request into variables. For first view maybe it can confuse somebody reading an action code, but of course it is not a big issue while the programmer should know that this is how this framework works. But I think it is much useful if these variables are used for the following purpose: if you set a variables it will be automatically accessible in the view layer.
-
I usually don't like to modify the request, just validate it, and if it is not valid pass back to the user. So I am not sure if it is neat that preg_replace in creating the action name. And maybe it would be logical to do it the dev mode section.
-
While the class's own methods are all protected maybe it would be sexier to define a __call method which throw the not found exception. And it would be faster for the normal flow while not the bad case is the general.
Life Line
I know my French is pretty terrible, but I'm sure I'm closer to the correct answer than what's shown here...
Merge branch 'v2022'
Merge pull request #169 from psumbera/solaris-2
I walked 7.0km in 1h6m48s
Fixed some ffing sidewalks again.
I walked 10.5km in 1h40m26s
Updated a pet_grooming shop
I walked 8.6km in 2h12m58s
I walked 8.7km in 1h24m16s
Updated a restaurant
I walked 2.4km in 24m20s
I walked 6.6km in 1h4m32s
I walked 0.6km in 4m38s
I walked 8.5km in 1h22m35s
Merged pull request #1029
Reflow some comments
Add comments, add end of file newlines, fix php 8.5 compilation
Benchmark Xdebug performance
Merged pull request #1051
PHP 8.6: printf() is now optimised out if it only uses %s and %d (and…
PHP 8.6: The object IDs of objects changed in tests
PHP 8.6: ZSTR_INIT_LITERAL() no longer takes non-literals, so use zen…
PHP 8.6: WRONG_PARAM_COUNT has been removed in favour of zend_wrong_p…
PHP 8.6: zval_dtor() has been deprecated in favour of zval_ptr_dtor_n…
Update test for version constraints, as well as the error messages


Shortlink
This article has a short URL available: https://drck.me/ei-6i2