OOP clarification

[fjm]

Hey everyone. I'm back in search of a better understanding of OOP. I feel like these past couple of months have paid off for me because I am at a point where I am really beginning to understand how this all works. I'd like to get some clarification on a few things first.

My questions stem from wanting to use private members and methods. I know that there is a reason for making methods and members public and private and honestly I'm still not totally clear as to when to use one over the other. I have been refactoring some of old classes and in looking at them, I was mortified. I figured that when I was redoing them that I should try and stick with private members and methods where possible because that's a good thing I guess.

I had download an app a while back that used 5 classes. Each class was like 1500 lines or so and the code looked clean to me. I figured that was a good way to program. I started to do the same thing but after looking over some of my classes, I quickly noticed that my classes were nothing more than functions instead of objects.

In refactoring this code, I separated out the methods that required functionality inside the class and set my constructor to call a main method that would do what was needed and then return out the values I needed. I just want to make certain that I understand correctly before I continue any further.

If I have a class like so:

class Hello{
    public  $out;
    private $text;
 
    public function __construct($text)
    {
        $this->text = $text;
        $this->sayHello();
    }
 
    private function sayHello()
    {
        $text = $this->text;
        $var = 'Hello, my name is: ' . $text;
        return $this->out = $var;
    }
}
 
$hello = new Hello('Tom');
echo $hello->out;

To me, this seems like the correct way to write a class. I am returning out the values that I want. The way I was doing it in the past was to call the method directly and didn’t seem right.

Does this look correct? I have a few more questions but I'll wait on those for now to see what the feedback is on this. I'll also show you how I was doing before.

Thank!

Frank

[Dormilich]

Supposedly, the getters and setters reveal too much implementation detail because they are typed. What happens if the type changes in the future then everything that calls those getters and setters might have to be updated.

that's why there are interfaces for the classes, that prevents such problems.

on the other hand side, the calls for __get() and __set() are unlikely to change (though they don't work on public properties)

[Atli]

The thing about getters and setters...

Implementing a getter and setter on the same variable (effectively making it a public variable) might seem unnecessary, seeing as we have the public keyword, but simply making it public restricts how you can use it in the future.

Consider if, in the soon to become present, you have the need to run some code on the new value of a variable before it is set. If you had had the foresight to create a setter for it, this would be no problem. But if it is just a public variable, you can't do that without breaking every code that uses this variable.

As you have found out, a simple change to the class design can have a devastating effect on your entire application.

And moreover, if you intend to have some variables read-only and some public, having getters for some of them and direct calls to others will make your class horribly inconsistent. (I HATE inconsistencies :P)

In my mind it's either/or. Use getters/setters on everything or nothing.
(My preference being everything.)

Supposedly, the getters and setters reveal too much implementation detail because they are typed. What happens if the type changes in the future then everything that calls those getters and setters might have to be updated.

How is that any different from a public variable?
Would the code not have to be altered just as much if the type of a public member changed?
Not that this is an issue in PHP. It's a loosely-typed language so there is no need for typed methods/members.