1. Should add references to parents instead of duplicating values
(for example Site.owner_id and Site.owner_session should be a
reference to the instantiated objects, not the values
themselves
2. The values stored in the session should not be directly accessed
by the objects (it would be the equivalent of using global
variables) - instead, the GameSession object should instantiate
the objects with the values it retrieves from the session, so
that the objects never need to access the session variables.
3. Should pass objects and not row ids as arguments. For example,
User.set_homebase() should receive a Site object as an argument,
not the id of the site, which should remain internal information
of the corresponding Site() object.
[vlad] done
4. Same thing with some of the properties, like Site.owner_id - it
should be a Site.owner property pointing to a User object. When
you don't want to instantiate some of the attributes until they
are accessed, you can have a look at overloading
http://php.net/manual/en/language.oop5.overloading.php or even
setup real properties capabilities on a BasObjecte that all
classes would inherit
http://www.php.net/manual/en/language.oop5.properties.php#98267
5. The Leaderboard probably belongs more as a child of the
GameSession than of the User - it forces you to pass the User
object as an argument every time, but the Leaderboard is not
specific to each user - it's the position in the leaderboard
which is specific to each user
6. Not sure how you intend to use the User.get_*() and User.set_*()
methods - my guess is that those methods are used to retrieve
and store the relevant data in the DB, right? The thing is that
those values are already stored on the object, so for example
you don't need to pass the avg_pr value as an argument to
User.set_avg_pr() - this method can retrieve it from the object
itself. Renaming the methods as User.push_*() and User.pull*()
(to respectively store the value from the object on the DB, and
update the object value from the DB).
for DB interaction i use the insert and update functions
7. User.total_sites, User.avg_pr, User.longest_chain and
User.longest_chain_tag belong to the SitesCollection rather than
directly from User - they describe the user's collection of
sites rather than directly the user.
8. The User.get_site_collection() method is redundant: it's already
a property of the object, instantiated by the constructor.
9. User.hack_last_refill, User.hack_last_refill, Site.last_check,
etc. should be DateTime objects rather than strings, it will be
easier to manipulate afterwards
10. User.login() and User.logout() belong to GameSession more than
User - both these actions change the user and will thus require
to instantiate a new User object - which will have to be done
from the GameSession object. You probably will need the
register() method to be on the User() object though - the User
itself would not change, it would just be updated and switch
from an anonymous status to a registered status, and values like
User.email or User.password would be updated.
[vlad] done; also moved the is_logged_in fnction to the game session class
11. Missing description and relationship for the PlayerStats and
TagList classes
12. Should probably remove the notion of tree (Site.tree_id) and
rework the tables accordingly.
13. The Site.__construct() method should not use numerical id when
it's instantiated by the GameSession - it should receive the
information always accessible from the request, to avoid having
Site logic outside of the Site class, just to get the id. When
the user navigates to a new site, what you get from the request
is the new site URL, not the site_id. You should instantiate the
current site with a URL then - it's then up to the contructor to
find the relevant row in the table.
[vlad] done
14. I think you should have an ActionProcessor class, instantiated
by the GameSession, that knows of all possible type of actions
that can be performed within the game and will call the relevant
method on the right object depending on the action. The
GameSession would then be responsible for instantiating the
environment, and the ActionProcessor for modifying this
environment according to the action the user is performing. It
will allow to better isolate responsibilities, and will also
make it easier to log actions, since the ActionProcessor could
then automatically call the ActionLogger with the right
attributes, independently of the action.
uml_schema_2010.10.10.pdf
Description: Adobe PDF document
_______________________________________________ Farsides mailing list - [email protected] Wiki: http://farsides.com/ List: http://farsides.com/ml/ Forum: http://farsides.com/forum/ Ideas: http://farsides.com/ideas/ Chat: http://farsides.com/chat/
