November 8, 2016
Creating SOLID (not STUPID) Plugins and Themes
A dive into the mistakes we as developers make and the best practices we can employ in object-oriented programming and design. We start with an example plugin and remove issues addressed using the STUPID principles. We then apply the five basic principles of SOLID design ending up with a word class WordPress plugin.
STUPID: (Singleton, Tight Coupling, Untestability, Premature Optimization, Indescriptive Naming, Duplication)
SOLID (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle)
November 10, 2016 at 12:48 pm |
Hi,
Great talk! Thanks for the video!
I understand that these principles applies heavily on plugins development.
But I would like to ask what do you think about using singletons in theme development? Here is example:
Let’s say your theme does not do anything complicated (as all the functionality should be in plugins, right? ;)) but you’ve decide to encapsulate the theme code into PHP classes. At least this eliminates/enhances the unique naming issue of your theme code (as you can simply name your classes uniquely – especially useful in a framework).
Now you create a class that outputs the theme assets. The next class would output the theme header, the other one outputs theme footer and so on.
Is there any particular reason why these classes shouldn’t use singleton pattern?
Thanks for the answer!
Regards,
Oliver
LikeLike