It is not feasible to try to fix the code you posted because OOP is conceptual and depends on how the structure of the other system codes you are developing is.
In the code you posted there is the classic getter of getter and setter (popular term). The technical name is "accessors and mutators".
However, it is applied redundantly because the nome_do_user queue property is set to public. That is, it can be freely accessed without accessors or can be freely modified without mutators .
$correios = new Correios();
var_dump($correios->nome_do_user);
To fix and get to a more appropriate path in object-oriented programming, try to understand the basics of defining visibility of properties and methods: link
Example with accessors and mutators (getter and setter)
Returning to the code, even if you invoke $correios->nome_do_user , you still will not get anything from nome_do_user since it has not been set.
To set, invoke method RecebeJson() before accessing nome_do_user :
$correios = new Correios();
$correios->RecebeJson();
var_dump($correios->nome_do_user);
Okay, it worked! But it did not resolve anything in OOP itself.
class Correios
{
/*
Definimos com visibilidade privada, para que seja acessível somente dentro desse objeto Correios.
*/
private $nome_do_user = null;
public function setNomeUser()
{
/*
Uma condicional que verifica se está vazio. Isso evita executar a rotina mais de uma vez.
A lógica aqui é que se já foi executado, provavelmente não precisa executar mais vezes pois apenas estaria consumindo processos.
*/
if ($this->nome_do_user === null) {
$this->nome_do_user = json_decode(file_get_contents('php://input'), true);
}
}
/*
Accessor que retorna a propriedade nome_do_user.
*/
public function getNomeUser()
{
return $this->nome_do_user;
}
}
$correios = new Correios();
$correios->setNomeUser();
var_dump($correios->getNomeUser());
As you can see, in practice, a lot has been modified from the original.
Example suppressing the mutator (setter)
Personally speaking, despite trying to figure out a way to correct, I feel uncomfortable because it does not mean that this is correct or the best thing to do, because as I said at the outset, OOP is conceptual. It is a set of paradigms. But we will not enter into this discussion because it is something very extensive. Let us then go on to a new suggestion to improve, or optimize, this class:
What bothers me about this class is that it does not seem to make sense to use a mutator . In this case setNomeUser() . We can simplify this way:
class Correios
{
/*
Definimos com visibilidade privada, para que seja acessível somente dentro desse objeto Correios.
*/
private $nome_do_user = null;
public function getNomeUser()
{
/*
Uma condicional que verifica se está vazio. Isso evita executar a rotina mais de uma vez.
A lógica aqui é que se já foi executado, provavelmente não precisa executar mais vezes pois apenas estaria consumindo processos.
*/
if ($this->nome_do_user === null) {
$this->nome_do_user = json_decode(file_get_contents('php://input'), true);
}
return $this->nome_do_user;
}
}
$correios = new Correios();
var_dump($correios->getNomeUser());
This may not be ideal for your project, however, because it depends on planning, what you plan to implement in this class.
In spite of this, note that we now move away from the "getter and setter" (accessor and mutator) pattern and are creating a new pattern.
The points you should note is, is the conceptual pattern you are creating something that is widely recognized and accepted by developer communities?
Even though it is a pattern different from the already existing and widely recognized standards, can I create a pattern of my own?
As long as it is well documented, yes. And of course as long as it's consistent, well written.
Example with constructors
Let's go to a third example of how to "refine" or "complicate" what is already complicated.
class Correios
{
/*
Definimos com visibilidade privada, para que seja acessível somente dentro desse objeto Correios.
*/
private $nome_do_user = null;
public function __construct()
{
/*
Uma condicional que verifica se está vazio. Isso evita executar a rotina mais de uma vez.
A lógica aqui é que se já foi executado, provavelmente não precisa executar mais vezes pois apenas estaria consumindo processos.
*/
if ($this->nome_do_user === null) {
$this->nome_do_user = json_decode(file_get_contents('php://input'), true);
}
return $this;
}
public function getNomeUser()
{
return $this->nome_do_user;
}
}
$correios = new Correios();
var_dump($correios->getNomeUser());
In practice, it does the same as the second example. The difference is that we use the constructor method. __construct() .
The __construct() method is invoked automatically whenever a new instance of a class starts.
That is, whenever you do $var = new NomeDaClasse() , if there is a method called __construct() , it will run automatically. See: link
Static Methods
Now let's "radicalize" and show this whole thing with static methods.
class Correios
{
private static $nome_do_user = null;
public static getNomeUser()
{
/*
Uma condicional que verifica se está vazio. Isso evita executar a rotina mais de uma vez.
A lógica aqui é que se já foi executado, provavelmente não precisa executar mais vezes pois apenas estaria consumindo processos.
*/
if (self::$nome_do_user === null) {
self::$nome_do_user = json_decode(file_get_contents('php://input'), true);
}
return self::$nome_do_user;
}
}
var_dump(Correios::getNomeUser());
When to use static methods and properties?
The thing that seemed simple goes deeper into very complex subjects.
You may think it's much cleaner to visually invoke Correios::getNomeUser(); instead of
$correios = new Correios();
$correios->getNomeUser();
After all, if I can get the same result with a smaller code, is this the one I should use?
Performatically, static style is better than instantiating an object?
With each question, you will probably create new questions. So the complexity in guiding you what or which way to go.
Final Consideration
Despite criticisms and advice on existing responses and comments, do not be discouraged. Every good programmer started as you did, writing concept codes without knowing exactly what he was doing. By practicing a lot and studying, you will be able to understand how to use it properly.
I could still demonstrate some 5 different ways, but I believe that until now it is enough for you to understand and choose what you really want to use. But I agree with what they quoted. Avoid using miraculous OOP things if you do not understand what you are doing. In a nutshell, look for the basic step that is the definition of visibility (public, protected, private).
