By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,549 Members | 1,717 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,549 IT Pros & Developers. It's quick & easy.

OOP php user system

P: n/a
Hey,

Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.

Since a short while I've been reading up on OOP and now I am trying to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.

I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).

Could any of you guys have a look and see if I'm going in the right
direction?

The few classes (put in a single file for the sake of easy reading)
can be found here: http://web-develop.nl/user_oop.phps

Hope you guys can give me some useful comments.

Thanks
Nov 9 '08 #1
Share this Question
Share on Google+
30 Replies


P: n/a

"Yorian" <yo************@hotmail.comwrote in message
news:8b**********************************@t39g2000 prh.googlegroups.com...
Hey,

Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.

Since a short while I've been reading up on OOP and now I am trying to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.

I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).

Could any of you guys have a look and see if I'm going in the right
direction?

The few classes (put in a single file for the sake of easy reading)
can be found here: http://web-develop.nl/user_oop.phps

Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't know
what language the comments are in, however I do recognize 'singleton'. For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to supply
those singletons the constructor args. You can either let the caller set the
values via 'setters' and/or create a static function, like 'initialize',
that essentially carries out the responsibility of __construct. You should
also think about defining __clone, __copy, etc. specifically as private so
that you are guaranteed not to have more than one instance of the singleton.

Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time, money,
and frustration when you need to add to it or modify it in some way in the
future.

Cheers
Nov 10 '08 #2

P: n/a
On Nov 9, 10:37*pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message

news:8b**********************************@t39g2000 prh.googlegroups.com...
Hey,
Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.
Since a short while I've been reading up on OOP and now I am trying to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.

The thing I like most, Yorian, is that it is well formatted! I don't know
what language the comments are in, however I do recognize 'singleton'. For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to supply
those singletons the constructor args. You can either let the caller set the
values via 'setters' and/or create a static function, like 'initialize',
that essentially carries out the responsibility of __construct. You should
also think about defining __clone, __copy, etc. specifically as private so
that you are guaranteed not to have more than one instance of the singleton.

Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time, money,
and frustration when you need to add to it or modify it in some way in the
future.

Cheers
Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.

Thomas
Nov 10 '08 #3

P: n/a
On Nov 9, 10:46*pm, 703designs <thomasmal...@gmail.comwrote:
On Nov 9, 10:37*pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message
news:8b**********************************@t39g2000 prh.googlegroups.com....
Hey,
Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.
Since a short while I've been reading up on OOP and now I am trying to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't know
what language the comments are in, however I do recognize 'singleton'. For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to supply
those singletons the constructor args. You can either let the caller set the
values via 'setters' and/or create a static function, like 'initialize',
that essentially carries out the responsibility of __construct. You should
also think about defining __clone, __copy, etc. specifically as privateso
that you are guaranteed not to have more than one instance of the singleton.
Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time, money,
and frustration when you need to add to it or modify it in some way in the
future.
Cheers

Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.

Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.

Thomas
Nov 10 '08 #4

P: n/a

"703designs" <th**********@gmail.comwrote in message
news:87**********************************@a26g2000 prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message
news:8b**********************************@t39g2000 prh.googlegroups.com...
Hey,
Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.
Since a short while I've been reading up on OOP and now I am trying to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't
know
what language the comments are in, however I do recognize 'singleton'.
For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to supply
those singletons the constructor args. You can either let the caller set
the
values via 'setters' and/or create a static function, like 'initialize',
that essentially carries out the responsibility of __construct. You
should
also think about defining __clone, __copy, etc. specifically as private
so
that you are guaranteed not to have more than one instance of the
singleton.
Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time,
money,
and frustration when you need to add to it or modify it in some way in
the
future.
Cheers

Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.

Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.

========

IMO, that's very bad advice. __get and __set only get executed when a caller
tries to access an *undefined* interface. You're abusing the actual intent
of __get/set. It makes it terribly hard to debug and manage. It doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor and
any screen dump of the object would not accurately show any validation for
the properties being set. I'd think about always being specific and not try
to rig the jury to obtain the get/set functionality that is supplied by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Nov 10 '08 #5

P: n/a
On Nov 9, 11:28*pm, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message

news:87**********************************@a26g2000 prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message
>news:8b**********************************@t39g200 0prh.googlegroups.com....
Hey,
Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it..
Since a short while I've been reading up on OOP and now I am tryingto
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't
know
what language the comments are in, however I do recognize 'singleton'..
For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to supply
those singletons the constructor args. You can either let the caller set
the
values via 'setters' and/or create a static function, like 'initialize',
that essentially carries out the responsibility of __construct. You
should
also think about defining __clone, __copy, etc. specifically as private
so
that you are guaranteed not to have more than one instance of the
singleton.
Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time,
money,
and frustration when you need to add to it or modify it in some way in
the
future.
Cheers
Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.
Thomas

Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.

========

IMO, that's very bad advice. __get and __set only get executed when a caller
tries to access an *undefined* interface. You're abusing the actual intent
of __get/set. It makes it terribly hard to debug and manage. It doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor and
any screen dump of the object would not accurately show any validation for
the properties being set. I'd think about always being specific and not try
to rig the jury to obtain the get/set functionality that is supplied by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.

Thomas
Nov 10 '08 #6

P: n/a

"703designs" <th**********@gmail.comwrote in message
news:b0**********************************@i20g2000 prf.googlegroups.com...
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message

