Modular design patterns for non-object oriented code?

Question

I am looking for an article or other articles about a form of modular design. Unfortunately I didn't fully read the article before I lost it so this might be kind of vague but I will try to be as specific as I can be and explain what I am trying to do so that someone might be able to suggest other articles.

The article (blog post) in question was by a programmer who said in his experience the best way to design software was in a sort of modular or component based approach so that different components could be selected for different versions of the same or similar software.

The main thing I remember from it was a diagram showing different programs on one axis and different components on another and showing how you could select specific components for specific programs.

The reason I am looking for this is that I am dealing with some non-object oriented PHP code which is too large to revise to object oriented. This program displays different branded web applications with different but similar rules for each site. Currently much of the code looks like:

if($_SESSION['country'] === "Canada" && $_SESSION['brand'] === "X" 
   && $_SESSION['type'] !== "1" || $_SESSION['brand'] !== "Y" 
   && $_SESSION['type'] === "2") {
      include("mod_something.php");
}

Where the conditions might be repeated in several places in the code for including different files.

And I would like to revise some of it to look more like:

if($_SESSION['component-red'] === true && $_SESSION['country'] === "Canada") {
    include("mod_something.php");
} 

and have the component variables set in a central location based on brand and user choices (the sites use a front loading or FrontController design pattern).

Any suggestions or tips about how to accomplish this would be appreciated, but I am not entirely sure how to research this for non-OOP code.

Thank you.

Edit: I was educated in OOP but that is not my question.

Claud

just learn OOP for PHP. That's like the only way to make this language manageable. – Leftist

This one has a pretty good overview of the idea, and has a chart like you've described: cowboyprogramming.com/2007/01/05/evolve-your-heirachy It's focused on game design, but it does a great job comparing the traditional OOP hierarchy with a more modular approach. It doesn't go into details about how to implement that type of system in a non-oop style though. – Bandit

Answer 1

I understand, that spending time with OOP may not help with existing code. Actually, if you are not going to rewrite all that existing code, suggestions are as following:

1. Ensure that site has only one entry point, if not - refactor.
2. Extract all repeating functionality from "module" files into that single entry script: it can be initialization of global resources, common tasks, request filtering, layout initialization, etc.
3. Create some routine which would branch "modules" depending on application state and request - router :) Basically it is switch or if ... elseif ... else
4. Try keep "module" files doing only business logic and assigning values to template.

Maybe you will need to split or merge some modules depending on logic fragmentation in existing source. Once I'd done similar job when ugly e-commerce site of customer was in need of modification. It is better that fully fragmented code.

Commissary

Thanks, this does help a lot. Honestly in a lot of places there aren't even modules but just HTML/PHP snippits. My question was really about number 3. Are there any good ways of (or anything I need to watch out for while) refactoring these if ... elseif ... else (which appear throughout many modules (there is also a central control switch statement)) to reduce the number of variables needing to be modified when requirements change or new branded versions of the program are added. – Claud

Actually, for example, in Zend Framework and many others there're routing concept (framework.zend.com/manual/en/zend.controller.router.html). But if your ifs already so complicated, I don't think it would be smaller in Zend, maybe even more complicated sometimes. One way to shorten switching is convention in module naming. Maybe that numeric parameters (brand, etc) can be named more concise so you could build "module" name from your conditions (e.g. require once "canada/brandx/actiony.php")? – Commissary

Answer 2

I know you want to accomplish it without OOP, but what you describe is literally OOP. You just call it "modules" we call it "objects", same same.

What you should do, is spend some time learning the OOP principles and how to implement them on PHP. When that'll happen, you'll start seeing the advantages of using objects and classes.

Rivera