The goal of this article is to promote and give an overview of Separation of Concerns.

So, when I first started to make websites, I would have one HTML page that had all the CSS and JS. Looked great, awesome!

Then ten years ago I started to learn PHP, I was in 10^th/11^th grade.  I started to create dynamic websites. A PHP file would have PHP, HTML, CSS, JS code in it.    Some of you is probably saying “ok what’s wrong with it?”  Well, when you dived in the codes, it was like an Olive Garden restaurant, pasta everywhere, spaghetti was the only dish served.  Now,  just say  I had five php files, wow, imagine when I had to make a change and I had to edit all of them.  Then I started to “include()” header and footer, but still, PHP,CSS,HTML, JS were everywhere.

One of the growing problem, as the site was getting bigger, I had to maintain each part. But sometimes, I didn’t even need to encounter with a CSS or JS line. But what if I wanted to change a JS section? ARRRRR!!!!!  Mixing everything is just a bad design.  Maintaining and extending part of the codes became a burden.  As the application became bigger and bigger, more trouble was coming ahead. So to solve this issue, I had to rely on a concept called Separation of Concerns.

Separation of Concerns, a concept probably coined by Edsger W. Dijkstra in his 1974 paper “On the role of scientific thought”, is the process of separating a computer program into distinct features that overlap in functionality as little as possible.

Translating this into a web application, we now have, for a super basic one page site:
- mysite. JS
- mysite.CSS
- mysite.PHP  (contain PHP & HTML)

The main advantage of having such structure,  I can concentrate my attention at updating one piece of functionality at a time, instead of running through the HTML,CSS, JS all at once trying to see what’s going.

That was pretty easy, wasn’t it? Now, what about separating our PHP logic from our View?  We can now add a view file:
- mysite. JS
- mysite.CSS
- mysite.PHP
- mysite.HTML (View)

Now mysite.PHP has only  the PHP logic. It processes data to be sent to the view, while mysite.HTML (the view) will only have my HTML.

Now what do we get here? We’ve just separated our application into maintainable “concerns”,  piece of interest.

If I have a JavaScript error, I would just edit mysite.JS. Oh lord, I just saw a PHP parse error, well I go straight to mysite.PHP. But I forgot to add the company’s  logo, well I’ll add the image tag in the mysite.HTML.

At its best, Separation of Concerns allow us to organize an application where each part fulfill a meaning and intuitive role while maximizing its ability to adapt to change. It allows us to maintain and debug our application with class. And extend any part of it without sacrificing the purpose of any.

What other benefits does the Separation of Concerns have?

It allows designers and developers to stay in their turf and not disturbe the flow of the other .

Imagine you’ve got some HTML page well laid out, all your elements well arranged, just for a php developer to come in and do this <? IPutMyCodesInYourCodes(); ?>.  Or do you want a designer to start messing with your PHP codes, just to add a new DIV?

Separation of Concerns separates your application into distinct features that overlap in functionality as little as possible.

I practice the “Separation of Concerns” in all of my applications. While there may be more files in my applications, I do have greater flexibility to update, maintain and extend my application.

So, On the Road to Changes, “Separation of Concerns” is going to lead us to  Model-View-Controller (MVC) concept. But until then, C Ya!

Not only can this be used to test XML but it can also be used to test HTML output from things like render methods and such. Using cURL you could even use some of these techniques to automatically test output on remote sites. All kinds of fun stuff.

http://qafoo.com/blog/007_practical_phpunit_testing_xml_generation.html