news:87**********************************@a26g2000 prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message
>news:8b**********************************@t39g200 0prh.googlegroups.com...
Hey,
Although I've been using classes and object for quite a while now
I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.
Since a short while I've been reading up on OOP and now I am trying
to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't
perfect
(user should actually be named userController, and userData should
be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't
know
what language the comments are in, however I do recognize 'singleton'.
For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to
supply
those singletons the constructor args. You can either let the caller
set
the
values via 'setters' and/or create a static function, like
'initialize',
that essentially carries out the responsibility of __construct. You
should
also think about defining __clone, __copy, etc. specifically as
private
so
that you are guaranteed not to have more than one instance of the
singleton.
Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time,
money,
and frustration when you need to add to it or modify it in some way in
the
future.
Cheers
Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.
Thomas

Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.

========

IMO, that's very bad advice. __get and __set only get executed when a
caller
tries to access an *undefined* interface. You're abusing the actual intent
of __get/set. It makes it terribly hard to debug and manage. It doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor and
any screen dump of the object would not accurately show any validation for
the properties being set. I'd think about always being specific and not
try
to rig the jury to obtain the get/set functionality that is supplied by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.

===========

I understand, however Python's get/set is not php's get/set. I was *very*
excited when I saw the __get/set in php for the first time! That is, until I
saw that it was NOT what I was used to either. Maybe they'll put actual
get/set constructs in another version down the road...because I have
relatively no use for what php is trying to get out of the current
implementation.

Have a good one.
Nov 10 '08 #7

P: n/a
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
>"703designs" <thomasmal...@gmail.comwrote in message

news:87**********************************@a26g200 0prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message
news:8b**********************************@t39g2 000prh.googlegroups.com...
Hey,
Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.
Since a short while I've been reading up on OOP and now I am trying to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't
know
what language the comments are in, however I do recognize 'singleton'.
For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to supply
those singletons the constructor args. You can either let the caller set
the
values via 'setters' and/or create a static function, like 'initialize',
that essentially carries out the responsibility of __construct. You
should
also think about defining __clone, __copy, etc. specifically as private
so
that you are guaranteed not to have more than one instance of the
singleton.
Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time,
money,
and frustration when you need to add to it or modify it in some way in
the
future.
Cheers
Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.
Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.

========

IMO, that's very bad advice. __get and __set only get executed when a caller
tries to access an *undefined* interface. You're abusing the actual intent
of __get/set. It makes it terribly hard to debug and manage. It doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor and
any screen dump of the object would not accurately show any validation for
the properties being set. I'd think about always being specific and not try
to rig the jury to obtain the get/set functionality that is supplied by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.

Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.

Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.

Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 10 '08 #8

P: n/a
On Nov 10, 6:02*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message
>news:87**********************************@a26g200 0prf.googlegroups.com....
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message
news:8b**********************************@t39g2 000prh.googlegroups.com...
Hey,
Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it..
Since a short while I've been reading up on OOP and now I am tryingto
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't
know
what language the comments are in, however I do recognize 'singleton'.
For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to supply
those singletons the constructor args. You can either let the callerset
the
values via 'setters' and/or create a static function, like 'initialize',
that essentially carries out the responsibility of __construct. You
should
also think about defining __clone, __copy, etc. specifically as private
so
that you are guaranteed not to have more than one instance of the
singleton.
Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time,
money,
and frustration when you need to add to it or modify it in some way in
the
future.
Cheers
Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.
Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.
========
IMO, that's very bad advice. __get and __set only get executed when a caller
tries to access an *undefined* interface. You're abusing the actual intent
of __get/set. It makes it terribly hard to debug and manage. It doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor and
any screen dump of the object would not accurately show any validationfor
the properties being set. I'd think about always being specific and not try
to rig the jury to obtain the get/set functionality that is supplied by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas

In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.

Part of good OO design is to keep separate things separate - that
includes attributes. *Independent getter and setter methods, while a
paid to code, do this quite nicely. *They also allow for easier
validation/massage of the data. *A single __get/__set method pair does
not do this.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.

Thomas
Nov 10 '08 #9

P: n/a

"703designs" <th**********@gmail.comwrote in message
news:45**********************************@s1g2000p rg.googlegroups.com...
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message
>news:87**********************************@a26g200 0prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message
news:8b**********************************@t39g2 000prh.googlegroups.com...
Hey,
Although I've been using classes and object for quite a while now
I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.
Since a short while I've been reading up on OOP and now I am trying
to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't
perfect
(user should actually be named userController, and userData should
be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't
know
what language the comments are in, however I do recognize
'singleton'.
For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to
supply
those singletons the constructor args. You can either let the caller
set
the
values via 'setters' and/or create a static function, like
'initialize',
that essentially carries out the responsibility of __construct. You
should
also think about defining __clone, __copy, etc. specifically as
private
so
that you are guaranteed not to have more than one instance of the
singleton.
Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time,
money,
and frustration when you need to add to it or modify it in some way
in
the
future.
Cheers
Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.
Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.
========
IMO, that's very bad advice. __get and __set only get executed when a
caller
tries to access an *undefined* interface. You're abusing the actual
intent
of __get/set. It makes it terribly hard to debug and manage. It doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor
and
any screen dump of the object would not accurately show any validation
for
the properties being set. I'd think about always being specific and not
try
to rig the jury to obtain the get/set functionality that is supplied by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas

In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.

Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.

=======

Hey Thomas. I don't think that's what Jerry is saying. In your suggested
implementation, all caller access to interfaces would come through __get and
__set. He assumes all of your validation would be contained in one single
and potentially large function (either __get or _set). What he fails to
realize, or give you credit for, is the fact that you very well could have
getters and settered defined in your object...either made public or private.
__get and __set could merely have a switch statement that defers the input
arguments to those getters/setter you have defined - which in fact *are*
independent. This scenario is outside of Jerry's criticism as things are
kept separate. It was just a bad assumption on his part.

My comment was, and still is, that __get/__set in php is meant to work in
the opposite way that other OOP languages use them - php uses them for
undefined interface references made by a caller.

As for Jerry's take on __get/__set in other languages, most bind them to the
specific interface...i.e.

Public Property Foo As Boolean
Get Foo() As Boolean
Return myFoo
End Get
Set Foo(ByVal Value As Boolean)
myFoo = Value
End Set
End Property

I just get the impression that Jerry doesn't work with many other
languages...enough to not make such a silly statement.

Cheers, Thomas
Nov 10 '08 #10

P: n/a
On Nov 10, 9:45*am, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message

news:45**********************************@s1g2000p rg.googlegroups.com...
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
>"703designs" <thomasmal...@gmail.comwrote in message
>>news:87**********************************@a26g20 00prf.googlegroups.com...
>On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>>>news:8b**********************************@t39g 2000prh.googlegroups.com...
>>>>Hey,
>>>>Although I've been using classes and object for quite a while now
>>>>I've
>>>>never actually programmed proper OO code yet. It ofcourse dependson
>>>>what you call proper OO code. I have been seperating parts of the
>>>>website. Like a user class, guestbook class, etc. But I've been
>>>>putting all the code in one single class instead of of spreiding it.
>>>>Since a short while I've been reading up on OOP and now I am trying
>>>>to
>>>>actually do things the way they should be done to make a nice
>>>>maintainable module. Which in fact means that I'm trying to stickto
>>>>some rules: Don't repeat yourself, seperation of concerns,
>>>>encapsulation, etc.
>>>>I've created (not finished just started it) a user system, this
>>>>according to the mvc pattern. The names for the classes aren't
>>>>perfect
>>>>(user should actually be named userController, and userData should
>>>>be
>>>>named user, etc.).
>>>>Could any of you guys have a look and see if I'm going in the right
>>>>direction?
>>>>The few classes (put in a single file for the sake of easy reading)
>>>>can be found here:http://web-develop.nl/user_oop.phps
>>>>Hope you guys can give me some useful comments.
>>>The thing I like most, Yorian, is that it is well formatted! I don't
>>>know
>>>what language the comments are in, however I do recognize
>>>'singleton'.
>>>For
>>>the classes that are singletons, you need to make the __constructor a
>>>private function and use the 'static' keyword for the other
>>>functions/variables in the class. You'd necissarily need a way to
>>>supply
>>>those singletons the constructor args. You can either let the caller
>>>set
>>>the
>>>values via 'setters' and/or create a static function, like
>>>'initialize',
>>>that essentially carries out the responsibility of __construct. You
>>>should
>>>also think about defining __clone, __copy, etc. specifically as
>>>private
>>>so
>>>that you are guaranteed not to have more than one instance of the
>>>singleton.
>>>Again, I like the code most because I can readily tell what it is
>>>doing...because it is well formatted. Above all, that will save time,
>>>money,
>>>and frustration when you need to add to it or modify it in some way
>>>in
>>>the
>>>future.
>>>Cheers
>>Instead of using all of those getAttribute methods, you could use a
>>generic __get method that returns the attribute.
>>Thomas
>Ah, my fault, it's late. I meant that you can use __get to point to
>those methods automatically using call_user_func. So that
>$userInstance->last_name would call that method.
>========
>IMO, that's very bad advice. __get and __set only get executed when a
>caller
>tries to access an *undefined* interface. You're abusing the actual
>intent
>of __get/set. It makes it terribly hard to debug and manage. It doesn't
>allow you to strongly type the input(s) or output(s). It's also a
>performance hit. Further, you should notice tools like php documentor
>and
>any screen dump of the object would not accurately show any validation
>for
>the properties being set. I'd think about always being specific and not
>try
>to rig the jury to obtain the get/set functionality that is suppliedby
>other oop languages. __get and __set are NOT php's version of other
>languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.
Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.

=======

Hey Thomas. I don't think that's what Jerry is saying. In your suggested
implementation, all caller access to interfaces would come through __get and
__set. He assumes all of your validation would be contained in one single
and potentially large function (either __get or _set). What he fails to
realize, or give you credit for, is the fact that you very well could have
getters and settered defined in your object...either made public or private.
__get and __set could merely have a switch statement that defers the input
arguments to those getters/setter you have defined - which in fact *are*
independent. This scenario is outside of Jerry's criticism as things are
kept separate. It was just a bad assumption on his part.

My comment was, and still is, that __get/__set in php is meant to work in
the opposite way that other OOP languages use them - php uses them for
undefined interface references made by a caller.

As for Jerry's take on __get/__set in other languages, most bind them to the
specific interface...i.e.

Public Property Foo As Boolean
* Get Foo() As Boolean
* * Return myFoo
* End Get
* Set Foo(ByVal Value As Boolean)
* * myFoo = Value
* End Set
End Property

I just get the impression that Jerry doesn't work with many other
languages...enough to not make such a silly statement.

Cheers, Thomas
Right, I think Jerry missed the part of my recommendation of calling
call_user_func(method) in __get. Getter and setter methods would still
be abound.

Thanks,
Thomas
Nov 10 '08 #11

P: n/a
703designs wrote:
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>703designs wrote:
>>On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message
news:87**********************************@a26g2 000prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>"Yorian" <yorianbenja...@hotmail.comwrote in message
>news:8b**********************************@t39 g2000prh.googlegroups.com...
>>Hey,
>>Although I've been using classes and object for quite a while now I've
>>never actually programmed proper OO code yet. It ofcourse depends on
>>what you call proper OO code. I have been seperating parts of the
>>website. Like a user class, guestbook class, etc. But I've been
>>putting all the code in one single class instead of of spreiding it.
>>Since a short while I've been reading up on OOP and now I am trying to
>>actually do things the way they should be done to make a nice
>>maintainable module. Which in fact means that I'm trying to stick to
>>some rules: Don't repeat yourself, seperation of concerns,
>>encapsulation, etc.
>>I've created (not finished just started it) a user system, this
>>according to the mvc pattern. The names for the classes aren't perfect
>>(user should actually be named userController, and userData should be
>>named user, etc.).
>>Could any of you guys have a look and see if I'm going in the right
>>direction?
>>The few classes (put in a single file for the sake of easy reading)
>>can be found here:http://web-develop.nl/user_oop.phps
>>Hope you guys can give me some useful comments.
>The thing I like most, Yorian, is that it is well formatted! I don't
>know
>what language the comments are in, however I do recognize 'singleton'.
>For
>the classes that are singletons, you need to make the __constructor a
>private function and use the 'static' keyword for the other
>functions/variables in the class. You'd necissarily need a way to supply
>those singletons the constructor args. You can either let the caller set
>the
>values via 'setters' and/or create a static function, like 'initialize',
>that essentially carries out the responsibility of __construct. You
>should
>also think about defining __clone, __copy, etc. specifically as private
>so
>that you are guaranteed not to have more than one instance of the
>singleton.
>Again, I like the code most because I can readily tell what it is
>doing...because it is well formatted. Above all, that will save time,
>money,
>and frustration when you need to add to it or modify it in some way in
>the
>future.
>Cheers
Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.
Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.
========
IMO, that's very bad advice. __get and __set only get executed when a caller
tries to access an *undefined* interface. You're abusing the actual intent
of __get/set. It makes it terribly hard to debug and manage. It doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor and
any screen dump of the object would not accurately show any validation for
the properties being set. I'd think about always being specific and not try
to rig the jury to obtain the get/set functionality that is supplied by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.

Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.

Thomas
Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.

That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 10 '08 #12

P: n/a

"703designs" <th**********@gmail.comwrote in message
news:e6**********************************@a17g2000 prm.googlegroups.com...
On Nov 10, 9:45 am, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message

news:45**********************************@s1g2000p rg.googlegroups.com...
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
>"703designs" <thomasmal...@gmail.comwrote in message
>>news:87**********************************@a26g20 00prf.googlegroups.com...
>On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>>>news:8b**********************************@t39g 2000prh.googlegroups.com...
>>>>Hey,
>>>>Although I've been using classes and object for quite a while now
>>>>I've
>>>>never actually programmed proper OO code yet. It ofcourse depends
>>>>on
>>>>what you call proper OO code. I have been seperating parts of the
>>>>website. Like a user class, guestbook class, etc. But I've been
>>>>putting all the code in one single class instead of of spreiding
>>>>it.
>>>>Since a short while I've been reading up on OOP and now I am
>>>>trying
>>>>to
>>>>actually do things the way they should be done to make a nice
>>>>maintainable module. Which in fact means that I'm trying to stick
>>>>to
>>>>some rules: Don't repeat yourself, seperation of concerns,
>>>>encapsulation, etc.
>>>>I've created (not finished just started it) a user system, this
>>>>according to the mvc pattern. The names for the classes aren't
>>>>perfect
>>>>(user should actually be named userController, and userData should
>>>>be
>>>>named user, etc.).
>>>>Could any of you guys have a look and see if I'm going in the
>>>>right
>>>>direction?
>>>>The few classes (put in a single file for the sake of easy
>>>>reading)
>>>>can be found here:http://web-develop.nl/user_oop.phps
>>>>Hope you guys can give me some useful comments.
>>>The thing I like most, Yorian, is that it is well formatted! I
>>>don't
>>>know
>>>what language the comments are in, however I do recognize
>>>'singleton'.
>>>For
>>>the classes that are singletons, you need to make the __constructor
>>>a
>>>private function and use the 'static' keyword for the other
>>>functions/variables in the class. You'd necissarily need a way to
>>>supply
>>>those singletons the constructor args. You can either let the
>>>caller
>>>set
>>>the
>>>values via 'setters' and/or create a static function, like
>>>'initialize',
>>>that essentially carries out the responsibility of __construct. You
>>>should
>>>also think about defining __clone, __copy, etc. specifically as
>>>private
>>>so
>>>that you are guaranteed not to have more than one instance of the
>>>singleton.
>>>Again, I like the code most because I can readily tell what it is
>>>doing...because it is well formatted. Above all, that will save
>>>time,
>>>money,
>>>and frustration when you need to add to it or modify it in some way
>>>in
>>>the
>>>future.
>>>Cheers
>>Instead of using all of those getAttribute methods, you could use a
>>generic __get method that returns the attribute.
>>Thomas
>Ah, my fault, it's late. I meant that you can use __get to point to
>those methods automatically using call_user_func. So that
>$userInstance->last_name would call that method.
>========
>IMO, that's very bad advice. __get and __set only get executed when a
>caller
>tries to access an *undefined* interface. You're abusing the actual
>intent
>of __get/set. It makes it terribly hard to debug and manage. It
>doesn't
>allow you to strongly type the input(s) or output(s). It's also a
>performance hit. Further, you should notice tools like php documentor
>and
>any screen dump of the object would not accurately show any
>validation
>for
>the properties being set. I'd think about always being specific and
>not
>try
>to rig the jury to obtain the get/set functionality that is supplied
>by
>other oop languages. __get and __set are NOT php's version of other
>languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.
Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.

=======

Hey Thomas. I don't think that's what Jerry is saying. In your suggested
implementation, all caller access to interfaces would come through __get
and
__set. He assumes all of your validation would be contained in one single
and potentially large function (either __get or _set). What he fails to
realize, or give you credit for, is the fact that you very well could have
getters and settered defined in your object...either made public or
private.
__get and __set could merely have a switch statement that defers the input
arguments to those getters/setter you have defined - which in fact *are*
independent. This scenario is outside of Jerry's criticism as things are
kept separate. It was just a bad assumption on his part.

My comment was, and still is, that __get/__set in php is meant to work in
the opposite way that other OOP languages use them - php uses them for
undefined interface references made by a caller.

As for Jerry's take on __get/__set in other languages, most bind them to
the
specific interface...i.e.

Public Property Foo As Boolean
Get Foo() As Boolean
Return myFoo
End Get
Set Foo(ByVal Value As Boolean)
myFoo = Value
End Set
End Property

I just get the impression that Jerry doesn't work with many other
languages...enough to not make such a silly statement.

Cheers, Thomas
Right, I think Jerry missed the part of my recommendation of calling
call_user_func(method) in __get. Getter and setter methods would still
be abound.

=========

Bingo!

And, my take on Jerry is that he likes to assume he is correct, without ever
actually being correct. The nature of a troll I suppose. :^)
Nov 10 '08 #13

P: n/a
On Nov 10, 10:17*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message
news:87**********************************@a26g2 000prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
"Yorian" <yorianbenja...@hotmail.comwrote in message
>news:8b**********************************@t39 g2000prh.googlegroups.com...
>Hey,
>Although I've been using classes and object for quite a while nowI've
>never actually programmed proper OO code yet. It ofcourse dependson
>what you call proper OO code. I have been seperating parts of the
>website. Like a user class, guestbook class, etc. But I've been
>putting all the code in one single class instead of of spreiding it.
>Since a short while I've been reading up on OOP and now I am trying to
>actually do things the way they should be done to make a nice
>maintainable module. Which in fact means that I'm trying to stickto
>some rules: Don't repeat yourself, seperation of concerns,
>encapsulation, etc.
>I've created (not finished just started it) a user system, this
>according to the mvc pattern. The names for the classes aren't perfect
>(user should actually be named userController, and userData should be
>named user, etc.).
>Could any of you guys have a look and see if I'm going in the right
>direction?
>The few classes (put in a single file for the sake of easy reading)
>can be found here:http://web-develop.nl/user_oop.phps
>Hope you guys can give me some useful comments.
The thing I like most, Yorian, is that it is well formatted! I don't
know
what language the comments are in, however I do recognize 'singleton'.
For
the classes that are singletons, you need to make the __constructor a
private function and use the 'static' keyword for the other
functions/variables in the class. You'd necissarily need a way to supply
those singletons the constructor args. You can either let the caller set
the
values via 'setters' and/or create a static function, like 'initialize',
that essentially carries out the responsibility of __construct. You
should
also think about defining __clone, __copy, etc. specifically as private
so
that you are guaranteed not to have more than one instance of the
singleton.
Again, I like the code most because I can readily tell what it is
doing...because it is well formatted. Above all, that will save time,
money,
and frustration when you need to add to it or modify it in some way in
the
future.
Cheers
Instead of using all of those getAttribute methods, you could use a
generic __get method that returns the attribute.
Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.
========
IMO, that's very bad advice. __get and __set only get executed when a caller
tries to access an *undefined* interface. You're abusing the actual intent
of __get/set. It makes it terribly hard to debug and manage. It doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor and
any screen dump of the object would not accurately show any validation for
the properties being set. I'd think about always being specific and not try
to rig the jury to obtain the get/set functionality that is suppliedby
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.
Part of good OO design is to keep separate things separate - that
includes attributes. *Independent getter and setter methods, while a
paid to code, do this quite nicely. *They also allow for easier
validation/massage of the data. *A single __get/__set method pair does
not do this.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.
Thomas

Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.

That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
If my application design is such that getting and setting will
probably be required in the future, I can avoid massive refactoring by
mapping assignment to __set and retrieval to __get. That way, in the
early stages I can use:

echo $this->name;

and even if it's used site-wide, I can instantly map all of these
references to $this->getName() if I use __get properly.

That is, if __get worked the way we wish it did :^)

