Abstraction is the key to php programming. You must carefully choose the degree of abstraction you need. Newbie programmers, with their enthusiasm, often create more abstraction than is really useful. A sign of this is if you are creating classes that don't really contain any code and really don't do anything except serve to abstract something. This attraction is understandable, but the value of code brevity has to be weighed against the value of abstraction. Every now and then, we see a mistake made by enthusiastic idealists: at the start of the project, many classes are defined, which seems wonderfully abstract, and one can expect that they will handle any eventuality that may arise. As the project progresses and fatigue sets in, the code itself becomes messy. Function bodies are getting longer than they should be. Empty classes are a burden to document, which is ignored when under pressure. The end result would have been better if the energy expended on abstraction had been expended on keeping things short and simple. It's a form of speculative programming.

There is a certain dogma associated with useful techniques like information concealment and object-oriented programming that are sometimes taken too far. These techniques allow you to code in an abstract way and anticipate changes. However, I personally think you shouldn't be producing a lot of speculative code. For example, it is an accepted style to hide an integer variable on an object behind mutators and accessors, so that the variable itself is not exposed, but only the interface to access it. This allows the implementation of this variable to be changed without affecting the calling code, and may be appropriate for a library programmer who needs to release a very stable API. But I don't think the benefit of this outweighs the cost of verbosity when my team has the calling code and can therefore re-code the caller as easily as the callee. Four or five more lines of code is a heavy burden to pay for this hypothetical profit.

Portability poses a similar problem. Does the code need to be portable to another computer, compiler, application system, or platform, or just easily portable? I think a short, easy-to-carry, non-portable piece of code is better than a long, portable code. It's relatively easy and certainly a good idea to confine non-portable code to a specific location, such as a class that performs database queries specific to a given DBMS.