I have two models User and Post .
user_id authorize editing.
If I have a method inside the Post class that receives a User object to check if User is the author of that Post , will I be respecting the object orientation paradigm? >
I have read that one class should not depend on another. Is this the right way to do it?
It is difficult to state without further details. It would have to see the implementation of this, how it will be used and what may happen in the future to make the decision. I do not know if I should get an object User .
If it's what you want to do, do it, and see if it's good in the future. And maybe you'll discover something else that many do not realize: people do things to make maintenance easier later, and they spend time doing it, and maintenance does not come. What I see nowadays is a system that is practically not evolved, there adopts a complexity for something that is not used.
But the first thing you should know is that there are several definitions of object-orientation. And in all PHP it benefits very little from this paradigm because it is secondary (some say it is not even a paradigm), because it serves to organize complex codes that relate in a complex way. PHP is a script language, it is practically an inherent micro-service. It separates so much from things that it makes little sense to use OOP in it. But she started to allow it because the industry is generally not very well informed about how things work and are very much guided by marketing, which has made it possible to write code like this "so as not to be out of fashion".
It makes more sense to use OOP in Hack , Java, or C #.
But what I can say is that there is no magic formula for defining what is right for OOP. And if so, why do you need to respect if you do something that is right for what you need? What problem does this cause? You have to make the decision because some problem is caused if you do wrong. If you can not determine if it causes any problems, it's not OOP that will help.
Among these controversies about what OOP is, there are those who say that everything about the object must be within it. But each one has a vision of what this all is. Some say that if something can be left out then it should stay. I'm from this class. That is, nothing to encapsulate the whole, but encapsulate the least. To such an extent that in some cases it should not even have a class. Much less with all the mechanisms they use.
Whatever the option, without mastering how to model things, without much experience, without having all the necessary information on the subject, and usually you do not have this, unless you are doing something you've done before and learned a lot from it, it will potentially go wrong.
Learn to model and worry less about OOP. Even because they started using the term for two or more different things, then when you are reading something you do not know which version of OOP you are talking about. Of course, whoever is saying that says his is OOP, the rest is something else. Much of what they claim to be OOP is just modularization.
I realize that people have difficulties to respect even grammatical questions in Portuguese that they use all the time (I am myself), imagine something they do not always use, because the language one should speak when programming is the problem to be solved, is not even the programming language. People go through a lot of difficulty over taxonomy and ontology, so it's hard to do it right and know it's all right.
Here's how it works:
OrworsestillinOOPthishappensalot(andtheydonotnoticeit,especiallyinPHP):
ConceptsthatshouldbemasteredandhavenothingtodowithOOP: What are the concepts of cohesion and coupling? .
And see Is it correct to say that Encapsulation aims at Cohesion? Why? .