Because OOP helps structure PHP programs into practical modules for re-use and change, the ability of each module to communicate with another module or set of modules is key to creating a successful OOP program. For example, your client class that makes requests must have some way of communicating with the target of its request. To instantiate an instance of a class when making a request, the new statement creates an object (instance) of that class. (That’s one reason constructor functions are all set to public by design. Even if you do not include a constructor function in a class one is automatically included.)

However, you do not want every object communicating with every other object in an OOP application. Consider, for example, a Web design and development company. You may not want your programmers sending directives to your design or UX people. (e.g., Let’s put an animated PacMan on every page.) or your design people telling your programmers what to do (e.g. The colors of your source code listings are all wrong. Change them to pastels.) However, you do want the head of your development team to communicate with the head of your design team to coordinate design and development. It’s the same with OOP programs; you want to organize the flow of communication between objects to avoid tangles and unexpected consequences.

A Double Feature

This will be a two-part post because those videos can get long quick! Here’s Part I on Visibility:

To find out a little more about visibility, this next video shows some OOP programs using different types of visibility and how they can be accessed.

It will probably help if you take a minute and download the example files. You should be able to put the programs in your favorite IDE and watch the video. That’ll probably give you a clear idea of how visibility works in different contexts. If you have any feedback about the videos or blog, please feel free to use the comments. Like to hear from you.