It's a fair question. Essentially, I do not want to make anything `public` unless the library requires it, and I don't want to make anything `protected` unless it's a clear place users will want to extend the library.

The reasoning here is when you open up the APIs to these classes, you restrict yourself from making modifications later. For instance, if we ever wanted to remove `hashCheck`, now we have to worry about all the applications calling `hashCheck` publicly.  If we make it `protected`, we only have to worry about the libraries subclassing `Pdo`, where as if it's `private`, we have 100% confidence that changing this method will not adversely affect any libraries.

Keeping all the functions in your library wide open means users will implement them in ways you never intended, and you may be locked into supporting them as such, which is unfortunate.  So as a general rule, assign appropriate access levels and you and your users will both be happy (for the most part :smile: )

Also, when you look at a class file, you can safely skip `private` methods, and understand that `protected` methods are points where subclassing may occur.  It goes a long way in **Self Documenting** the library

`</endrant>`