You should check out Manning Press' "PHP in Action." It has some top-
notch writing on this subject. Their recommendation is the same as
Jessica's (that __get's not designed/implemented appropriately for
this use quite yet).

Thanks,
Thomas
Nov 10 '08 #14

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
703designs wrote:
>On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>>703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message
news:87**********************************@a26g 2000prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>news:8b**********************************@t3 9g2000prh.googlegroups.com...
>>>Hey,
>>>Although I've been using classes and object for quite a while now
>>>I've
>>>never actually programmed proper OO code yet. It ofcourse depends
>>>on
>>>what you call proper OO code. I have been seperating parts of the
>>>website. Like a user class, guestbook class, etc. But I've been
>>>putting all the code in one single class instead of of spreiding
>>>it.
>>>Since a short while I've been reading up on OOP and now I am trying
>>>to
>>>actually do things the way they should be done to make a nice
>>>maintainable module. Which in fact means that I'm trying to stick
>>>to
>>>some rules: Don't repeat yourself, seperation of concerns,
>>>encapsulation, etc.
>>>I've created (not finished just started it) a user system, this
>>>according to the mvc pattern. The names for the classes aren't
>>>perfect
>>>(user should actually be named userController, and userData should
>>>be
>>>named user, etc.).
>>>Could any of you guys have a look and see if I'm going in the right
>>>direction?
>>>The few classes (put in a single file for the sake of easy reading)
>>>can be found here:http://web-develop.nl/user_oop.phps
>>>Hope you guys can give me some useful comments.
>>The thing I like most, Yorian, is that it is well formatted! I don't
>>know
>>what language the comments are in, however I do recognize
>>'singleton'.
>>For
>>the classes that are singletons, you need to make the __constructor
>>a
>>private function and use the 'static' keyword for the other
>>functions/variables in the class. You'd necissarily need a way to
>>supply
>>those singletons the constructor args. You can either let the caller
>>set
>>the
>>values via 'setters' and/or create a static function, like
>>'initialize',
>>that essentially carries out the responsibility of __construct. You
>>should
>>also think about defining __clone, __copy, etc. specifically as
>>private
>>so
>>that you are guaranteed not to have more than one instance of the
>>singleton.
>>Again, I like the code most because I can readily tell what it is
>>doing...because it is well formatted. Above all, that will save
>>time,
>>money,
>>and frustration when you need to add to it or modify it in some way
>>in
>>the
>>future.
>>Cheers
>Instead of using all of those getAttribute methods, you could use a
>generic __get method that returns the attribute.
>Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.
========
IMO, that's very bad advice. __get and __set only get executed when a
caller
tries to access an *undefined* interface. You're abusing the actual
intent
of __get/set. It makes it terribly hard to debug and manage. It
doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor
and
any screen dump of the object would not accurately show any validation
for
the properties being set. I'd think about always being specific and
not try
to rig the jury to obtain the get/set functionality that is supplied
by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.

Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.

Thomas

Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.

That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.
Jerry, Jerry, Jerry!

The 'need' could be as simple as convenience! OOP languages bind getters and
setters directly into the properties available to the caller...such that:

object.property = something // initiates a __set

and

print object.property // initiates a __get

That's not so hard to understand! And while Java and C++ fit the bill, I
hardly would hold SmallTalk up as a beacon for OOP! However, ALL of those
languages operate in the way I've just displayed. Thomas is simply trying to
coerse php to do what the rest of us hope it eventually will...give us the
same or similar constructs.

BTW, quit accusing Thomas of bad design! If you read his suggestion, you'd
have noticed that he's not balling up all of his validation in __get/set as
you've twice accused him of. He suggested using php's call user func
function...I said it could be as easy as a switch statement and a direct
call to the getter/setter. Thus far, your arguments are MOOT. You've only to
state that "there is no need for the __get/__set methods" (if you've already
defined getters/setters). Ok then! Statement noted.

Do you ever offer advice that actually further's someone's understanding of
php or help better the content of a thread in which you've posted, Jerry? I
can't see that you do.
Nov 10 '08 #15

P: n/a
703designs wrote:
On Nov 10, 10:17 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>703designs wrote:
>>On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
>"703designs" <thomasmal...@gmail.comwrote in message
>news:87**********************************@a26 g2000prf.googlegroups.com...
>On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>>news:8b**********************************@t 39g2000prh.googlegroups.com...
>>>>Hey,
>>>>Although I've been using classes and object for quite a while now I've
>>>>never actually programmed proper OO code yet. It ofcourse depends on
>>>>what you call proper OO code. I have been seperating parts of the
>>>>website. Like a user class, guestbook class, etc. But I've been
>>>>putting all the code in one single class instead of of spreiding it.
>>>>Since a short while I've been reading up on OOP and now I am trying to
>>>>actually do things the way they should be done to make a nice
>>>>maintainable module. Which in fact means that I'm trying to stick to
>>>>some rules: Don't repeat yourself, seperation of concerns,
>>>>encapsulation, etc.
>>>>I've created (not finished just started it) a user system, this
>>>>according to the mvc pattern. The names for the classes aren't perfect
>>>>(user should actually be named userController, and userData should be
>>>>named user, etc.).
>>>>Could any of you guys have a look and see if I'm going in the right
>>>>direction?
>>>>The few classes (put in a single file for the sake of easy reading)
>>>>can be found here:http://web-develop.nl/user_oop.phps
>>>>Hope you guys can give me some useful comments.
>>>The thing I like most, Yorian, is that it is well formatted! I don't
>>>know
>>>what language the comments are in, however I do recognize 'singleton'.
>>>For
>>>the classes that are singletons, you need to make the __constructor a
>>>private function and use the 'static' keyword for the other
>>>functions/variables in the class. You'd necissarily need a way to supply
>>>those singletons the constructor args. You can either let the caller set
>>>the
>>>values via 'setters' and/or create a static function, like 'initialize',
>>>that essentially carries out the responsibility of __construct. You
>>>should
>>>also think about defining __clone, __copy, etc. specifically as private
>>>so
>>>that you are guaranteed not to have more than one instance of the
>>>singleton.
>>>Again, I like the code most because I can readily tell what it is
>>>doing...because it is well formatted. Above all, that will save time,
>>>money,
>>>and frustration when you need to add to it or modify it in some way in
>>>the
>>>future.
>>>Cheers
>>Instead of using all of those getAttribute methods, you could use a
>>generic __get method that returns the attribute.
>>Thomas
>Ah, my fault, it's late. I meant that you can use __get to point to
>those methods automatically using call_user_func. So that
>$userInstance->last_name would call that method.
>========
>IMO, that's very bad advice. __get and __set only get executed when a caller
>tries to access an *undefined* interface. You're abusing the actual intent
>of __get/set. It makes it terribly hard to debug and manage. It doesn't
>allow you to strongly type the input(s) or output(s). It's also a
>performance hit. Further, you should notice tools like php documentor and
>any screen dump of the object would not accurately show any validation for
>the properties being set. I'd think about always being specific and not try
>to rig the jury to obtain the get/set functionality that is supplied by
>other oop languages. __get and __set are NOT php's version of other
>languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.
Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.
Thomas
Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.

That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

If my application design is such that getting and setting will
probably be required in the future, I can avoid massive refactoring by
mapping assignment to __set and retrieval to __get. That way, in the
early stages I can use:

echo $this->name;

and even if it's used site-wide, I can instantly map all of these
references to $this->getName() if I use __get properly.
Which does not mean it's a good design. If you had a good design, you
don't need the __get() method.
That is, if __get worked the way we wish it did :^)
That is, if _get() worked the way YOU wish it did.
You should check out Manning Press' "PHP in Action." It has some top-
notch writing on this subject. Their recommendation is the same as
Jessica's (that __get's not designed/implemented appropriately for
this use quite yet).

