alright, some basics please. (PHP and classes)

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

alright, some basics please. (PHP and classes)

Postby BotoBoto » Mon Oct 18, 2010 4:13 pm UTC

Alright let me give you whats up: I am unsure wether or not i have to give 'points' a seperate class.

I have a user system and the user has points, the user also buys stuff like 'name change' with those points.

It is a property of 'user' but still i am unsure :S

pearm
Posts: 1
Joined: Thu Oct 14, 2010 5:39 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby pearm » Mon Oct 18, 2010 4:25 pm UTC

If there are many things you can buy using these points then maybe a class is warranted?

In my experience (which is not very much) a class shouldn't have more than one purpose. Spending points seems
like a reasonable purpose.

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Mon Oct 18, 2010 4:54 pm UTC

Pa-lease help.

User avatar
bocochoco
Posts: 317
Joined: Thu Aug 06, 2009 8:22 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby bocochoco » Mon Oct 18, 2010 5:43 pm UTC

It does not need its own class. Just make it a variable of the user class.
Image

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Mon Oct 18, 2010 8:57 pm UTC

Ah, and i use methods to change the value of the points (it is of course also a database value.) Could i maybe send you my class so you could check the methods? not the code itself, but the usage of methods and all that..

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: alright, some basics please. (PHP and classes)

Postby Jplus » Mon Oct 18, 2010 11:12 pm UTC

Maybe you should first just try whether your code works, and if it doesn't, make it work. OO design is not something you should want to do in the very best way at your first attempt.

Whatever you do, it will be a good exercise in using classes anyway.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Tue Oct 19, 2010 10:53 am UTC

well that's just the thing: i have been using OOP for a while now, however i wish to check whether i have been implemnting it correctly. In my view my class will get like 50+ methods. Is that even normal?

Sambo
Posts: 4
Joined: Tue Oct 19, 2010 12:53 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby Sambo » Tue Oct 19, 2010 1:08 pm UTC

From my understanding of classes, each individual class should perform a single function. Assuming I understand your needs correctly the following is what I would use myself, although it is written in a Java-like language so you will have to seek help elsewhere to convert it into PHP.

Code: Select all

class User {
    public void purchase(Buyable item) {
        item.buy(this);
        this.points -= item.getCost();
    }

    public void nameChange() {
        //...
    }

Code: Select all

class Buyable {
    public void buy(User user);
    public int getCost();
}

Code: Select all

class NameChange implements Buyable {
    public void buy(User user) {
        user.nameChange();
    }

