PHP Class Libraries: Design Patterns
After using them for many years I have recently been rewriting some of my existing class libraries (both due to their age and their growing inflexibility for current requirements):
- HTML Page Template
- HTML Tables
- HTML Forms
- Button Generation
- HTTP Requests
- Persistent Navigation
Most received only minor updates however for others I made some more major changes.
For rounded corner buttons I used to rely on PHP generating images using the GD Extension, I would stitch together the left corner of the image, repeat the middle section depending on the text width, and then stitch on the right corner, optionally adding in an icon as well. This worked well however with most modern browsers supporting CSS “border-radius”, and styling of submit buttons seemingly working more reliably cross platform images were nolonger needed and I switched to using regular HTML / CSS.
I used to try and embed all possible required functionality inside the “standard” class itself, and use function callbacks, function arguments, and return values to customise specific functionality depending on requirements for the particular page it was being used on. This approach however slowly started becoming less ideal as it got increasingly more complicated to cater for particular infrequently used edge cases. It also sometimes increased development time due to needing to work out how to incorporate the functionality properly into the “standard” class, and then test it, and potentially test other pages also using the class rather than just customising it for a specific page.
The rewritten class now relies more on the principle of “object inheritance” and uses PHPs “extends” functionality. As much as possible distinct operations e.g. generating navigation links, generating table titles, retrieving table data, generating table cells are all now separate “functions”.
This means that if any customisations are required for specific pages it is generally a much simpler / quicker case of just using the “extends” keyword to inherit the class functionality, and overwriting particular methods sometimes in combination with the “parent::” operator to retain existing functionality. This gives a lot more flexibility than just relying on specific pre supported functionality and customising more via augments, and callbacks.
I have written HTML form classes before however after writing them have usually not ended up using them and instead fallen back to using a standard template which I customise in multiple places for database record add/edit pages (which most of my forms are). I just never seemed to be able to get the balance right between writing a class that actually saved development time long term without being over complicated or too inflexible to cater for ever changing requirements, something which turned out to be even bigger problem for forms (generally requiring more customisations) than was required for tables.
I believe I may however have found the answer in terms of using object inheritance (as described above for the table class) which I am hoping will both cut down development time while at the same time being flexible enough (and flexible enough in a simple way, similar to my old fully customisable template based approach).
Note: Classes are not really usable as is, and are a work in progress. I have included them more to illustrate points made in the blog post.