Thanks,
Thomas
You should read some of the GOOD OOAD books. Ones by long recognized
names like Booch, Rumbaugh, and similar.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 10 '08 #16

P: n/a
Jessica Griego wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
>703designs wrote:
>>On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
>"703designs" <thomasmal...@gmail.comwrote in message
>news:87**********************************@a26 g2000prf.googlegroups.com...
>On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>>news:8b**********************************@t 39g2000prh.googlegroups.com...
>>>>Hey,
>>>>Although I've been using classes and object for quite a while now
>>>>I've
>>>>never actually programmed proper OO code yet. It ofcourse depends
>>>>on
>>>>what you call proper OO code. I have been seperating parts of the
>>>>website. Like a user class, guestbook class, etc. But I've been
>>>>putting all the code in one single class instead of of spreiding
>>>>it.
>>>>Since a short while I've been reading up on OOP and now I am trying
>>>>to
>>>>actually do things the way they should be done to make a nice
>>>>maintainable module. Which in fact means that I'm trying to stick
>>>>to
>>>>some rules: Don't repeat yourself, seperation of concerns,
>>>>encapsulation, etc.
>>>>I've created (not finished just started it) a user system, this
>>>>according to the mvc pattern. The names for the classes aren't
>>>>perfect
>>>>(user should actually be named userController, and userData should
>>>>be
>>>>named user, etc.).
>>>>Could any of you guys have a look and see if I'm going in the right
>>>>direction?
>>>>The few classes (put in a single file for the sake of easy reading)
>>>>can be found here:http://web-develop.nl/user_oop.phps
>>>>Hope you guys can give me some useful comments.
>>>The thing I like most, Yorian, is that it is well formatted! I don't
>>>know
>>>what language the comments are in, however I do recognize
>>>'singleton'.
>>>For
>>>the classes that are singletons, you need to make the __constructor
>>>a
>>>private function and use the 'static' keyword for the other
>>>functions/variables in the class. You'd necissarily need a way to
>>>supply
>>>those singletons the constructor args. You can either let the caller
>>>set
>>>the
>>>values via 'setters' and/or create a static function, like
>>>'initialize',
>>>that essentially carries out the responsibility of __construct. You
>>>should
>>>also think about defining __clone, __copy, etc. specifically as
>>>private
>>>so
>>>that you are guaranteed not to have more than one instance of the
>>>singleton.
>>>Again, I like the code most because I can readily tell what it is
>>>doing...because it is well formatted. Above all, that will save
>>>time,
>>>money,
>>>and frustration when you need to add to it or modify it in some way
>>>in
>>>the
>>>future.
>>>Cheers
>>Instead of using all of those getAttribute methods, you could use a
>>generic __get method that returns the attribute.
>>Thomas
>Ah, my fault, it's late. I meant that you can use __get to point to
>those methods automatically using call_user_func. So that
>$userInstance->last_name would call that method.
>========
>IMO, that's very bad advice. __get and __set only get executed when a
>caller
>tries to access an *undefined* interface. You're abusing the actual
>intent
>of __get/set. It makes it terribly hard to debug and manage. It
>doesn't
>allow you to strongly type the input(s) or output(s). It's also a
>performance hit. Further, you should notice tools like php documentor
>and
>any screen dump of the object would not accurately show any validation
>for
>the properties being set. I'd think about always being specific and
>not try
>to rig the jury to obtain the get/set functionality that is supplied
>by
>other oop languages. __get and __set are NOT php's version of other
>languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.

Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.

Thomas
Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.

That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.

Jerry, Jerry, Jerry!

The 'need' could be as simple as convenience! OOP languages bind getters and
setters directly into the properties available to the caller...such that:
Convenience != good design! There is nothing to replace a good design.
Your "convenience" is just plain laziness.
object.property = something // initiates a __set

and

print object.property // initiates a __get
Good OO design does not allow such actions.
That's not so hard to understand! And while Java and C++ fit the bill, I
hardly would hold SmallTalk up as a beacon for OOP! However, ALL of those
languages operate in the way I've just displayed. Thomas is simply trying to
coerse php to do what the rest of us hope it eventually will...give us the
same or similar constructs.
SmallTalk is a good OO language. But NONE of them operate in the way
you would like. If property is private, as it should be, then
object.property (unless in a member function) will cause a compile time
error.
BTW, quit accusing Thomas of bad design! If you read his suggestion, you'd
have noticed that he's not balling up all of his validation in __get/set as
you've twice accused him of. He suggested using php's call user func
function...I said it could be as easy as a switch statement and a direct
call to the getter/setter. Thus far, your arguments are MOOT. You've only to
state that "there is no need for the __get/__set methods" (if you've already
defined getters/setters). Ok then! Statement noted.
We already know how you program. Your previous "answer" is proof of that.
Do you ever offer advice that actually further's someone's understanding of
php or help better the content of a thread in which you've posted, Jerry? I
can't see that you do.

ROFLMAO. This from some newbie who doesn't have any idea what good
programming is all about.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 10 '08 #17

P: n/a
On Nov 10, 11:11*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
Jessica Griego wrote:
"Jerry Stuckle" <jstuck...@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
703designs wrote:
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
"703designs" <thomasmal...@gmail.comwrote in message
>news:87**********************************@a26 g2000prf.googlegroups.com...
On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>>news:8b**********************************@t 39g2000prh.googlegroups.com...
>>>Hey,
>>>Although I've been using classes and object for quite a while now
>>>I've
>>>never actually programmed proper OO code yet. It ofcourse depends
>>>on
>>>what you call proper OO code. I have been seperating parts of the
>>>website. Like a user class, guestbook class, etc. But I've been
>>>putting all the code in one single class instead of of spreiding
>>>it.
>>>Since a short while I've been reading up on OOP and now I am trying
>>>to
>>>actually do things the way they should be done to make a nice
>>>maintainable module. Which in fact means that I'm trying to stick
>>>to
>>>some rules: Don't repeat yourself, seperation of concerns,
>>>encapsulation, etc.
>>>I've created (not finished just started it) a user system, this
>>>according to the mvc pattern. The names for the classes aren't
>>>perfect
>>>(user should actually be named userController, and userData should
>>>be
>>>named user, etc.).
>>>Could any of you guys have a look and see if I'm going in the right
>>>direction?
>>>The few classes (put in a single file for the sake of easy reading)
>>>can be found here:http://web-develop.nl/user_oop.phps
>>>Hope you guys can give me some useful comments.
>>The thing I like most, Yorian, is that it is well formatted! I don't
>>know
>>what language the comments are in, however I do recognize
>>'singleton'.
>>For
>>the classes that are singletons, you need to make the __constructor
>>a
>>private function and use the 'static' keyword for the other
>>functions/variables in the class. You'd necissarily need a way to
>>supply
>>those singletons the constructor args. You can either let the caller
>>set
>>the
>>values via 'setters' and/or create a static function, like
>>'initialize',
>>that essentially carries out the responsibility of __construct. You
>>should
>>also think about defining __clone, __copy, etc. specifically as
>>private
>>so
>>that you are guaranteed not to have more than one instance of the
>>singleton.
>>Again, I like the code most because I can readily tell what it is
>>doing...because it is well formatted. Above all, that will save
>>time,
>>money,
>>and frustration when you need to add to it or modify it in some way
>>in
>>the
>>future.
>>Cheers
>Instead of using all of those getAttribute methods, you could usea
>generic __get method that returns the attribute.
>Thomas
Ah, my fault, it's late. I meant that you can use __get to point to
those methods automatically using call_user_func. So that
$userInstance->last_name would call that method.
========
IMO, that's very bad advice. __get and __set only get executed when a
caller
tries to access an *undefined* interface. You're abusing the actual
intent
of __get/set. It makes it terribly hard to debug and manage. It
doesn't
allow you to strongly type the input(s) or output(s). It's also a
performance hit. Further, you should notice tools like php documentor
and
any screen dump of the object would not accurately show any validation
for
the properties being set. I'd think about always being specific and
not try
to rig the jury to obtain the get/set functionality that is supplied
by
other oop languages. __get and __set are NOT php's version of other
languages' get/set construct.
Sorry, Python's my first language and this sort of thing works very
cleanly there. I'll keep these drawbacks in mind: I guess that __get's
not quite ready for primetime.
Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.
>>Part of good OO design is to keep separate things separate - that
includes attributes. *Independent getter and setter methods, whilea
paid to code, do this quite nicely. *They also allow for easier
validation/massage of the data. *A single __get/__set method pair does
not do this.
>>--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.
>Thomas
Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.
That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.
Jerry, Jerry, Jerry!
The 'need' could be as simple as convenience! OOP languages bind getters and
setters directly into the properties available to the caller...such that:

Convenience != good design! *There is nothing to replace a good design.
* Your "convenience" is just plain laziness.
object.property = something // initiates a __set
and
print object.property * * * // initiates a __get

Good OO design does not allow such actions.
That's not so hard to understand! And while Java and C++ fit the bill, I
hardly would hold SmallTalk up as a beacon for OOP! However, ALL of those
languages operate in the way I've just displayed. Thomas is simply trying to
coerse php to do what the rest of us hope it eventually will...give us the
same or similar constructs.

SmallTalk is a good OO language. *But NONE of them operate in the way
you would like. *If property is private, as it should be, then
object.property (unless in a member function) will cause a compile time
error.
BTW, quit accusing Thomas of bad design! If you read his suggestion, you'd
have noticed that he's not balling up all of his validation in __get/set as
you've twice accused him of. He suggested using php's call user func
function...I said it could be as easy as a switch statement and a direct
call to the getter/setter. Thus far, your arguments are MOOT. You've only to
state that "there is no need for the __get/__set methods" (if you've already
defined getters/setters). Ok then! Statement noted.

We already know how you program. *Your previous "answer" is proof of that.
Do you ever offer advice that actually further's someone's understanding of
php or help better the content of a thread in which you've posted, Jerry? I
can't see that you do.

ROFLMAO. *This from some newbie who doesn't have any idea what good
programming is all about.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
First of all, don't go flinging crap like "newbie" around here. You'll
only piss others off.

Second, design quality is subjective, and I don't bow before any OO
deities. Have you forgotten which mailing list you're on? We'd be
elsewhere if we favored design to implementation.

Third, I rescinded my recommendation of __get in, like, the third post
here after Jessica helpfully clarified how lame it is.

