Over-engineering woes...

I've been given a project to do, largely from scratch, the scope of which to me is a non-trivial undertaking. An entire back-end has to be made to interface with an existing database from PHP, and, well, the objects and relations represented in the database are somewhat overwhelming given the scope of projects I've done in the past (UML diagrams that will not easily print on a handful of pages).

Now, I'm going to go on a bit of a tangent. Java is a nice, fundamentally solid object-oriented language. By common practice, you end up with getter and setter functions for every member on a class, nice encapsulation, and ultimately very reliable (if long, and tedious) code.

PHP is a newly emerging object-oriented language, in that PHP has been around for quite a while, but only in its most recent version has it supported classes. The majority of experience I have with PHP is as an in-line scripting language. My interaction with the database was done in the page, as I needed the information. Clunky, yes, but with little overhead. Impossible to work through a redesign with, but kind of elegant for the project scopes I used it on.

In becoming object oriented, PHP threw me a bit of a curve ball. Now I've got the homogenized nature of Java, all pretty and sterile, compartmentalized and encapsulated to the last, provided to PHP, the wild jungle banshee child of web languages. I'm fighting some very base, some might even say primal urges to use PHP's scripting language capacity to do database interaction, but no, that's bad. It needs to be extensible, easily redesigned, easily understood... it must be object oriented.

But then I look at the Java code that was previously used to interact with the database. Classes with hundreds of lines of getters and setters, code that was hard to navigate, not due to complexity, but monotony. Unnecessary sterility, unnecessary encapsulation for things that were just being consumed or emitted from objects, only to be consumed or emitted from the database. Things which would never need redesign, built that way "just in case..."

All of these things were done in Eclipse, so I realize no poor fool had to sit there and write all of them, but still. PHP is an interpreted language, slow on runtime because it is not precompiled. Surely, several hundred lines of code and function declarations meant only for the purpose of tradition could only slow it down further, and take me forever and a day to write using notepad++... I must think of a better way.

Then, it occurs to me. I'll make a solution that lets me write less code. The pitfall of all designers/programmers. The theory is simple, the implementation is only trivially less simple, and in practice it works practically identically to the Java model of doing things. I end up breaking encapsulation, but only a tiny bit, at the benefit of saving myself the effort of writing menial pass-through getters and setters.

In my model, most gets/sets are handled by an abstract class, which my "real" classes extend. The "real" classes have only the getters and setters defined for things that are special cases, like members that might pull from more than one place in the table, etc. The rest of the data members on an object are pulled from internal variables directly, based on column name. I don't have to write the setters/getters for trivial columns, like username for instance. Plus, if the column name changes, I can write a special case setter/getter for the old column name that will still behave identically, preserving encapsulation.

It's a brilliant plan, in theory, but I worry about having over-engineered it. I worry about it breaking people's expectations of an OO language. I know it will be nice for me to use, but, I'm not so sure how to expect other people to react. I'm breaking a precious paradigm, and Java coders throughout the ranks are cringing upon hearing my ideas. I want to think I'm not a bad designer, and I hope this turns out well. I hope that people will see the benefit of mixing object-orientation with the flexibility of PHP. We shall see.