I get asked this quite a bit, people really don’t understand why I am such a big proponent of OOP.
I wish I had all of the time in the world to really, really write out the benefits of an OO architecture versus a procedural approach. For me, It’s all about maintainability and organization. That’s not to say procedural programming can’t be organized, but, I like to require others who use my code to be organized as well.
I can offer only an experience I had recently (which I face way more often than I should.) It has to do with Python but the same principles apply to PHP and Java as well.
At work I have written a testing framework for the automation of our product. The way it works is kind of simple. Each night we have a job that kicks off to build (and unit test) the code and publish it for us to work with and test the next day. Long ago we had a dilemma, the unit tests were passing but once we actually deployed the software some fatal areas were broken.
To remedy the situation, I came up with a tiny framework which grabs this build, configures, deploys, and executes some basic functionality tests to ensure our team is not wasting their time with the latest build.
The structure is like the following:
- core/Product — API for different actions within the product
- core/Database — Wrapper functions for Database calls ( we support 3 different databases, you can think of it as PDO)
- core/TestSuite — Loads and executes tests.
- core/Result - contains name of test, status, reference to log location
- (more things related to the core utilities/necessities of the product)
- tests/GetBuildTest
- tests/DeployBuildTest
- tests/FunctionalityArea1Test
- (more tests)
- run.py - loads the tests and executes them, displays the results.
Each test is actually extremely simple. 15-20 lines of code or less. They have a very strict contract that they must adhere to, in order for the execution to succeed.
Each test MUST
- have an execute() method.
- is in charge of logging it’s actions in the common log file
- return it’s status.
Now that all of the hard work is done, a new requirement comes.
We need an HTML Report of each of the tests
If this were a procedural project, you’d go in to run.py, and start writing code to take the status to generate an html report. Simple enough. Not much maintenance, no need to touch anything else.
The status of the test is not enough, we actually would like to see the associated log messages (from the product) as well as the log messages for the framework when an error occurs.
Again, if this were a procedural process we’d potentially have to touch a lot of code, requiring a lot of testing and a longer turn around time to stability.
Instead, we could just plug in a reporting module. Something with a structure like:
- reporting/Report — contain methods like: add_test(), get_tests()..
- reporting/HTMLReport - generates the report in some pretty html.
- reporting/BasicReport - prints the status of the report
- reporting/EmailReport - emails a report to recipient_list
Each report type would have:
- a generate() method — in charge of generating content however it wants to.
By providing a usable, yet extensible reporting interface, if a requirement comes along later to report a different way, I have isolated the work completely away from the presentation, such that the work will never have to be altered.
It’s late. This may or may not be coherent, but this is the type of maintenance I face every day. OOP works for me. What works for you?
Filed by nick on June 7th, 2008 under
Programming ||
No comments