Magento architect Anton Kril asked about opinions on XML based tests:
My answer does not fit into a Tweet, so here’s a short blog post. Continue reading “My Opinion on XML Based Testing in Magento”
Common convention for namespaces in PHP is to start with
Vendor\Package, capitalized (
CamelCase ) with “vendor” and “package” analogous to the composer package name.
There is a bad habit I see often, probably coming from the ZF1 and Pear days, where every word in the class name is a new sub namespace (and a new subdirectory), or child classes are moved into a namespace with the name of the parent class. All this is leading to deeply nested namespaces and class names that have no meaning without their namespace.
Examples from Zend Framework 1 (pseudo namespaces):
Zend_Db_Table_Row_Abstract an abstract base class for
Zend_Db_Table_Row, representing a database table row. There are also
Zend_Pdf_FileParser_Font_OpenType_TrueType a parser for true type font files. The class extends
Zend_Pdf_FileParser_Font_OpenType which extends
Zend_Pdf_FileParser_Font which extends
And a current example from Magento 2:
Magento\Catalog\Model\Product\Option\Type\File\Validator – A validator for product options of the type “file”
Continue reading “Sensible Namespaces in PHP”
Lately I’ve been advocating decoupling business logic from the framework (i.e. Magento) a lot.
This has multiple advantages:
- Benefit from test driven development (TDD) without having to mock a bunch of core classes.
- Possible reuse in different applications (for example Magento 1 and Magento 2)
- Having separated bounded contexts helps to view parts of the domain isolated and without distraction.
Even in chirurgic modifications that we often have to do in Magento projects, it is worth identifying the actual logic and extracting it from the actual Magento classes.
Let me demonstrate it with a real-world example:
Read more at integer-net.com →
“Helpers” are often used as convenient collection of functions. They are also a sign of bad design, and I want you to stop writing them. I’ll quote myself
In general, having classes named “Helper”, “Util” or similar just says “I have some functions that I don’t know where to put” and don’t make much sense as a class.
It’s not very object oriented. Not at all to be frank. The idea of object oriented programming is that there are objects that send each others messages. They have an active role in the system and are not just containers for data and code, which would be a very procedural way to see them.
So what would be the role of a helper? A butler maybe, that does not act on its own and will do anything you tell him. But to do that, he needs access to your whole household, your bank account and your car.
Continue reading “Stop using Helpers”
Here’s the next update with hopefully interesting questions ans answers on StackExchange!
This week something from programmers.stackexchange.com: