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
Suggestions on my Project Design
Moderator: General Moderators
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
-
jeffery
- Forum Contributor
- Posts: 105
- Joined: Mon Apr 03, 2006 3:13 am
- Location: Melbourne, Australia
- Contact:
thanks, I will see how I can implement the singleton pattern.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?
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.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Whoa....it looks more like a network than a library of classes 
Your over complicating things...
There is no need to:
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)
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.
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:
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
Your over complicating things...
There is no need to:
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...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
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);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.
Authentication/Authorization/Sessions2) 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.
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';
}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
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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:thanks, I will see how I can implement the singleton pattern.
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.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.
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
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 
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
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