$oop->consistency = false;

There are various ways to access the properties of an object. Is one way better than another? What constitutes a better way? Why should anyone care?

Recently I read this article: http://www.shawnstratton.info/accesors-and-religion/. The article explained how there is some discussion going on about whether or not properties should be publicly available or if they should be made available through so called getter and setter functions only. The following examples demonstrate various positions:

/**
 * My Person class with publicly available name
 */
public class PublicPerson
{
      public $name;
}

/**
 * My Person class with publicly available name and functions
 */
public class SemiPublicPerson
{
      public $name;

      public function getName()
      {
            return $this->name;
      }

      public function setName($name)
      {
            $this->name = $name;
      }
}

/**
 * My Person class with private name and public functions
 */
public class PrivatePerson
{
      private $name;

      public function getName()
      {
            return $this->name;
      }

      public function setName($name)
      {
            $this->name = $name;
      }
}

The conclusion of the article, which I would like to quote here, is as follows:

There are many ways you can skin this metaphorical cat, however, they each have trade-offs.  Ultimately I went with the methodology that made the most sense to me and that passed our architectural standards (consistency) but you may have a different use case and that’s fine.

Even though the author references consistency (which I greatly approve of :) ) I don’t think he’s being thàt consistent.

Consistency

In science, consistency alone is nice, but nothing more than that. The scientific method that validates scientific theories does not only require a theory to be consistent within itself, it also requires the theory to be consistent with the context. In the case of science, this is the world. In the case of developing object oriented software, this is the set of principles of object orientation.

I find it perfectly reasonable to be called a hardliner, but I’m firmly against preferences and whim. A coding style or practice that is consistent is not a good style if it consistently violates fundamental principles of the paradigm you’re working with!

Encapsulation

To me, getters and setters are not inherently evil. I think setters can be a great way of applying dependency injection and that getters can be very useful for immutable data-holding objects. But let’s be honest; if you want to modify the internal state of another object, then you don’t understand the principle of encapsulation.

This is not a bad thing. You can still write perfectly fine software without consistent encapsulation.  But there are certain risks involved. You may end up tightly coupling classes that needn’t be tightly coupled, you may end up destroying your own code by updating your dependencies and what not – but it’s a choice.

Ok, you keep whining about others. What do you do?

Firstly, I never ever make any property public. Public properties can obtain any value and I don’t think I’ve seen a lot of situations where any value is a valid value. In our earlier example, false is not a proper value for a name, but publicly available properties $name may be set to false.

Secondly, I rarely flat-out use getters. $pim->getName() is a perfectly valid use-case, but $abstractedAwayDataSource->getConnectionSoICanFiddleWithIt() may not be. Before adding setters to a class, think hard and deep about the situations in which it will be used.

There was a discussion in the PHP community recently about using protected or private variables in large framework libraries. Symfony2 has migrated protected properties to private properties, which caused some uproar. The Symfony contributors have re-evaluated their use-case scenarios and decided that, if they want to guarantee stability, they want to control how their application is extended.

After initial complaints, both the users and the contributors have learned new things about how to define and implement the use cases. This has lead to a better product, according to the article I referenced.

Consistency (2)

We care about consistency because consistency is a tool that enables us to produce better results. The perfect programmer writes software that is consistent with paradigms, maximizes the need for readability & write-ability and minimizes time used. Oh, and achieves the stated functional goals, of course. This perfect programmer does not exist, but the inability for us to always be the perfect programmer does not mean we should not attempt to achieve it, for as much as we are possible.

If we are used to pursuing consistency and to continuously reflect on how we are doing, we become this perfect programmer more and more. This maximizes our value (and, I believe, enjoyment, but that is another article).

My counter-conclusion

There is no such thing as ‘to each his own’. There are criteria and there are styles and standards that meet them, or not. If you choose to work following a non-perfect standard and if you choose not to pursue consistency in its fullest, then that is your choice, yes. But it’s limiting your capabilities and your experience of writing software.

$oop->beConsistent();