Page 1 of 1

Suggestions on my Project Design

Posted: Mon Apr 24, 2006 6:00 pm
by jeffery
Hi everyone,

I am writing a project (self-study) and seeking your assistance of the design of it. I am not an expert in OOP but learning along the way. So far what I have got is plotted in a UML diagram and I have included some information as to how the applicartion logic flows.

http://members.iinet.net.au/~jfernandez ... ev/uml.jpg

The only problem I am facing now is the Core class is getting instantiate (3) once from the Index class and then again when the appropriate section (10) is being called it is being extended. I would like to avoid it from being called more than once. any suggestions ?

This is just the initial Project design and I am open to suggestions. Thanks!

cheers,
Jeffery

Posted: Mon Apr 24, 2006 8:16 pm
by John Cartwright
I only was trawling the boards since I only have a few minutes, but I think the Singleton Pattern is what you are looking for.

Posted: Mon Apr 24, 2006 9:58 pm
by Christopher
Cool diagram, what is it supposed to do? I'd lose the Core class altogether, typically you don't use super classes like in PHP. What is its purpose? And why does the DB class inherit the Session class?

Posted: Wed Apr 26, 2006 10:40 pm
by jeffery
arborint wrote:Cool diagram, what is it supposed to do? I'd lose the Core class altogether, typically you don't use super classes like in PHP. What is its purpose? And why does the DB class inherit the Session class?
thanks, I will see how I can implement the singleton pattern.

I think the reason I have DB class inheriting from Session class was so that I could make the session class a singleton pattern and also because Sessions are stored in the database. I may have the possiblity of the Database class having multiple instances across the application to do multiple connections.

Posted: Wed Apr 26, 2006 11:33 pm
by alex.barylski
Whoa....it looks more like a network than a library of classes :)

Your over complicating things...

There is no need to:
1) Derive anything from database classes...it's likely most objects which need DB support have a has_a relationship with the DB class not a is_a
That is...they are not a database objet, they only need it's functionality...there is no point to extending the database class. The only time I can think of when one might, is in writting a DB abstraction layer...

If for some reason, you wanted the data store to be bound to your subclass at object instantiation instead of dynamically (sorta) via a connect() you could derive your sub class from a database superclass...

Also, if in your subclass, you wanted to inherit the super class API...for specialized functions (ex: perhaps MySQL and MSSQL used a different connect parameters)

Code: Select all

1) MySQL: connect($user, $pass, $host);
   2) MSSQL: connect($pass, $user, $host);
Notice the difference in function signatures?

MySQL and MSSQL would be your super classes and MineDB would be your subclass which derived from MySQL or MSSQL depending on a define you specified or something similar.

You would use inheritance here, because you need to inherit the interface for connections specific to your data store. You would NOT prototype the connect function in your subclass, but instead rely solely on your superclass (aka driver API) to provide the connection function signature.

This approach isn't ideal nor the best example of implementing a driver interface, but it is a example of when to derive from a database class.
2) Core contains your application permissions? Well, ironically I'm writting a auth library as we speak, so I'm quite familiar with how everything should be layed out.
Authentication/Authorization/Sessions

This triad of components are all that is needed to allow access across your site...

Authentication: Is the process of confirming a users validity - checking login credentials against a data store (albeit; XML or MySQL or Flat files, etc).

Authorization: Is the process of granting permission to a authenticated user to carry out an action.

Sessions: The process of expediting re-authentication (so to speak) via a session cookie or authentication ticket if you will (decreases security risk as well - as plaintext passwords aren't send over the wire). This may at first glance seem like part of Authentication, but logically it is a separate entity and should not be integrated with Authentication implementation. They should communicate only through interface.

The process would go something like:

Code: Select all

//
// Sanitization depends on data store for both 
// session data and ticket persistance
$ticket_id = $_COOKIE['ticket_id']; 
$user_id = is_session_valid($ticket_id); // Return user ID or ZERO on failure
if($user_id){ // 
  $ret = get_role_value($user_id, 'GROUP_NAME', 'VALUE');
  if($ret == TRUE){
    echo 'Carry out task';
  else
    echo 'Incorrect or invalid permission - redirect';
}
else{
  echo 'Show login screen as session NOT valid';
}
If this is what core is attempting to do, I suggest dropping core altogather and calling these classes/functions as demonstrated above as needed in modules like: Language, Log, Template, Setup, etc...

None of those are "types" of any of the three triad components I mentioned earlier, so derivation isn't really proper OOP practice :)

Although, I may be wrong here as I don't fully understand the UML diagram you presented, except that like Arborint said, "it's neat"...

This is strictly a class diagram correct or does it also reflect your file structure, etc???

Cheers :)

Posted: Wed Apr 26, 2006 11:50 pm
by Christopher
jeffery wrote:thanks, I will see how I can implement the singleton pattern.
I would temper the use of Singletons. I have found that in the long run they cause more trouble than they help because they are still a global.
jeffery wrote:I think the reason I have DB class inheriting from Session class was so that I could make the session class a singleton pattern and also because Sessions are stored in the database. I may have the possiblity of the Database class having multiple instances across the application to do multiple connections.
It seems like if the sessions are stored in the database then you would pass a DB object to the Session object when you instansiate it. Besides, if the session is stored in a database then it really doesn't matter how many instances of the Session there are anyway.

Posted: Thu Apr 27, 2006 12:29 am
by alex.barylski
1) Use of singletons: A singleton, incase you are unaware...is a class which restricts instantiation of a class to one instance (sometimes more), therefore, if you ever instantiate the object twice, it by definition will return the first instance back to you - or unconventionally crap all over you :P

In saying this, you should be sure you really need a singleton...as again like Arborint said it is fundamentally a global (although IMHO globals aren't bad by themselves, they are only as bad as the programmers who use them) but also a poor design choice if not really what you need.

2) Passing a database object by reference via function parameter would likely be an excellent choice...as Arborint has suggested...

This way your module is not dependant on the database class...well...it is and it isn't...

- Your session class is dependant on a database class existing, cuz if you call any functions in your session class whch use that object and it's not defined, your application will choke - obviously...

- But at the module level - not implementation level, your code is still solid as it doesn't depend on anything from the outside world, which is always ideal, especially in OOP solutions.

Code modularity should always be a priority when coding - if you can anyways :)