[thelist] PHP object property getters/setters

Andrew Kamm akamm at demicooper.com
Thu Dec 1 08:58:58 CST 2005

On 11/30/05 10:11 PM, "Chris Johnston" <fuzzylizard at gmail.com> wrote:

>> $customer->city->state->stateName
> Dumb question, but why not just have city and state as attributes (i.e.,
> strings) of customer? Why make them into separate objects? What are you
> gaining by having the city and the state as separate objects in terms of the
> design of your application?

The reason I would treat them as separate objects is because they all have
their own  properties -- a state has an abbreviation, a full name, a
database ID; a city could have a name, town hall address, etc.  What I'm
gaining is access to all of the properties of a customer's city and state
automatically --- why go through the process of creating city and state
objects every time I create a customer object when I can just have the
customer class do that work for me.

In addition, I'll want to access city and state properties without
referencing customers sometimes. So I would of course need to be able to
call city or state objects independent of customers depending on

> In general, from an OO point of view, the above would be bad

Isn't that actually a more effective use of OOP?

>Plus, if the
> above is all you are doing, then why not add a getter to customer that
> retrieves the state name and another getter that will get the city?

The above is a really, really small example for the sake of discussion.  I
hear what you're saying though. No need to make stuff more complicated than
it needs to be. This app is pretty big though, so to store the properties of
one object in another would get pretty crazy (as an example, you would be
storing all state attributes in both the customer and city objects in
addition to already being in the state object, etc)

Thanks! --- Andy

More information about the thelist mailing list