Thomas
Nov 10 '08 #18

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
Jessica Griego wrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
>>703designs wrote:
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
>On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
>>"703designs" <thomasmal...@gmail.comwrote in message
>>news:87**********************************@a2 6g2000prf.googlegroups.com...
>>On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>>>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>>>news:8b**********************************@ t39g2000prh.googlegroups.com...
>>>>>Hey,
>>>>>Although I've been using classes and object for quite a while now
>>>>>I've
>>>>>never actually programmed proper OO code yet. It ofcourse depends
>>>>>on
>>>>>what you call proper OO code. I have been seperating parts of the
>>>>>website. Like a user class, guestbook class, etc. But I've been
>>>>>putting all the code in one single class instead of of spreiding
>>>>>it.
>>>>>Since a short while I've been reading up on OOP and now I am
>>>>>trying to
>>>>>actually do things the way they should be done to make a nice
>>>>>maintainable module. Which in fact means that I'm trying to stick
>>>>>to
>>>>>some rules: Don't repeat yourself, seperation of concerns,
>>>>>encapsulation, etc.
>>>>>I've created (not finished just started it) a user system, this
>>>>>according to the mvc pattern. The names for the classes aren't
>>>>>perfect
>>>>>(user should actually be named userController, and userData
>>>>>should be
>>>>>named user, etc.).
>>>>>Could any of you guys have a look and see if I'm going in the
>>>>>right
>>>>>direction?
>>>>>The few classes (put in a single file for the sake of easy
>>>>>reading)
>>>>>can be found here:http://web-develop.nl/user_oop.phps
>>>>>Hope you guys can give me some useful comments.
>>>>The thing I like most, Yorian, is that it is well formatted! I
>>>>don't
>>>>know
>>>>what language the comments are in, however I do recognize
>>>>'singleton'.
>>>>For
>>>>the classes that are singletons, you need to make the
>>>>__constructor a
>>>>private function and use the 'static' keyword for the other
>>>>functions/variables in the class. You'd necissarily need a way to
>>>>supply
>>>>those singletons the constructor args. You can either let the
>>>>caller set
>>>>the
>>>>values via 'setters' and/or create a static function, like
>>>>'initialize',
>>>>that essentially carries out the responsibility of __construct.
>>>>You
>>>>should
>>>>also think about defining __clone, __copy, etc. specifically as
>>>>private
>>>>so
>>>>that you are guaranteed not to have more than one instance of the
>>>>singleton.
>>>>Again, I like the code most because I can readily tell what it is
>>>>doing...because it is well formatted. Above all, that will save
>>>>time,
>>>>money,
>>>>and frustration when you need to add to it or modify it in some
>>>>way in
>>>>the
>>>>future.
>>>>Cheers
>>>Instead of using all of those getAttribute methods, you could use a
>>>generic __get method that returns the attribute.
>>>Thomas
>>Ah, my fault, it's late. I meant that you can use __get to point to
>>those methods automatically using call_user_func. So that
>>$userInstance->last_name would call that method.
>>========
>>IMO, that's very bad advice. __get and __set only get executed when
>>a caller
>>tries to access an *undefined* interface. You're abusing the actual
>>intent
>>of __get/set. It makes it terribly hard to debug and manage. It
>>doesn't
>>allow you to strongly type the input(s) or output(s). It's also a
>>performance hit. Further, you should notice tools like php
>>documentor and
>>any screen dump of the object would not accurately show any
>>validation for
>>the properties being set. I'd think about always being specific and
>>not try
>>to rig the jury to obtain the get/set functionality that is supplied
>>by
>>other oop languages. __get and __set are NOT php's version of other
>>languages' get/set construct.
>Sorry, Python's my first language and this sort of thing works very
>cleanly there. I'll keep these drawbacks in mind: I guess that
>__get's
>not quite ready for primetime.
>Thomas
In addition, the generic __get and __set methods are contrary to good
OO
design, even in Python.
>
Part of good OO design is to keep separate things separate - that
includes attributes. Independent getter and setter methods, while a
paid to code, do this quite nicely. They also allow for easier
validation/massage of the data. A single __get/__set method pair does
not do this.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.

Thomas
Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.

That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.

Jerry, Jerry, Jerry!

The 'need' could be as simple as convenience! OOP languages bind getters
and setters directly into the properties available to the caller...such
that:

Convenience != good design! There is nothing to replace a good design.
Your "convenience" is just plain laziness.

Christ Almighty! I KNEW you worked for IBM!!!
And yes, damn those point-n-click Windows users!

>object.property = something // initiates a __set

and

print object.property // initiates a __get

Good OO design does not allow such actions.
Uh, didn't you just mention C++ and Java? Are you *trying* to make people
think you're retarded?!
>That's not so hard to understand! And while Java and C++ fit the bill, I
hardly would hold SmallTalk up as a beacon for OOP! However, ALL of those
languages operate in the way I've just displayed. Thomas is simply trying
to coerse php to do what the rest of us hope it eventually will...give us
the same or similar constructs.

SmallTalk is a good OO language. But NONE of them operate in the way you
would like. If property is private, as it should be, then object.property
(unless in a member function) will cause a compile time error.
I see now. It's your illiteracy kicking in! Further, you compensate by
offering a straw-man. You are great fun, Jerry! You've just said all
properties of an object should be private. That's great! One has nothing to
do with the other, Jerry!

