PHP World

How to balance brevity and abstraction

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.

Php blog

  1. 9 Juin 2022The Different Roles of a PHP Development Team: What to Expect When Working with One309 aff.
  2. 6 Juin 2022The Pros and Cons of Programming Languages: Which One Is Right for You?294 aff.
  3. 28 Avril 2022How to Learn PHP Programming: The Basic Steps392 aff.
  4. 29 Janv. 2022The S19 XP Crypto Mining Machine: The Most Efficient Miner on the Market!495 aff.
  5. 29 Nov. 2021Adding Team Extension to Your Larger Company: Benefits and Strategies842 aff.
  6. 21 Août 2021The Key Principles of a php Web Development Company753 aff.
  7. 19 Juil. 2021Read your news online with web publication !757 aff.
  8. 20 Avril 2021Concepts that will revolutionize certain sectors796 aff.
  9. 12 Mars 2021How to make a responsive design with php ?906 aff.
  10. 10 Nov. 2020Learning how to master Php programming1260 aff.