OOP - object design granularity
Posted: Fri Sep 19, 2003 4:48 am
This post is created as a reply to an off topic discussion started here.
I guess that function login ($LoginValues) is a function inside the class user, but I dont see the whole picture.
May I ask you to provide a link to a page that describes the theory?
Now I've read it.
I see the point. It looks very clean when using it.
I'm trying to look at my user class and see what you see.
It's true that I don't validate the $strUsername and $strPassword inside the user object, but they were made safe at initialisation of $objNavigator (read below). They were not validated (ie, checked for bad format), but safe for SQL.
I realise it'll take a couple of years to reach this level of thinking. I started doing some OOP as late as the beginning of this year, but haven't tried to create something with it until summer.
Today I have larger objects than you, but I think they are pretty small and modularised anyway.
**************
I have an object called "objNavigator" that is responsible for ways to redirect the browser in different ways and to secure input. Its constructor performs a check to make sure all $_GET and $_POST values are (kind of) friendly. That's it. I chose it to be responsible for those two things.
The user object:
At least until you showed up, I thought it was good practise to let the user object contain methods to authenticate login and check privileges and such. That is/was my heading.
Why do I make a new thread out of this?
Well, as the header implies, I am interrested in a discussion on how large a class should be. I realise I might start something endless.
Beeing an OOP beginner, and even a more beginner of a class designer, I don't quite follow on that one. Maybe you would like to post some more of the Inspector class than just how you use it?jason wrote:Anyways, what you would be better off doing is separating your validation. Remove it from the user object. In fact, the user object could be thinned to something like:Code: Select all
function login ($LoginValues) { $Validations =& Inspector::validate($LoginValues); $Validations->enforce('username', 'password'); if ( $Validations->isValid() ) { $this->setUsername($LoginValues['username']); $this->intLoggedInId = $this->getUserId(); } }
I guess that function login ($LoginValues) is a function inside the class user, but I dont see the whole picture.
May I ask you to provide a link to a page that describes the theory?
The user object I provided was an embryo. I get your opinion that it maybe should not even get ANY larger. But I guess I'm just a kid in object design, and would like to read more about it. I'll search the "phppatterns.com concerning Strategy patterns" and see what I get.jason wrote:Anyways, the idea is to try and separate your validation from your User object's login method.
Now I've read it.
I see the point. It looks very clean when using it.
I'm trying to look at my user class and see what you see.
It's true that I don't validate the $strUsername and $strPassword inside the user object, but they were made safe at initialisation of $objNavigator (read below). They were not validated (ie, checked for bad format), but safe for SQL.
I realise it'll take a couple of years to reach this level of thinking. I started doing some OOP as late as the beginning of this year, but haven't tried to create something with it until summer.
Today I have larger objects than you, but I think they are pretty small and modularised anyway.
**************
I have an object called "objNavigator" that is responsible for ways to redirect the browser in different ways and to secure input. Its constructor performs a check to make sure all $_GET and $_POST values are (kind of) friendly. That's it. I chose it to be responsible for those two things.
The user object:
At least until you showed up, I thought it was good practise to let the user object contain methods to authenticate login and check privileges and such. That is/was my heading.
Why do I make a new thread out of this?
Well, as the header implies, I am interrested in a discussion on how large a class should be. I realise I might start something endless.