OOP clarification

[fjm]

Hey!! I never got notification that this post was updated since I last posted here!!! :(

Well, I'm glad to see that this thread is still going. I came back today to tell you guys that I now see the point about designing classes where it won't affect your application code. Here's what happened to me this past weekend....

I needed to add some functionality to my app and when I went into the class to make the change, everything was cool..... that is, until I started the app again and saw that everything was broken. Designing a class with a single action is a very bad thing. It had a rippling effect through the app where this class was being used. Luckly for me though, I had a handy-dandy search/replace function built into my trusty IDE so I was back up and running in no time. :D

So listen up kids... don't design your classes to do single functions. dlite22 summed it up pretty well with his car class comparason. Actually, all you guys are great and are truly helpful. Thanks!

[fjm]

And, BTW: what's all the fuss about using getters and setters? I have read a lot of things about how a "true" OO system really isn't OO if you use setters and getters. I'm sure you guys know what they are talking about but its a bit over my head. Can someone please explain?

If needed, I will grab some of these links.

[fjm]

Hey Dan, thanks for this great comparison. Let me ask you a few questions about the methods you chose plus I'd like to respond to a few of your comments.

1. Frank, I think you're treating a class like it's a script. Two things lead me to this; one is the quote:
. And second is how your constructor is sort of like a trigger and creates a domino affect.

Yes, agreed... I see it now only because it happened to me where a small change created this huge ripple effect throughout my program. A lesson well learned. The good thing is that I never seem to get tired of refactoring my code. :) I'll now go back and redo these classes the right way.

I do not use getters and setters if all they do is directly alter the private member. Might as well make it public anyway. You should have functions that are like "verbs" or actions to the class. For example if the class was a car, accelerate(valu e) , turnOnHeadlight s() etc. while gas-pedal, headlight, wheel where private members. Say to yourself if this was a real life object what would it "do".

All of my methods are using verbs like you suggest. Only thing that I'd like a bit of clarification on is that I noticed that you have a method for accelerate(). In my mind, there are other things that need to happen before actually accelerating such as pressing down the accelerator pedal. I know it may seem like I'm splitting hairs here but I'm just trying to understand is all. Would you just combine the pressAccelerato r() method in with the accelerate() method? Is there such a thing as taking something out too far? I mean, you could conceiveably say that the accelerator pedal should only move downward a certain amount of distance. Should that be its own method? I know that my examples are corny but I hope you see my point in it.


Thanks,
--Frank

[Dormilich]

And, BTW: what's all the fuss about using getters and setters?

I think it's about having control. you'll see that if you look at an exception backtrace. if there's a (g|s)etter involved, you know the property had (not) been touched.

and on the other hand, how else would you code read-only properties?

[fjm]

I think it's about having control. you'll see that if you look at an exception backtrace. if there's a (g|s)etter involved, you know the property had (not) been touched.

and on the other hand, how else would you code read-only properties?

I agree with you Dormi. Here.... I found an excerpt of why these are *supposedly* so bad:

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.

[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.