OOP structure: inheritance and encapsulation [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I'm starting a new project and also trying to get a better understanding of OOP in PHP. What I really want to see in action is the pros and cons of encapsulation. My ideal goal is to see there is no class-property exposed to the global scope, so there should be only methods publicly available to others, and they will rely on private or protected class-properties.

The other thing that I'm really looking into is to have a good inheritance as well; However I'm facing difficultly on how to combine both at the same design -- probably I have a wrong understanding or too much expectations from inheritance. To picture it better imaging the following structure:

1. Class App is the base class.
2. I have a couple of other classes like Storage class also, which they all extends App class.
3. Underneath, I have a MVC structure as well. So I want to have access to Storage methods just inside of my Model class, ideally by getting use of inheritance not dependency injection for example.

Now if I want to have my Storage methods available to others, I can simply make a public property in the App class and store the Storage instance in there, so every other class can simply access all the Storage methods, but I want to avoid it and implement a true encapsulation and see how it works in the real world.

On the other hand I want to have SRP on board as well. If I implement even just a single method in the App class that somehow gives you access to the Storage class for example, then I'm violating SRP, because that's not the business of App class -- App can't see the child methods, so I need to provide a way of accessing it.

Also in the above case, whenever I extend the App in another class, then I have to come back to the App class and provide some form interface to that class as well. That means touching an already-working code and I think it's not a good practice at all unless you want to debug the code, but not for adding features or even worst: when you're extending that class by others.

So the question is can I implement such a design without any compromise, and ideally in a battle-tested structure?

Answer 1

The key principles in OOP are encapsulation, cohesion, and coupling. Encapsulation is a protection mechanism. You restrict access to the internals of a class (or an instance of a class) from external actors. Cohesion describes how related the methods/properties of the class are. SRP is an expression of cohesion. Coupling is how much interaction classes (or instances of them) have with each other. You need some, but want them loosely coupled. Dependency injection is one way of keeping your classes loosely coupled. For example, you inject dependencies, not create them internally so that the consuming class doesn't have intimate knowledge of how the class it is dependent on is created (and thus have to change if the creation logic changes). Inheritance isn't strictly necessary for OOP but it allows related classes to share behavior; it's defined by an is-a relationship between two classes, for example, a Car is a specialization of a Vehicle.

Your idea of having all classes inherit from a single base class, other than a simple object class to give them common behaviors like equality and duplication, is a violation of the loose coupling principle and certainly is a bad example of inheritance. A storage mechanism is NOT an app. An app might have a storage mechanism, so it would be an example of a has-a relationship or composition rather than inheritance.