The problem is not that OOP languages don't operate in the way I'd
like...it's that you don't even know what discussion is being had! That, or
you simply have NO clue.
>BTW, quit accusing Thomas of bad design! If you read his suggestion,
you'd have noticed that he's not balling up all of his validation in
__get/set as you've twice accused him of. He suggested using php's call
user func function...I said it could be as easy as a switch statement and
a direct call to the getter/setter. Thus far, your arguments are MOOT.
You've only to state that "there is no need for the __get/__set methods"
(if you've already defined getters/setters). Ok then! Statement noted.

We already know how you program. Your previous "answer" is proof of that.
>Do you ever offer advice that actually further's someone's understanding
of php or help better the content of a thread in which you've posted,
Jerry? I can't see that you do.

ROFLMAO. This from some newbie who doesn't have any idea what good
programming is all about.
yawn...trolling ignored.
Nov 10 '08 #19

P: n/a
703designs wrote:
On Nov 10, 11:11 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>Jessica Griego wrote:
>>"Jerry Stuckle" <jstuck...@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
703designs wrote:
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>703designs wrote:
>>On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
>>>"703designs" <thomasmal...@gmail.comwrote in message
>>>news:87**********************************@a 26g2000prf.googlegroups.com...
>>>On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>>>>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>>>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>>>>news:8b********************************** @t39g2000prh.googlegroups.com...
>>>>>>Hey,
>>>>>>Although I've been using classes and object for quite a while now
>>>>>>I've
>>>>>>never actually programmed proper OO code yet. It ofcourse depends
>>>>>>on
>>>>>>what you call proper OO code. I have been seperating parts of the
>>>>>>website. Like a user class, guestbook class, etc. But I've been
>>>>>>putting all the code in one single class instead of of spreiding
>>>>>>it.
>>>>>>Since a short while I've been reading up on OOP and now I am trying
>>>>>>to
>>>>>>actually do things the way they should be done to make a nice
>>>>>>maintainable module. Which in fact means that I'm trying to stick
>>>>>>to
>>>>>>some rules: Don't repeat yourself, seperation of concerns,
>>>>>>encapsulation, etc.
>>>>>>I've created (not finished just started it) a user system, this
>>>>>>according to the mvc pattern. The names for the classes aren't
>>>>>>perfect
>>>>>>(user should actually be named userController, and userData should
>>>>>>be
>>>>>>named user, etc.).
>>>>>>Could any of you guys have a look and see if I'm going in the right
>>>>>>direction?
>>>>>>The few classes (put in a single file for the sake of easy reading)
>>>>>>can be found here:http://web-develop.nl/user_oop.phps
>>>>>>Hope you guys can give me some useful comments.
>>>>>The thing I like most, Yorian, is that it is well formatted! I don't
>>>>>know
>>>>>what language the comments are in, however I do recognize
>>>>>'singleton'.
>>>>>For
>>>>>the classes that are singletons, you need to make the __constructor
>>>>>a
>>>>>private function and use the 'static' keyword for the other
>>>>>functions/variables in the class. You'd necissarily need a way to
>>>>>supply
>>>>>those singletons the constructor args. You can either let the caller
>>>>>set
>>>>>the
>>>>>values via 'setters' and/or create a static function, like
>>>>>'initialize',
>>>>>that essentially carries out the responsibility of __construct. You
>>>>>should
>>>>>also think about defining __clone, __copy, etc. specifically as
>>>>>private
>>>>>so
>>>>>that you are guaranteed not to have more than one instance of the
>>>>>singleton.
>>>>>Again, I like the code most because I can readily tell what it is
>>>>>doing...because it is well formatted. Above all, that will save
>>>>>time,
>>>>>money,
>>>>>and frustration when you need to add to it or modify it in some way
>>>>>in
>>>>>the
>>>>>future.
>>>>>Cheers
>>>>Instead of using all of those getAttribute methods, you could use a
>>>>generic __get method that returns the attribute.
>>>>Thomas
>>>Ah, my fault, it's late. I meant that you can use __get to point to
>>>those methods automatically using call_user_func. So that
>>>$userInstance->last_name would call that method.
>>>========
>>>IMO, that's very bad advice. __get and __set only get executed when a
>>>caller
>>>tries to access an *undefined* interface. You're abusing the actual
>>>intent
>>>of __get/set. It makes it terribly hard to debug and manage. It
>>>doesn't
>>>allow you to strongly type the input(s) or output(s). It's also a
>>>performance hit. Further, you should notice tools like php documentor
>>>and
>>>any screen dump of the object would not accurately show any validation
>>>for
>>>the properties being set. I'd think about always being specific and
>>>not try
>>>to rig the jury to obtain the get/set functionality that is supplied
>>>by
>>>other oop languages. __get and __set are NOT php's version of other
>>>languages' get/set construct.
>>Sorry, Python's my first language and this sort of thing works very
>>cleanly there. I'll keep these drawbacks in mind: I guess that __get's
>>not quite ready for primetime.
>>Thomas
>In addition, the generic __get and __set methods are contrary to good OO
>design, even in Python.
>Part of good OO design is to keep separate things separate - that
>includes attributes. Independent getter and setter methods, while a
>paid to code, do this quite nicely. They also allow for easier
>validation/massage of the data. A single __get/__set method pair does
>not do this.
>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>jstuck...@attglobal.net
>==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.
Thomas
Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.
That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.
Jerry, Jerry, Jerry!
The 'need' could be as simple as convenience! OOP languages bind getters and
setters directly into the properties available to the caller...such that:
Convenience != good design! There is nothing to replace a good design.
Your "convenience" is just plain laziness.
>>object.property = something // initiates a __set
and
print object.property // initiates a __get
Good OO design does not allow such actions.
>>That's not so hard to understand! And while Java and C++ fit the bill, I
hardly would hold SmallTalk up as a beacon for OOP! However, ALL of those
languages operate in the way I've just displayed. Thomas is simply trying to
coerse php to do what the rest of us hope it eventually will...give us the
same or similar constructs.
SmallTalk is a good OO language. But NONE of them operate in the way
you would like. If property is private, as it should be, then
object.property (unless in a member function) will cause a compile time
error.
>>BTW, quit accusing Thomas of bad design! If you read his suggestion, you'd
have noticed that he's not balling up all of his validation in __get/set as
you've twice accused him of. He suggested using php's call user func
function...I said it could be as easy as a switch statement and a direct
call to the getter/setter. Thus far, your arguments are MOOT. You've only to
state that "there is no need for the __get/__set methods" (if you've already
defined getters/setters). Ok then! Statement noted.
We already know how you program. Your previous "answer" is proof of that.
>>Do you ever offer advice that actually further's someone's understanding of
php or help better the content of a thread in which you've posted, Jerry? I
can't see that you do.
ROFLMAO. This from some newbie who doesn't have any idea what good
programming is all about.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

First of all, don't go flinging crap like "newbie" around here. You'll
only piss others off.
So show me where "Jessica Griego" has posted here before.
Second, design quality is subjective, and I don't bow before any OO
deities. Have you forgotten which mailing list you're on? We'd be
elsewhere if we favored design to implementation.
Yes, it is subjective. But there are numerous GOOD books on what is
good OO design and what is not.

PHP is not a good OO language. It's slowly but surely approaching a
half-way decent OO language status. But don't go by PHP books as to
what is "good" or "poor" design. Rather, you should read solid OO
design books which are language independent to find out what's "good" or
"bad".

And design is ALL ABOUT implementation. If you want a house built, what
do you do - had a carpenter some boards and nails and tell him to "build
me a house"? No - you hire an architect to design the house first.
Then the carpenter implements it. The same with the car you drive - it
was designed, right down to the last bolt. And then the design was
implemented.

But this is too often overlooked in programming - especially with a lot
of programmers who learn "by the seat of their pants" and never have the
advantage of working with more knowledgeable people. Then we get
languages like PHP, which, quite frankly, was not designed well from the
outset, and you have a recipe for problems.

PHP is improving - I will give the people at Zend credit for that. But
it still has a ways to go. Each version is better than the previous one.
Third, I rescinded my recommendation of __get in, like, the third post
here after Jessica helpfully clarified how lame it is.

Thomas
I wouldn't necessarily call it "lame". But I would say it is poor practice.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 10 '08 #20

P: n/a
On Nov 10, 11:59*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
On Nov 10, 11:11 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
Jessica Griego wrote:
"Jerry Stuckle" <jstuck...@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
703designs wrote:
On Nov 10, 6:02 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
703designs wrote:
>On Nov 9, 11:28 pm, "Jessica Griego" <j...@example.comwrote:
>>"703designs" <thomasmal...@gmail.comwrote in message
>>>news:87**********************************@a 26g2000prf.googlegroups.com...
>>On Nov 9, 10:46 pm, 703designs <thomasmal...@gmail.comwrote:
>>>On Nov 9, 10:37 pm, "Jessica Griego" <j...@example.comwrote:
>>>>"Yorian" <yorianbenja...@hotmail.comwrote in message
>>>>>news:8b********************************** @t39g2000prh.googlegroups.com...
>>>>>Hey,
>>>>>Although I've been using classes and object for quite a whilenow
>>>>>I've
>>>>>never actually programmed proper OO code yet. It ofcourse depends
>>>>>on
>>>>>what you call proper OO code. I have been seperating parts ofthe
>>>>>website. Like a user class, guestbook class, etc. But I've been
>>>>>putting all the code in one single class instead of of spreiding
>>>>>it.
>>>>>Since a short while I've been reading up on OOP and now I am trying
>>>>>to
>>>>>actually do things the way they should be done to make a nice
>>>>>maintainable module. Which in fact means that I'm trying to stick
>>>>>to
>>>>>some rules: Don't repeat yourself, seperation of concerns,
>>>>>encapsulation, etc.
>>>>>I've created (not finished just started it) a user system, this
>>>>>according to the mvc pattern. The names for the classes aren't
>>>>>perfect
>>>>>(user should actually be named userController, and userData should
>>>>>be
>>>>>named user, etc.).
>>>>>Could any of you guys have a look and see if I'm going in theright
>>>>>direction?
>>>>>The few classes (put in a single file for the sake of easy reading)
>>>>>can be found here:http://web-develop.nl/user_oop.phps
>>>>>Hope you guys can give me some useful comments.
>>>>The thing I like most, Yorian, is that it is well formatted! Idon't
>>>>know
>>>>what language the comments are in, however I do recognize
>>>>'singleton'.
>>>>For
>>>>the classes that are singletons, you need to make the __constructor
>>>>a
>>>>private function and use the 'static' keyword for the other
>>>>functions/variables in the class. You'd necissarily need a wayto
>>>>supply
>>>>those singletons the constructor args. You can either let the caller
>>>>set
>>>>the
>>>>values via 'setters' and/or create a static function, like
>>>>'initialize',
>>>>that essentially carries out the responsibility of __construct.. You
>>>>should
>>>>also think about defining __clone, __copy, etc. specifically as
>>>>private
>>>>so
>>>>that you are guaranteed not to have more than one instance of the
>>>>singleton.
>>>>Again, I like the code most because I can readily tell what itis
>>>>doing...because it is well formatted. Above all, that will save
>>>>time,
>>>>money,
>>>>and frustration when you need to add to it or modify it in some way
>>>>in
>>>>the
>>>>future.
>>>>Cheers
>>>Instead of using all of those getAttribute methods, you could use a
>>>generic __get method that returns the attribute.
>>>Thomas
>>Ah, my fault, it's late. I meant that you can use __get to pointto
>>those methods automatically using call_user_func. So that
>>$userInstance->last_name would call that method.
>>========
>>IMO, that's very bad advice. __get and __set only get executed when a
>>caller
>>tries to access an *undefined* interface. You're abusing the actual
>>intent
>>of __get/set. It makes it terribly hard to debug and manage. It
>>doesn't
>>allow you to strongly type the input(s) or output(s). It's also a
>>performance hit. Further, you should notice tools like php documentor
>>and
>>any screen dump of the object would not accurately show any validation
>>for
>>the properties being set. I'd think about always being specific and
>>not try
>>to rig the jury to obtain the get/set functionality that is supplied
>>by
>>other oop languages. __get and __set are NOT php's version of other
>>languages' get/set construct.
>Sorry, Python's my first language and this sort of thing works very
>cleanly there. I'll keep these drawbacks in mind: I guess that __get's
>not quite ready for primetime.
>Thomas
In addition, the generic __get and __set methods are contrary to good OO
design, even in Python.
Part of good OO design is to keep separate things separate - that
includes attributes. *Independent getter and setter methods, while a
paid to code, do this quite nicely. *They also allow for easier
validation/massage of the data. *A single __get/__set method pair does
not do this.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I never said that a single get/set pair should do that. Another part
of good OO design is to not reference object attributes directly, but
rather to always have getter and setter methods.
Thomas
Then if each attribute has it's own get/set pair (as in good OO design),
there is no need for the __get/__set methods.
That's why you won't find them in good OO languages such as SmallTalk,
Java and even C++.
Jerry, Jerry, Jerry!
The 'need' could be as simple as convenience! OOP languages bind getters and
setters directly into the properties available to the caller...such that:
Convenience != good design! *There is nothing to replace a good design.
* Your "convenience" is just plain laziness.
>object.property = something // initiates a __set
and
print object.property * * * // initiates a __get
Good OO design does not allow such actions.
>That's not so hard to understand! And while Java and C++ fit the bill, I
hardly would hold SmallTalk up as a beacon for OOP! However, ALL of those
languages operate in the way I've just displayed. Thomas is simply trying to
coerse php to do what the rest of us hope it eventually will...give us the
same or similar constructs.
SmallTalk is a good OO language. *But NONE of them operate in the way
you would like. *If property is private, as it should be, then
object.property (unless in a member function) will cause a compile time
error.
>BTW, quit accusing Thomas of bad design! If you read his suggestion, you'd
have noticed that he's not balling up all of his validation in __get/set as
you've twice accused him of. He suggested using php's call user func
function...I said it could be as easy as a switch statement and a direct
call to the getter/setter. Thus far, your arguments are MOOT. You've only to
state that "there is no need for the __get/__set methods" (if you've already
defined getters/setters). Ok then! Statement noted.
We already know how you program. *Your previous "answer" is proof ofthat.
>Do you ever offer advice that actually further's someone's understanding of
php or help better the content of a thread in which you've posted, Jerry? I
can't see that you do.
ROFLMAO. *This from some newbie who doesn't have any idea what good
programming is all about.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
First of all, don't go flinging crap like "newbie" around here. You'll
only piss others off.

So show me where "Jessica Griego" has posted here before.
Second, design quality is subjective, and I don't bow before any OO
deities. Have you forgotten which mailing list you're on? We'd be
elsewhere if we favored design to implementation.

Yes, it is subjective. *But there are numerous GOOD books on what is
good OO design and what is not.

PHP is not a good OO language. *It's slowly but surely approaching a
half-way decent OO language status. *But don't go by PHP books as to
what is "good" or "poor" design. *Rather, you should read solid OO
design books which are language independent to find out what's "good" or
"bad".

And design is ALL ABOUT implementation. *If you want a house built, what
do you do - had a carpenter some boards and nails and tell him to "build
me a house"? *No - you hire an architect to design the house first.
Then the carpenter implements it. *The same with the car you drive - it
was designed, right down to the last bolt. *And then the design was
implemented.

But this is too often overlooked in programming - especially with a lot
of programmers who learn "by the seat of their pants" and never have the
advantage of working with more knowledgeable people. *Then we get
languages like PHP, which, quite frankly, was not designed well from the
outset, and you have a recipe for problems.

PHP is improving - I will give the people at Zend credit for that. *But
it still has a ways to go. *Each version is better than the previous one.
Third, I rescinded my recommendation of __get in, like, the third post
here after Jessica helpfully clarified how lame it is.
Thomas

I wouldn't necessarily call it "lame". *But I would say it is...

read more
I don't credit lifting Java's OO model as much of a gift by the Zend
folks. It feels just as bolted on as Perl OO, and the PHP guys
could've done much better -- elegance over verbosity.
But this is too often overlooked in programming - especially with a lot
of programmers who learn "by the seat of their pants" and never have the
advantage of working with more knowledgeable people.
Some day we'll be blessed to study under you...
I wouldn't necessarily call it "lame".
For those of us used to more effective magic methods, __get and __set
are indeed quite lame.

Thomas
Nov 10 '08 #21

P: n/a
On Mon, 10 Nov 2008 11:11:08 -0500, Jerry Stuckle
<js*******@attglobal.netwrote in
<gf**********@registered.motzarella.org>:
>Jessica Griego wrote:
[snip thread about using __get and __set to handle interface
attributes]
Your "convenience" is just plain laziness.
>object.property = something // initiates a __set

and

print object.property // initiates a __get

Good OO design does not allow such actions.
Hm. I don't think that I agree with your statement as I understand
it. Take C# for example:

public class Foo
{
private int m_i = 0;

public Foo() {}

public int i
{
get { return m_i; }
set
{
// i must have a value between 0 and 10
if (value < 0 || value 10)
throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
else
m_i = value;
}
}
}

// Some other code
try
{
Foo f = new Foo();
f.i = 10; // okay
f.i = 11; // exception thrown here
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to 11!");
}
This is a trivial example, of course, but you can do all sorts of
interesting things with properties in C#, such as have one that
returns a calculated value, implement only the getter, etc. Is this
anything that can't be done with methods? No, but it can make the
syntax easier to read:

iTeachersPerStudent = Class.StudentCount / Class.TeacherCount;

vs.

iTeachersPerStudent = Class.GetStudentCount() /
Class.GetTeacherCount();

It's just syntax candy, but then anything other than ones and zeros is
just syntax candy. I, for one, wouldn't mind if PHP had such syntax
candy, providing that it were implemented properly.

--
Charles Calvert | Web-site Design/Development
Celtic Wolf, Inc. | Software Design/Development
http://www.celticwolf.com/ | Data Conversion
(703) 580-0210 | Project Management
Nov 10 '08 #22

P: n/a

"Charles Calvert" <cb***@yahoo.comwrote in message
news:ti********************************@4ax.com...
On Mon, 10 Nov 2008 11:11:08 -0500, Jerry Stuckle
<js*******@attglobal.netwrote in
<gf**********@registered.motzarella.org>:
>>Jessica Griego wrote:

[snip thread about using __get and __set to handle interface
attributes]
> Your "convenience" is just plain laziness.
>>object.property = something // initiates a __set

and

print object.property // initiates a __get

Good OO design does not allow such actions.

Hm. I don't think that I agree with your statement as I understand
it. Take C# for example:

public class Foo
{
private int m_i = 0;

public Foo() {}

public int i
{
get { return m_i; }
set
{
// i must have a value between 0 and 10
if (value < 0 || value 10)
throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
else
m_i = value;
}
}
}

// Some other code
try
{
Foo f = new Foo();
f.i = 10; // okay
f.i = 11; // exception thrown here
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to 11!");
}
This is a trivial example, of course, but you can do all sorts of
interesting things with properties in C#, such as have one that
returns a calculated value, implement only the getter, etc. Is this
anything that can't be done with methods? No, but it can make the
syntax easier to read:

iTeachersPerStudent = Class.StudentCount / Class.TeacherCount;

vs.

iTeachersPerStudent = Class.GetStudentCount() /
Class.GetTeacherCount();

It's just syntax candy, but then anything other than ones and zeros is
just syntax candy. I, for one, wouldn't mind if PHP had such syntax
candy, providing that it were implemented properly.
Hey Charles. It seems Jerry is just prone to trolling. He already snipped my
VB.Net example that essentially showed the same thing. And btw, I just
noticed his sig. What exactly *can* JDS teach if JDS *is* Jerry
Stuckle...and this is the tripe he's espousing here. Just a thought.

Cheers.
Nov 10 '08 #23

P: n/a
Charles Calvert wrote:
On Mon, 10 Nov 2008 11:11:08 -0500, Jerry Stuckle
<js*******@attglobal.netwrote in
<gf**********@registered.motzarella.org>:
>Jessica Griego wrote:

[snip thread about using __get and __set to handle interface
attributes]
> Your "convenience" is just plain laziness.
>>object.property = something // initiates a __set

and

print object.property // initiates a __get
Good OO design does not allow such actions.

Hm. I don't think that I agree with your statement as I understand
it. Take C# for example:

public class Foo
{
private int m_i = 0;

public Foo() {}

public int i
{
get { return m_i; }
set
{
// i must have a value between 0 and 10
if (value < 0 || value 10)
throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
else
m_i = value;
}
}
}

// Some other code
try
{
Foo f = new Foo();
f.i = 10; // okay
f.i = 11; // exception thrown here
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to 11!");
}
This is a trivial example, of course, but you can do all sorts of
interesting things with properties in C#, such as have one that
returns a calculated value, implement only the getter, etc. Is this
anything that can't be done with methods? No, but it can make the
syntax easier to read:

iTeachersPerStudent = Class.StudentCount / Class.TeacherCount;

vs.

iTeachersPerStudent = Class.GetStudentCount() /
Class.GetTeacherCount();

It's just syntax candy, but then anything other than ones and zeros is
just syntax candy. I, for one, wouldn't mind if PHP had such syntax
candy, providing that it were implemented properly.
Charles,

I did say GOOD OO design :-).

