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
Updated 3 restaurants
I walked 3.1km in 29m25s
I walked 4.4km in 45m01s
I walked 5.4km in 55m28s
Updated a restaurant; Confirmed a hotel
I walked 6.3km in 1h12m59s
Paraphrasing opening keynote speaker at ConFoo: "Should we go back to the waterfall method of writing massive specs upfront to feed to AI coding agents?"
I walked 1.6km in 17m29s
I walked 2.1km in 17m44s
Updated a pub
I walked 2.6km in 26m41s
Merged pull request #1065
Comparison whether class is userland or internal used the wrong macro
PHP 8.6: zend_enum.h now mixes code with declarations
PHP 8.6: Argument names are now stored as zend_strings
Updated a bench and a waste_basket
I walked 8.3km in 1h25m37s
Created a recycling
I walked 10.5km in 1h46m57s
An interesting journey in story form, showing how English changed over time.
https://www.deadlanguagesociety.com/p/how-far-back-in-time-understand-english
A much better writer than I is summing up perfectly why I have such disdain for Generative AI/LLMs.
https://jonn.substack.com/p/so-why-do-i-feel-so-angry-about-this
Created a waste_basket; Updated a waste_basket; Deleted a bench
Created a bench; Updated 7 benches and a gate; Deleted 2 benches and a gate
Created 10 benches and 2 waste_baskets; Updated an information


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