    public int getCost() {
        return 10;
    }
Last edited by Sambo on Wed Oct 20, 2010 4:44 pm UTC, edited 1 time in total.

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Tue Oct 19, 2010 2:19 pm UTC

I'm not even using a class to use my store.. I keep writing new files and new functions to do this.

User avatar
Steax
SecondTalon's Goon Squad
Posts: 3038
Joined: Sat Jan 12, 2008 12:18 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby Steax » Tue Oct 19, 2010 2:49 pm UTC

How about showing us the layout of your code? As in, what classes you have, what variables, what methods, and what classes inherit from it?

(Just the major variables, ones you have just for technical reasons can be omitted.)
In Minecraft, I use the username Rirez.

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: alright, some basics please. (PHP and classes)

Postby Jplus » Tue Oct 19, 2010 2:52 pm UTC

BotoBoto wrote:well that's just the thing: i have been using OOP for a while now, however i wish to check whether i have been implemnting it correctly. In my view my class will get like 50+ methods. Is that even normal?

I see. No, if your class has more than 10 methods, that's often an indication that you gave too many responsibilities to that class (but of course, this is only a rule of thumb; some well-designed classes may have 15 methods while some classes with 5 methods might already seem bloated).
50 methods seems insane to me. Sometimes you see classes with that many methods in standards libraries, but those are usually not meant to be truly OO (like C++' std::string, which is more of a very versatile, encapsulated datastructure), or they are heavily over-engineered.
Maybe you have missed opportunities for making abstractions and reusing code? The less methods, the easier to maintain (which is probably a reason you were asking in the first place).

Just before posting: Sambo's code makes sense. "Each individual class should perform a single function" is really too narrow of a definition and also a bit misleading, though. Some key ideas behind OO design are the following*:
  • Inheritance: if some class is a special case of some other class, it can copy its default behaviour from that class and will then only need to specify the differences.
  • Data abstraction: means as much as "reflecting the human way of thinking". You can ask from everything what is its type and always get an answer. For example, some variable that you declared might be of type "Chair", which on itself is of type "Furniture". This relation is also reflected in the program code through inheritance.
  • Information hiding: user of a class need not know about the implementation, i.e. how the data are privately saved or how member methods are implemented. A user need only know what it can expect from a method, not how it is doing it (this is however a good idea in any programming paradigm).
  • Encapsulation: data and behaviour that are related are bundled.
    <-- Sambo illustrated this nicely in the code above.
  • Dynamic binding: if using inheritance, objects of subclasses can be treated as if they were of the parent class, and if they override a method of the parent class that will be resolved at runtime.
    <-- Like in Buyable.
  • Polymorphism: (follows from dynamic binding:) a class may have several subclasses which the user would not need to (nor want to) distinguish in order to be able to use them. For example, someone could make an array of Shapes and .rotate() each of them, without needing to know whether they're actually Circles, Squares, Triangles or even some mix of those.
  • Composition: classes can keep instances of other classes as member data for storing pieces of their information or for defining parts of their behaviour. This is especially a good idea when there are multiple ways to implement some behaviour or when multiple classes need to store part of their data in the same way.
  • Delegation: classes don't implement their methods entirely on their own but accept helper objects (usually as method arguments) to get things done which are essentially the same but which may still vary in different circumstances. A good example is seen in classes in C++ that can be printed in text format. Printing can be done to the command line or to a file (or to a GUI widget). Still, C++ classes offer only one method for printing to text, which takes an argument of type std::ostream. The ostream object may be a handle to the command line, or it may actually be of derived type std::ofstream, i.e. a handle to a file. Or it may be some entirely different derived class from std::ostream.
  • Double dispatch: an object may pass itself as an argument to a method of another object that it invokes, as a special case of delegation.
    <-- Sambo was delegating the effect of buying an item to the item itself.

Does this help?

*) derived partly from Danny Kalev and partly from the Gang of Four.

Edit: added example of delegation that was apparently lost in the original post.
Last edited by Jplus on Tue Oct 19, 2010 3:46 pm UTC, edited 1 time in total.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Tue Oct 19, 2010 3:30 pm UTC

Steax:

Code: Select all

<?php
/*
This is the user class, it acts as a starter of the session, and also everything around it.
it first checks if the user is logged in, by checking the session variable

*/
class User
{
    var $lang = array();
    public $level;
    public $name;
    var $timezone;
    var $dst;
    function __construct()
    {
        global $db;
            $user_data = $db->sql_fetchrow($result);   
            $this->level         = $user_data['user_level'];
            $this->logged_in    = 1;
            $this->username        = $user_data['username'];
            $this->id            = $user_data['user_id'];
            $this->ip            = $_SERVER['REMOTE_ADDR'];
            $this->points        = $user_data['user_points'];
            $this->is_admin        = ($this->level == 3 ? 1 : 0);
            $this->timezone        = $user_data['user_tz'];
            $this->last_comment    = $user_data['user_lastcomment'];
            $this->avatar_ext    = $user_data['user_avatar_ext'];
            $this->gender        = $user_data['user_gender'];

    function format_date($gmepoch, $format = false, $forcedate = false)
    function login($username, $password)
    function post_comment($comment, $author, $game_id)
    function give_points($amount)
    function take_points($amount)

}
?>


Please do remember this is old code, i have only just started working on it again ;)

Oh and Jplus, some things are jibberish to me, and some do actually make sense. Thank you. Dynamic binding is quite strange for me.. :S

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: alright, some basics please. (PHP and classes)

Postby Jplus » Tue Oct 19, 2010 4:10 pm UTC

To truly grasp OO design you'll have to understand all of the concepts that I named, and probably more. That's partly a matter of applying them and partly of reading about them. You could start by googling "dynamic binding", "object-oriented programming" and "design patterns".

To become truly proficient in OO design takes a lot of learning and patience, but the good news is that it is very rewarding when you feel the "click". Understanding the paradigm really makes you a better programmer and enables you to tackle many problems in a more elegant way.
On the other hand, you should always remember that OOP is not The One And Only True Way To Do It. Understanding other paradigms such as generic programming and functional programming is just as enriching and just as valuable. In practice, problems often turn out to have their own specific best approach, which might for example be a mix of generic and functional programming. (I think your particular project fits well to an OO approach though, so don't worry.)

As for your code, I still wonder whether you've actually made it work yet (or at least the part of it that you've started to define). Whether you want to improve your OO skills or not, making things work should really always be your first priority, since designs can always be changed, and probably always will change. A common pitfall (even among professional programmers) is to keep lingering in the design phase without actually implementing anything, just because better ways to design the software keep coming to the surface.
So when you start a project, of course you should think about your design first before starting to write your code, but not too long. And as soon as you have started to write class definitions you should also commit yourself to implementing the methods.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
Steax
SecondTalon's Goon Squad
Posts: 3038
Joined: Sat Jan 12, 2008 12:18 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby Steax » Tue Oct 19, 2010 5:24 pm UTC

Your code looks okay in general, just a few alarm bells going off:
- User::format_date() probably shouldn't go under the User object. I usually have a "System" object containing app-specific stuff like that, or it works as a standalone function.
- If you're going to declare stuff public, declare the others private (that is, don't use vars and publics). It's really just a little nitpick from me. Similarly, declare the same for your functions (they're likely public so far).

I generally also move the stuff like User::logged_in to a Session object.

Your code will certainly expand rapidly. You could, however, move stuff about. As Jplus said, you could do with a full-scale design of the structure before moving on. For example, User::post_comment() could go into a Forum object.
In Minecraft, I use the username Rirez.

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Tue Oct 19, 2010 5:52 pm UTC

Steax wrote:Your code looks okay in general, just a few alarm bells going off:
- User::format_date() probably shouldn't go under the User object. I usually have a "System" object containing app-specific stuff like that, or it works as a standalone function.
- If you're going to declare stuff public, declare the others private (that is, don't use vars and publics). It's really just a little nitpick from me. Similarly, declare the same for your functions (they're likely public so far).

I generally also move the stuff like User::logged_in to a Session object.

Your code will certainly expand rapidly. You could, however, move stuff about. As Jplus said, you could do with a full-scale design of the structure before moving on. For example, User::post_comment() could go into a Forum object.



thing is, the format_date is specific per user, and the user input HOW he wants the date to be formateed (e.g. day/month/year v.s. month/day/year war) and the post_comment works on a variety of things, news posts, media posts, and later on maybe forum post.

Jplus wrote:To truly grasp OO design (...) should think about your design first before starting to write your code, but not too long. And as soon as you have started to write class definitions you should also commit yourself to implementing the methods.


I have started implementing this all, but i have ommitted all the code within the methods.

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: alright, some basics please. (PHP and classes)

Postby Jplus » Tue Oct 19, 2010 11:07 pm UTC

BotoBoto wrote:
Steax wrote:Your code looks okay in general, just a few alarm bells going off:
- User::format_date() probably shouldn't go under the User object. I usually have a "System" object containing app-specific stuff like that, or it works as a standalone function.
- If you're going to declare stuff public, declare the others private (that is, don't use vars and publics). It's really just a little nitpick from me. Similarly, declare the same for your functions (they're likely public so far).

I generally also move the stuff like User::logged_in to a Session object.

Your code will certainly expand rapidly. You could, however, move stuff about. As Jplus said, you could do with a full-scale design of the structure before moving on. For example, User::post_comment() could go into a Forum object.


thing is, the format_date is specific per user, and the user input HOW he wants the date to be formateed (e.g. day/month/year v.s. month/day/year war) and the post_comment works on a variety of things, news posts, media posts, and later on maybe forum post.

Here's one possible other way to do it: give the User class a .userID() accessor which returns the database ID of the User. When you invoke the formatting entity (the System class with a method or just some global function), e.g. for a date in a post, just pass the entire User object as an argument (by reference). The formatter then extracts the ID from the User, retrieves the User's settings from the database, and formats the date accordingly.

It may seem long-winded, but in this way you can easily adapt the formatting entity to add or change possible settings, without ever needing to adjust the User class for it. Also, you avoid needlessly copying the setting from the database to the User object -- which would result in heavier objects.
(Generally, that something varies per object still doesn't necessarily mean that it should be stored in the object, although the class should probably provide a way to determine what are the specifics of the object.)

It might actually be a fun and interesting exercise to try to think of as many alternative ways to do this as possible. :)
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Thu Oct 21, 2010 7:21 am UTC

Jplus wrote:
BotoBoto wrote:
Steax wrote:Your code looks okay in general, just a few alarm bells going off:
- User::format_date() probably shouldn't go under the User object. I usually have a "System" object containing app-specific stuff like that, or it works as a standalone function.
- If you're going to declare stuff public, declare the others private (that is, don't use vars and publics). It's really just a little nitpick from me. Similarly, declare the same for your functions (they're likely public so far).

I generally also move the stuff like User::logged_in to a Session object.

Your code will certainly expand rapidly. You could, however, move stuff about. As Jplus said, you could do with a full-scale design of the structure before moving on. For example, User::post_comment() could go into a Forum object.


thing is, the format_date is specific per user, and the user input HOW he wants the date to be formateed (e.g. day/month/year v.s. month/day/year war) and the post_comment works on a variety of things, news posts, media posts, and later on maybe forum post.

Here's one possible other way to do it: give the User class a .userID() accessor which returns the database ID of the User. When you invoke the formatting entity (the System class with a method or just some global function), e.g. for a date in a post, just pass the entire User object as an argument (by reference). The formatter then extracts the ID from the User, retrieves the User's settings from the database, and formats the date accordingly.

It may seem long-winded, but in this way you can easily adapt the formatting entity to add or change possible settings, without ever needing to adjust the User class for it. Also, you avoid needlessly copying the setting from the database to the User object -- which would result in heavier objects.
(Generally, that something varies per object still doesn't necessarily mean that it should be stored in the object, although the class should probably provide a way to determine what are the specifics of the object.)

It might actually be a fun and interesting exercise to try to think of as many alternative ways to do this as possible. :)


isnt that a bit like you say long-winded? I mean the format is only evoked when it is needed on the page.

User avatar
Steax
SecondTalon's Goon Squad
Posts: 3038
Joined: Sat Jan 12, 2008 12:18 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby Steax » Thu Oct 21, 2010 8:09 am UTC

This is on a tangent, but I'd like to give a little friendly reminder. Are you absolutely sure you need that date formatting function? People have their preferences, naturally, but pretty much anyone can adapt to any commonly-used format. If you drop it into a preferences page or whatever, I can assure you that less than 10% of your users will even change it. When you're working on application design, make sure you only add what's necessary. It's easy to go overboard on configuration options and whatnot, when in the end people rarely ever even use it.
In Minecraft, I use the username Rirez.

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Thu Oct 21, 2010 11:36 am UTC

Steax wrote:This is on a tangent, but I'd like to give a little friendly reminder. Are you absolutely sure you need that date formatting function? People have their preferences, naturally, but pretty much anyone can adapt to any commonly-used format. If you drop it into a preferences page or whatever, I can assure you that less than 10% of your users will even change it. When you're working on application design, make sure you only add what's necessary. It's easy to go overboard on configuration options and whatnot, when in the end people rarely ever even use it.


Well actually I for one do NOT like the month/day/year notation americans have. It messes with my brain and most americans probably hate the day/month/year notation everybody in the world uses. So yes. I do believe some configuration is necessary, not on a preferences page but probably at registration.

User avatar
Steax
SecondTalon's Goon Squad
Posts: 3038
Joined: Sat Jan 12, 2008 12:18 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby Steax » Thu Oct 21, 2010 12:15 pm UTC

BotoBoto wrote:Well actually I for one do NOT like the month/day/year notation americans have. It messes with my brain and most americans probably hate the day/month/year notation everybody in the world uses. So yes. I do believe some configuration is necessary, not on a preferences page but probably at registration.


That's even worse, usability-wise. Keep your registration page as minimal possible. Every next preference you give is another point where people could, instead, choose to close their browser tab. You could also use a format like 21 Oct 2010 which is neutral either way. Of course, if you really need the option, you could implement it, but it shouldn't trouble you too much.

Alternatively, if you have a format_date function somewhere, you can use a sensible default now and later on implement that option when you're done with your critical features. I usually prune down my web apps to the few that will actually be used commonly, make them, and when I get feedback it's usually nowhere close to what I had planned. Those pruned features are usually forgotten. It's funny how effective web app design actually makes things easier to develop...

Or, if you really need to ask your users of their location, you can infer from that. Or, if you feel like making it really slick, you can also try auto-detecting their location based on their IP address.
In Minecraft, I use the username Rirez.

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Thu Oct 21, 2010 12:33 pm UTC

I really like your feedback! Write a book or something. I am going to make my registration page as minimal as possible, I too have closed a browser because i felt like the registration itself would take 15+ minutes. Any feedback on my site in my signature? I'd love to hear it. Apart from the registration which ill probably fix today.

User avatar
Steax
SecondTalon's Goon Squad
Posts: 3038
Joined: Sat Jan 12, 2008 12:18 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby Steax » Thu Oct 21, 2010 1:07 pm UTC

Glad to help, I'm a UI/UX designer by profession so I guess I'm doing something right. I did some browsing around your site, nothing too big grabs my attention; a few things though. I would suggest vote up/down for media, youtube already experimented with this. Also, you have breadcrumbs that don't act as expected; take "Index > Media > Pictures > [name]". The Pictures text isn't a link; how do I see more pictures? Then, clicking Media takes me to login. This totally doesn't fit my mental model, how could I see a page but not it's parent?

Finally, in your error text (just making a mention so you don't miss this), you say stuff like "You did not fill in a email address". It's usually more friendly to not blame your users, but blame yourself with a clear explanation. For example, filling in a non-email formatted address still says "you did not fill in", which would irritate people who just don't know that an email has to have the .com at the end. You might already have this up your pipeline for your registration fix, though, so feel free to disregard it if you change the model.

That aside, this is a bit far from OOPish, so you might want to toss out any other queries of your objects while we're at it, too.
In Minecraft, I use the username Rirez.

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Thu Oct 21, 2010 1:34 pm UTC

Steax wrote:Glad to help, I'm a UI/UX designer by profession so I guess I'm doing something right. I did some browsing around your site, nothing too big grabs my attention; a few things though. I would suggest vote up/down for media, youtube already experimented with this. Also, you have breadcrumbs that don't act as expected; take "Index > Media > Pictures > [name]". The Pictures text isn't a link; how do I see more pictures? Then, clicking Media takes me to login. This totally doesn't fit my mental model, how could I see a page but not it's parent?

Finally, in your error text (just making a mention so you don't miss this), you say stuff like "You did not fill in a email address". It's usually more friendly to not blame your users, but blame yourself with a clear explanation. For example, filling in a non-email formatted address still says "you did not fill in", which would irritate people who just don't know that an email has to have the .com at the end. You might already have this up your pipeline for your registration fix, though, so feel free to disregard it if you change the model.

That aside, this is a bit far from OOPish, so you might want to toss out any other queries of your objects while we're at it, too.


Gonna fix up what you mentioned in the first paragraph. And it does sound nicer to blame it on the server/website. But what do you mean with your last line?

Edit; oh and about the voting. I liked what I did actually. It is weighted so that people who have been with the site longer/had more comments/have more points are able to vote with more power. So:

guest: vote counts 1x (try it.)
just registered: vote counts 1* certain variable which coordinates with time spent on site (or something)
admin: vote counts 9001x (nah not really.)

User avatar
Steax
SecondTalon's Goon Squad
Posts: 3038
Joined: Sat Jan 12, 2008 12:18 pm UTC

Re: alright, some basics please. (PHP and classes)

Postby Steax » Thu Oct 21, 2010 1:57 pm UTC

I just meant that the topic is still on classes (object-oriented programming) so we might want to keep it on track (though then again this is your personal thread so there's nothing wrong with focusing on your needs, too!).

Weighed voting sounds good. As long as you're sure it's not vulnerable to user manipulation (and that voting itself is critical to the system).
In Minecraft, I use the username Rirez.

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Thu Oct 21, 2010 2:13 pm UTC

Steax wrote:I just meant that the topic is still on classes (object-oriented programming) so we might want to keep it on track (though then again this is your personal thread so there's nothing wrong with focusing on your needs, too!).

Weighed voting sounds good. As long as you're sure it's not vulnerable to user manipulation (and that voting itself is critical to the system).


Well, every voted is saved in the database with user id / IP(for guests) and if you created something, your own vote is worth 0, if that is what you mean.
It is crucial as voting differtiates good/bad (in the website visitors's opinion) pictures/videos/news bulletins. Also when voting it immediately shows what a difference you made, and also giving you points, awarding the visitor :)

Edit: btw I made a 'pictures' link http://www.funzors.com/media.php?mode=pictures

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: alright, some basics please. (PHP and classes)

Postby Jplus » Thu Oct 21, 2010 5:01 pm UTC

BotoBoto wrote:
Jplus wrote:Here's one possible other way to do it: give the User class a .userID() accessor which returns the database ID of the User. When you invoke the formatting entity (the System class with a method or just some global function), e.g. for a date in a post, just pass the entire User object as an argument (by reference). The formatter then extracts the ID from the User, retrieves the User's settings from the database, and formats the date accordingly.

It may seem long-winded, but in this way you can easily adapt the formatting entity to add or change possible settings, without ever needing to adjust the User class for it. Also, you avoid needlessly copying the setting from the database to the User object -- which would result in heavier objects.
(Generally, that something varies per object still doesn't necessarily mean that it should be stored in the object, although the class should probably provide a way to determine what are the specifics of the object.)

It might actually be a fun and interesting exercise to try to think of as many alternative ways to do this as possible. :)

isnt that a bit like you say long-winded? I mean the format is only evoked when it is needed on the page.

That the format is only evoked when it is needed on the page is actually another reason to not load and store the setting in the user object. See what I mean?

I didn't say "it may seem long-winded" because I thought it was long-winded, but because I expected you might get that impression. Personally, I find the alternative that I suggested more elegant than what you were doing. Still, I like to invite you to think of more ways to do it (even though you're maybe not going to store any formatting settings afterall).
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Thu Oct 21, 2010 5:08 pm UTC

You may be right, however I am not that familiar with OOP design, i now have a DB class and a user class and use them accordingly but I saw in some software (phpBB) that they also had a session class, which really seemd logical to me, but still couldnt really understand what was going on..

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: alright, some basics please. (PHP and classes)

Postby Jplus » Thu Oct 21, 2010 5:19 pm UTC

You don't have to defend yourself! Don't worry, it was not my goal to emphasize your "non-familiarity with OOP". I wasn't even necessarily sure that I was more right than you, I was just offering you another point of view and trying to estimate whether you got the message. :)

Whether you're familiar with OO design is actually totally irrelevant here, since what this thread was about was you getting more familiar with OO design! (Or, more directly, PHP and classes.) I was trying to help you a bit. All I meant to say was "Hey, there are more ways to do it! Just stay sharp!".
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Thu Oct 21, 2010 5:31 pm UTC

I know, im not dogmatically making my site, just when i make something you usually stick to it. Bad coding habbits may have been born in my code lol.. I mean when i try to search for a tutorial on PHP and OOP , you always get the bycicle example. But that does not help me one bit. I need a real live example of a user class being used. Its hard to find :P (a good one, and also well used.)

User avatar
Emu*
Posts: 689
Joined: Mon Apr 28, 2008 9:47 am UTC
Location: Cardiff, UK
Contact:

Re: alright, some basics please. (PHP and classes)

Postby Emu* » Thu Oct 21, 2010 11:08 pm UTC

phpBB is not a good example of php development. It has mutated over its many iterations.

Drupal is better as a development example.
Cosmologicon wrote:Emu* implemented a naive east-first strategy and ran it for an hour, producing results that rivaled many sophisticated strategies, visiting 614 cells. For this, Emu* is awarded Best Deterministic Algorithm!

User avatar
BotoBoto
Posts: 191
Joined: Mon Mar 09, 2009 9:31 pm UTC
Contact:

Re: alright, some basics please. (PHP and classes)

Postby BotoBoto » Thu Oct 21, 2010 11:19 pm UTC

I'll look into that thank you emu* ;)

User avatar
Emu*
Posts: 689
Joined: Mon Apr 28, 2008 9:47 am UTC
Location: Cardiff, UK
Contact:

Re: alright, some basics please. (PHP and classes)

Postby Emu* » Mon Oct 25, 2010 12:15 am UTC

BotoBoto wrote:I'll look into that thank you emu* ;)


Start here:
http://drupal.org/coding-standards
Cosmologicon wrote:Emu* implemented a naive east-first strategy and ran it for an hour, producing results that rivaled many sophisticated strategies, visiting 614 cells. For this, Emu* is awarded Best Deterministic Algorithm!


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 7 guests