Yes, something like this is handy (basically, it's a carryover from
VBScript objects), but I personally don't find it to be a real good
design. It can get very confusing, very quickly (what happens if you
don't use a try/catch block, for instance)? It forces you to use these,
when something like:

class Foo {
private int m_i;

public int setI(i) {
if (i 0 && i < 10) {
m_i = i;
return true;
}
return false;
}

Foo f = new Foo();
if (f.setI(10)) {
...

Of course, if you want the try/catch block so you can handle it at a
higher level, you can always do something like:

if (!f.setI(11))
throw new System.InvalidArgumentException('Invalid value for i');

Or, it still allows you to do it in the function itself, ie.

public void setI(i) {
if (i 0 && i < 10) {
m_i = i;
}
else throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
}

The big problem is that C#'s implementation limits you as to how you can
do it (if you use their property methods).

As for your example - you can easily have a method which does the
calculations for you, i.e

iTeachersPerStudent = Class.GetTeachersPerStudent().

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 10 '08 #24

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
Charles Calvert wrote:
>On Mon, 10 Nov 2008 11:11:08 -0500, Jerry Stuckle
<js*******@attglobal.netwrote in
<gf**********@registered.motzarella.org>:
>>Jessica Griego wrote:

[snip thread about using __get and __set to handle interface
attributes]
>> Your "convenience" is just plain laziness.

object.property = something // initiates a __set

and

print object.property // initiates a __get

Good OO design does not allow such actions.

Hm. I don't think that I agree with your statement as I understand
it. Take C# for example:

public class Foo
{
private int m_i = 0;

public Foo() {}

public int i
{
get { return m_i; }
set
{
// i must have a value between 0 and 10
if (value < 0 || value 10)
throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
else
m_i = value;
}
}
}

// Some other code
try
{
Foo f = new Foo();
f.i = 10; // okay
f.i = 11; // exception thrown here
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to 11!");
}
This is a trivial example, of course, but you can do all sorts of
interesting things with properties in C#, such as have one that
returns a calculated value, implement only the getter, etc. Is this
anything that can't be done with methods? No, but it can make the
syntax easier to read:

iTeachersPerStudent = Class.StudentCount / Class.TeacherCount;

vs.

iTeachersPerStudent = Class.GetStudentCount() /
Class.GetTeacherCount();

It's just syntax candy, but then anything other than ones and zeros is
just syntax candy. I, for one, wouldn't mind if PHP had such syntax
candy, providing that it were implemented properly.

Charles,

I did say GOOD OO design :-).
Uh, it doesn't look as if you know what that is, Jerry!
Yes, something like this is handy (basically, it's a carryover from
VBScript objects), but I personally don't find it to be a real good
design. It can get very confusing, very quickly (what happens if you
don't use a try/catch block, for instance)? It forces you to use these,
when something like:
Whether you throw an exception within a try/catch or from a getter/setter
function, you still get an error. You are only forced to correct the error,
not where you put the handling thereof. Charles could have just as easily
returned a boolean true/false from the setter and never have thrown an
exception. This is BAD design since you are leaving the caller to catch the
oversight. He'll end up wondering why his results are jacked up. It will
come down to the fact that he tried to use 11 AND didn't check to see if the
value 'took'. Very bad design indeed. You are the spokesperson for 'good'
design? I just don't see how you could be, Jerry!
class Foo {
private int m_i;

public int setI(i) {
if (i 0 && i < 10) {
m_i = i;
return true;
}
return false;
}

Foo f = new Foo();
if (f.setI(10)) {
...

Of course, if you want the try/catch block so you can handle it at a
higher level, you can always do something like:

if (!f.setI(11))
throw new System.InvalidArgumentException('Invalid value for i');

Or, it still allows you to do it in the function itself, ie.

public void setI(i) {
if (i 0 && i < 10) {
m_i = i;
}
else throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
}
What's the difference between IF-ing a setter or trying/catching when
setting via normal OOP property 'syntax candy'? Not much...the words IF/ELSE
and TRY/CATCH maybe.
The big problem is that C#'s implementation limits you as to how you can
do it (if you use their property methods).
You need to qualify this with a real-world example, Jerry. As it is, that
statement is a load of hog-wash!
As for your example - you can easily have a method which does the
calculations for you, i.e

iTeachersPerStudent = Class.GetTeachersPerStudent().
But why does he need to? What's the compelling argument to do that?

Class.TeachersPerStudent as a property is just fine. It is also far more
clear to the caller when it is a read/write property than if everything is
treated as a function prefixed by either get or set. And also, please tell
me the 'i' in iTeachersPerStudent isn't the amateurist's mistake of using
hungarian notation...right?!!!
Nov 10 '08 #25

P: n/a
On Mon, 10 Nov 2008 15:06:35 -0500, Jerry Stuckle
<js*******@attglobal.netwrote in
<gf**********@registered.motzarella.org>:
>Charles Calvert wrote:
>On Mon, 10 Nov 2008 11:11:08 -0500, Jerry Stuckle
<js*******@attglobal.netwrote in
<gf**********@registered.motzarella.org>:
>>Jessica Griego wrote:

[snip thread about using __get and __set to handle interface
attributes]
>> Your "convenience" is just plain laziness.

object.property = something // initiates a __set

and

print object.property // initiates a __get

Good OO design does not allow such actions.

Hm. I don't think that I agree with your statement as I understand
it. Take C# for example:

public class Foo
{
private int m_i = 0;

public Foo() {}

public int i
{
get { return m_i; }
set
{
// i must have a value between 0 and 10
if (value < 0 || value 10)
throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
else
m_i = value;
}
}
}

// Some other code
try
{
Foo f = new Foo();
f.i = 10; // okay
f.i = 11; // exception thrown here
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to 11!");
}
This is a trivial example, of course, but you can do all sorts of
interesting things with properties in C#, such as have one that
returns a calculated value, implement only the getter, etc. Is this
anything that can't be done with methods? No, but it can make the
syntax easier to read:

iTeachersPerStudent = Class.StudentCount / Class.TeacherCount;

vs.

iTeachersPerStudent = Class.GetStudentCount() /
Class.GetTeacherCount();

It's just syntax candy, but then anything other than ones and zeros is
just syntax candy. I, for one, wouldn't mind if PHP had such syntax
candy, providing that it were implemented properly.

I did say GOOD OO design :-).

Yes, something like this is handy (basically, it's a carryover from
VBScript objects), but I personally don't find it to be a real good
design. It can get very confusing, very quickly (what happens if you
don't use a try/catch block, for instance)?
That can be a problem with methods that throw exceptions as well. When
using a platform on which exceptions can be thrown, one should always
take that into account. Since the .NET libraries may throw
exceptions, you can't ignore them even if your code doesn't. This is
different than the current state of PHP (absent any frameworks) of
course, but it wouldn't surprise me if things continue moving in that
direction; many other popular OO languages, such as Python and Ruby,
use exceptions in the standard libraries.
It forces you to use these, when something like:

class Foo {
private int m_i;

public int setI(i) {
if (i 0 && i < 10) {
m_i = i;
return true;
}
return false;
}

Foo f = new Foo();
if (f.setI(10)) {
...

Of course, if you want the try/catch block so you can handle it at a
higher level, you can always do something like:

if (!f.setI(11))
throw new System.InvalidArgumentException('Invalid value for i');

Or, it still allows you to do it in the function itself, ie.

public void setI(i) {
if (i 0 && i < 10) {
m_i = i;
}
else throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
}

The big problem is that C#'s implementation limits you as to how you can
do it (if you use their property methods).
True, but given that .NET uses exceptions throughout the standard
libraries, avoiding them in one's own code for exceptional errors
(rather than common errors) is pointless. In fact, if one has an
exception handling structure set up in one's application, one could
argue that avoiding them is the bad design choice.

However, that doesn't carry over to PHP in it's current state,
obviously. We'll have to see what Zend does with it in the future.
>As for your example - you can easily have a method which does the
calculations for you, i.e

iTeachersPerStudent = Class.GetTeachersPerStudent().
Sure. There are many ways to skin a cat. I happen to like doing it
with properties when working in C#. :)
--
Charles Calvert | Web-site Design/Development
Celtic Wolf, Inc. | Software Design/Development
http://www.celticwolf.com/ | Data Conversion
(703) 580-0210 | Project Management
Nov 10 '08 #26

P: n/a
Charles Calvert wrote:
On Mon, 10 Nov 2008 15:06:35 -0500, Jerry Stuckle
<js*******@attglobal.netwrote in
<gf**********@registered.motzarella.org>:
>Charles Calvert wrote:
>>On Mon, 10 Nov 2008 11:11:08 -0500, Jerry Stuckle
<js*******@attglobal.netwrote in
<gf**********@registered.motzarella.org>:

Jessica Griego wrote:
[snip thread about using __get and __set to handle interface
attributes]

Your "convenience" is just plain laziness.

object.property = something // initiates a __set
>
and
>
print object.property // initiates a __get
>
Good OO design does not allow such actions.
Hm. I don't think that I agree with your statement as I understand
it. Take C# for example:

public class Foo
{
private int m_i = 0;

public Foo() {}

public int i
{
get { return m_i; }
set
{
// i must have a value between 0 and 10
if (value < 0 || value 10)
throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
else
m_i = value;
}
}
}

// Some other code
try
{
Foo f = new Foo();
f.i = 10; // okay
f.i = 11; // exception thrown here
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to 11!");
}
This is a trivial example, of course, but you can do all sorts of
interesting things with properties in C#, such as have one that
returns a calculated value, implement only the getter, etc. Is this
anything that can't be done with methods? No, but it can make the
syntax easier to read:

iTeachersPerStudent = Class.StudentCount / Class.TeacherCount;

vs.

iTeachersPerStudent = Class.GetStudentCount() /
Class.GetTeacherCount();

It's just syntax candy, but then anything other than ones and zeros is
just syntax candy. I, for one, wouldn't mind if PHP had such syntax
candy, providing that it were implemented properly.
I did say GOOD OO design :-).

Yes, something like this is handy (basically, it's a carryover from
VBScript objects), but I personally don't find it to be a real good
design. It can get very confusing, very quickly (what happens if you
don't use a try/catch block, for instance)?

That can be a problem with methods that throw exceptions as well. When
using a platform on which exceptions can be thrown, one should always
take that into account. Since the .NET libraries may throw
exceptions, you can't ignore them even if your code doesn't. This is
different than the current state of PHP (absent any frameworks) of
course, but it wouldn't surprise me if things continue moving in that
direction; many other popular OO languages, such as Python and Ruby,
use exceptions in the standard libraries.
Very true. However, if you use set/get methods, you have the choice.
Your try/catch blocks can quickly become unwieldy, especially if you are
setting a bunch of items at the same time, i.e.

try
{
f.i = 10;
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to 11!");
}

try
{
f.j = "abc";
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to abc!");
}

try
{
f.k = 100;
}
catch (System.InvalidArgumentException ex)
{
Console.Write("Shouldn't have set it to 100!");
}

vs.

if (!f.setI(10))
{
Console.Write("Shouldn't have set it to 11!");
}

if (f.setJ("abc"))
{
Console.Write("Shouldn't have set it to abc!");
}

if (f.setK(100))
{
Console.Write("Shouldn't have set it to 100!");
}
>It forces you to use these, when something like:

class Foo {
private int m_i;

public int setI(i) {
if (i 0 && i < 10) {
m_i = i;
return true;
}
return false;
}

Foo f = new Foo();
if (f.setI(10)) {
...

Of course, if you want the try/catch block so you can handle it at a
higher level, you can always do something like:

if (!f.setI(11))
throw new System.InvalidArgumentException('Invalid value for i');

Or, it still allows you to do it in the function itself, ie.

public void setI(i) {
if (i 0 && i < 10) {
m_i = i;
}
else throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
}

The big problem is that C#'s implementation limits you as to how you can
do it (if you use their property methods).

True, but given that .NET uses exceptions throughout the standard
libraries, avoiding them in one's own code for exceptional errors
(rather than common errors) is pointless. In fact, if one has an
exception handling structure set up in one's application, one could
argue that avoiding them is the bad design choice.
Yes, but if you use those libraries in your set methods, you can handle
the exceptions in the method itself.
However, that doesn't carry over to PHP in it's current state,
obviously. We'll have to see what Zend does with it in the future.
Very true.
>As for your example - you can easily have a method which does the
calculations for you, i.e

iTeachersPerStudent = Class.GetTeachersPerStudent().

Sure. There are many ways to skin a cat. I happen to like doing it
with properties when working in C#. :)
I never have liked the properties interface in C#. But that's just my
own feeling - from too many years in C++ and Java. :-)

And too many years in VBScript :-(

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 10 '08 #27

P: n/a
On Mon, 10 Nov 2008 14:34:21 -0600, "Jessica Griego"
<je**@example.comwrote in
<9V*****************@nlpi069.nbdc.sbc.com>:
>
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:gf**********@registered.motzarella.org...
[snip discussion of properties as implemented in C#]
>Foo f = new Foo();
if (f.setI(10)) {
...

Of course, if you want the try/catch block so you can handle it at a
higher level, you can always do something like:

if (!f.setI(11))
throw new System.InvalidArgumentException('Invalid value for i');

Or, it still allows you to do it in the function itself, ie.

public void setI(i) {
if (i 0 && i < 10) {
m_i = i;
}
else throw new System.InvalidArgumentException(
"i must have a value between 0 and 10");
}

What's the difference between IF-ing a setter or trying/catching when
setting via normal OOP property 'syntax candy'? Not much...the words IF/ELSE
and TRY/CATCH maybe.
Actually, there are differences.

1. Each method of error handling lends itself to a different type of
code flow. Consider:

// Get user input

// Set the value of f.i
bool res = f.SetI(input);
if (false == res)
// User is inexperienced; take them to a wizard interface
else
{
// Ask for second input
res = f.SetI(input);
if (false == res)
{
// take path 1
}
else
{
// take path 2
}
}
You could do this with try/catch, but it might be a little ugly,
especially if the exceptions can only be identified by text strings.
On the other hand, using exceptions can make interrupting the flow of
code and bailing out much cleaner than a lot of if...else statements
or multiple returns:

try
{
// task one
// task two
// task three
}
catch (exception e)
{
// clean up all tasks, release resources and bail out
}

2. Exceptions generally have far worse performance than returning a
simple value, because they must unwind the stack, capturing
information as they go.
>The big problem is that C#'s implementation limits you as to how you can
do it (if you use their property methods).

You need to qualify this with a real-world example, Jerry. As it is, that
statement is a load of hog-wash!
No, Jerry's right, as far as it goes. If you use properties, the only
way that you can handle invalid input is to throw an exception. It
does limit your options. Whether that's a problem or not depends on
the architecture of the application and the needs of the particular
class and attribute. I don't agree with Jerry that it's inherently
bad design.
>As for your example - you can easily have a method which does the
calculations for you, i.e

iTeachersPerStudent = Class.GetTeachersPerStudent().

But why does he need to? What's the compelling argument to do that?

Class.TeachersPerStudent as a property is just fine. It is also far more
clear to the caller when it is a read/write property than if everything is
treated as a function prefixed by either get or set. And also, please tell
me the 'i' in iTeachersPerStudent isn't the amateurist's mistake of using
hungarian notation...right?!!!
Hungarian notation, as originally invented by Charles Simonyi, was
intended to indicate the use of the variable with a prefix (e.g. the
prefix "cb" was for "count of bytes"). In the Microsoft world, it
quickly morphed into something to indicate the type of the variable.
While opinions on this usage vary widely, it is quite common in that
arena. I can assure that it's usage in no way designates the user as
an amateur, any more than variable_names_with_underscores indicate
professionalism.

--
Charles Calvert | Web-site Design/Development
Celtic Wolf, Inc. | Software Design/Development
http://www.celticwolf.com/ | Data Conversion
(703) 580-0210 | Project Management
Nov 11 '08 #28

P: n/a
Charles Calvert wrote:
>
You could do this with try/catch, but it might be a little ugly,
especially if the exceptions can only be identified by text strings.
On the other hand, using exceptions can make interrupting the flow of
code and bailing out much cleaner than a lot of if...else statements
or multiple returns:

try
{
// task one
// task two
// task three
}
catch (exception e)
{
// clean up all tasks, release resources and bail out
}
Of course, you can still do this, even if you don't throw exceptions in
the set() function, i.e.

try {
if (!f.setI(11))
throw new Exception("i cannot be set to 11!");
if (!f.setJ('abc'))
throw new Exception("j cannot be set to abc!");
if (!f.setK(1000))
throw new Exception("k cannot be set to 1000!");
}
catch (Exception e) {
....

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 11 '08 #29

P: n/a
On Nov 9, 1:08*pm, Yorian <yorianbenja...@hotmail.comwrote:
Hey,

Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.

Since a short while I've been reading up on OOP and now I am trying to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.

I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).

Could any of you guys have a look and see if I'm going in the right
direction?

The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps

Hope you guys can give me some useful comments.

Thanks
I noticed with an (admittedly quick) glance at your code that you have
a couple of functions with switch statements that contain long blocks
of inline code. May I suggest instead of having that code inline you
move the content of each case statement into its own private
function? That way if you need to do the task associated with each
case somewhere else in the class you can just call the function
instead of duplicating code, and if a need arises later on for some
other part of the program to do that task you can change the function
to protected or public. Also, from a purely aesthetic point of view I
tend to favour shorter functions, but that's just my personal taste. :)
Nov 15 '08 #30

P: n/a
On Nov 15, 12:34*pm, Gordon <gordon.mc...@ntlworld.comwrote:
On Nov 9, 1:08*pm, Yorian <yorianbenja...@hotmail.comwrote:
Hey,
Although I've been using classes and object for quite a while now I've
never actually programmed proper OO code yet. It ofcourse depends on
what you call proper OO code. I have been seperating parts of the
website. Like a user class, guestbook class, etc. But I've been
putting all the code in one single class instead of of spreiding it.
Since a short while I've been reading up on OOP and now I am trying to
actually do things the way they should be done to make a nice
maintainable module. Which in fact means that I'm trying to stick to
some rules: Don't repeat yourself, seperation of concerns,
encapsulation, etc.
I've created (not finished just started it) a user system, this
according to the mvc pattern. The names for the classes aren't perfect
(user should actually be named userController, and userData should be
named user, etc.).
Could any of you guys have a look and see if I'm going in the right
direction?
The few classes (put in a single file for the sake of easy reading)
can be found here:http://web-develop.nl/user_oop.phps
Hope you guys can give me some useful comments.
Thanks

I noticed with an (admittedly quick) glance at your code that you have
a couple of functions with switch statements that contain long blocks
of inline code. *May I suggest instead of having that code inline you
move the content of each case statement into its own private
function? *That way if you need to do the task associated with each
case somewhere else in the class you can just call the function
instead of duplicating code, and if a need arises later on for some
other part of the program to do that task you can change the function
to protected or public. *Also, from a purely aesthetic point of view I
tend to favour shorter functions, but that's just my personal taste. :)
Thnx Gordon,

that's not such a bad idea, I will have a look at it.
Nov 19 '08 #31

This discussion thread is closed

Replies have been disabled for this discussion.