A PHP design pattern that is not OO, PHP pattern best suited to this situation

Question

We were given a php inventory program. We are then supposed to say if a design pattern will make the program better or if it will just make the program more complicated.

The program is structured like this.

The program is broken down into php scripts embedded with html. Either there is (A) one entire php page dedicated to one option, or (B) an option’s logic is inside another script page that serves for other options of a similar action. (This excludes simple buttons such as “Reset” and “Back to Home.”)

(A) For example, once you open the website, a navigation menu appears with options. When you click an option, say under Customer, there is a “View” link. Once clicked, you are taken to another page that includes other links that corresponds to more options, such as “Edit” and “Delete”. Usually, for this website, each option corresponds to its own php script page. For example, “View” corresponds to list_customers.php. “Edit” corresponds to edit_customer.php.

(B) The other thing that could happen is that the logic for that option is in a “generalized” script page. What I mean by that is that several options’ logic are grouped into one page. An example of this is “Delete.” Before one may delete a customer, a job order, or a quotation, one is directed to a php script page called auth.php to make sure that only the admin may delete. The logic for checking if it’s the admin logging in AND for deleting a customer, a job order, or a quotation is also in auth.php. Another example is all the “Search” option for Customer. Although it has its own page, search_customer.php, the logic for the actually searching is actually in list_customers.php. This pattern follows for all searches, including search for customers, for quotations, or delivery reports; the searching code is actually in the corresponding list_*.php page.

I am finding a hard time finding a design pattern that will not make it more complicated. Most of the ones I find are geared for OO paradigms, and this inventory certainly is not. The Factory Pattern certainly won't help since the only useful way I found it for is if the log in (username and password) changes to something like (username, password, id no.). However, I thought that won't be useful since only 2 php pages have login functionality.

I also looked to see if all the searching logic can be made into a single object. But then, each type of search will have to have it's own method (since they are querying diff. tables), and that wont be much different from the current setup (each search is currently in the corresponding list php page.)

The only thing I found that might be useful is a design patter for regular expressions. The forms in the program are not validated. Do you have any ideas here?

Furthermore, the topic of the class is Software Quality. My personal opinion is that a design patter will make this website more complicated, since it is not such a big project. But my classmates argue that since it's not OO, it is not as maintainable. But I was thinking, PHP was made as not OO, am I correct? So forcing it to conform to an OO design pattern will just mess things up.

What do you think? Any design patterns that might be applicable to this situation?

Answer 1

We are then supposed to say if a design pattern will make the program better or if it will just make the program more complicated.

Design Patterns are common solutions to common problems. You dont use Design Patterns to use Design Patterns. You use them to solve a specific problem. The most prominent Design Patterns are those from GOF and POEAA. Some of them are simple to implement, like Strategies, while some others require some more architectural thought.

Some Design Patterns you use without even knowing, for instance, your action scripts sound like TransactionScript to me. And yes, you could make these into a PageController to reduce boilerplate code in the scripts. And you could add a FrontController to reduce boilerplate in the PageControllers then. And while you are at that, why not separate business logic and UI with MVC?

In general, Design Patterns will make your code more maintainable in the long run, especially if you keep your implementations GRASP, SOLID and DRY. Design Patterns will also make your code easier to understand and talk about, because patterns are well defined terms. Tell a developer this piece of code is Factory and s/he will understand you.

But yes, Design Patterns might also make your code more complex and you should know where to stop to prevent overengineering. That's not to say, don't use them, but use them reasonably where they can solve a specific problem. Also consider learning about common AntiPatterns.

Since the class is on Software Quality, you should be aware that Software Quality is not measured in the number of Design Patterns in your code. Software Quality is measured in a number of metrics and there is tools for measuring them. Have a look at Quality Assurance in PHP Projects to get an idea.

On a sidenote, Design Patterns do not necessarily have to be used with OOP. OOP is just a great way of organizing code and a lot of the Design Patterns are indeed targeted at, but not limited to OOP. MVC can be used with procedural code. You can use Strategy and Factory with Anonymous Functions, A FrontController can be a simple switch/case statement, and so on. That's because Design Patterns are architectural blueprints and mostly language and paradigm agnostic.

Answer 2

OO is a great way of going. It does make code much more maintainable. It really is the future of programing and php is a great language for OO.

Answer 3

PHP 5+ is quite OO. And you should try to do mostly anything in an OO manner, even if it's a one page script. The rationale here is that there is a really high possibility that this one page is going to grow or will be used in something else.

And do not try to apply a design pattern without understanding it well, certainly do not mix in a pattern just to call it a pattern. See this SO question on Design Patterns.