Design patterns for User and Message System...

[Lord_Yggdrasill]

I was wondering though, what are your preferred design pattern for a User and Message System for your application? This is the structure I am considering, but I am not quite sure at this point:

1. User System:

   • abstract class User

     • class Member extends User

       • class AdminUser extends Member

       • class RegularUser extends Member

       • class BannedUser extends Member

     • class Guest extends User

Not sure what design pattern this is, its somewhat similar to abstract factory but has lots of differences Id say?

2. Message System:

   • interface Message

     • class SystemMessage implements Message

     • class PrivateMessage implements Message

     • class VisitorMessage implements Message

     • class Shoutboxmessage implements Message

     • class EmailMessage implements Message

Seems like a simple strategy design pattern to me?

So what would you do if you were the designer of a User and a Message System? What design patterns would you use? Id really like to collect ideas, suggestions and criticisms before getting started, thanks.

[NogDog]

I'm thinking maybe you could use the Decorator pattern for User to apply the other sub-types, layering them as needed.

[Lord_Yggdrasill]

Umm sounds like it will work too, I am not quite familiar with how decorator pattern works so would you mind giving me an example of how the user system may incorporate such a pattern? Theres no need to write a complete class with methods, just give me a general idea or a layout of interfaces/classes that would be nice. Thank you so much for this advice.

[NogDog]

I'll leave it to you to search the web for Decorator Pattern tutorials, but I could possibly see an abstract User class which is extended by a Member class and a UserDecorator class. That UserDecorator class would then be extended by an AdminUserDecorator class and a BannedUserDecorator class. Then if, for example, you need a banned user object, it would be instantiated as something like:

$user = new BannedUserDecorator(new Member());

If there could be such a thing as a banned admin user, it might be:

$user = new BannedUserDecorator(new AdminUserDecorator(new Member()));

[Lord_Yggdrasill]

I see, thanks for the example. And yeah, from the textbook I learned PHP it did appear that the decorator class would accept an argument of another object it was supposed to 'decorate'. You even proposed the idea of an adminuser being banned, this is so thoughtful of you.

[Derokorian]

I don't know if its something that will benefit you or not, but if you can use php 5.4 then traits are the way to go for horizontal development. I'm currently working on a project using 5.4 and traits and it has simplified my inheritance and improved my code usability greatly.

[Lord_Yggdrasill]

Well I've heard of PHP 5.4 and I personally like the new features such as trait and short-array syntax. The problem is that the software I am developing has lots of users and even developers using older version of PHP. Some were even using PHP 5.2.17, and for this reason we have yet to adopt namespace in our codes. Though about half a year from now we will force users to switch to webhosts that provide at least PHP 5.3.x.

But yeah, it wont hurt to get started. Trait will be huge in future PHP programming, its time to get ready for that.

[Derokorian]

Ah yeah this project I'm working on is an intranet solution, so I / the customer have complete control of the server, including versions of software, settings, etc. (to be specific I have physical access to the server, with full administrative privileges). However if this wasn't the case I wouldn't be using traits either, as even my own host doesn't support 5.4 yet. It does make things easier tho!

[Lord_Yggdrasill]

Well yeah, the customers/users of your software make a difference. I find it quite annoying how many freehosts and sharedhosts are still using PHP 5.2.17, they are just stubborn or lazy to upgrade. Or you can say they are cowards because they fear too much of script incompatibility after upgrading? Anyway eventually hosts using newer version of PHP will emerge with a cutting edge over the others who refuse to make the move, it is just about time when majority of webhosts switch to PHP 5.3 and even 5.4.

[bradgrafelman]

Lord Yggdrasill;11001311 wrote:

they are just stubborn or lazy to upgrade. Or you can say they are cowards because they fear too much of script incompatibility after upgrading?

Or you can say they're trying to be somewhat intelligent by fearing script incompatibility after upgrading. After all, shared web hosts don't thrive just because they enjoy upgrading software on their servers - it's their customers that foot the bill every month.

Upgrade too fast and break the websites of several of your customers and you might find yourself preaching to an empty room about how the latest-n-greatest has more features, is more secure, blah blah (meanwhile your paying customers have already ditched you - despite your good intentions - and taken their money elsewhere, leaving you with all of those upgrade costs and less customers to help pay for it).

Note I'm not an owner of any hosting company, nor am I trying to defend the ones that lag too far behind (PHP4, anyone?).

[Derokorian]

bradgrafelman;11001315 wrote:

Note I'm not an owner of any hosting company, nor am I trying to defend the ones that lag too far behind (PHP4, anyone?).

To go along with this: I was approached not to long ago about updating a site for someone. I inspected their server and decided to decline the job unless they were willing to change hosts (or have their hosts put them on a different shared solution with new software). Why would I decline a paying job? Well the host was running 4.2.# and TBH I didn't know if I knew how to develop a site that would work in 4.2 heh.

And yes breaking a customers script to upgrade is bad, that's why often time hosts providing shared solutions often dedicate new machines to new software, and continue to keep older customers on their old software unless requested otherwise!! I was able to get my employers on 5.3.9 instead of 5.1.4 just but submitting a ticket. This makes perfect sense tho, often times people don't care to know how the application works, so long as it continues to work.

[Lord_Yggdrasill]

I do understand the risk, but it is about time for the change. PHP 5.3.0 was released like almost three years ago, and to me about 2 years is long enough to make a move. If you are still using PHP below 5.3.0, you are so outdated. As far as I know, CPanel is compatible with PHP 5.3.x so there should not be excuses. Cant even imagine those still running PHP4, they aint getting new customers lmao.

Yeah updating your softwares and servers way too frequently does hurt too, I am not saying the webhosts should upgrade to PHP 5.4.0 already as it just came out a few months ago. But PHP 5.3.0? It is already not that new tbh...

[Bonesnap]

Lord Yggdrasill;11001299 wrote:

Some were even using PHP 5.2.17, and for this reason we have yet to adopt namespace in our codes.

My web server at home is still sitting at 5.2.9 🙁 I just haven't gotten around to upgrading it. Feels bad man.

[Lord_Yggdrasill]

Bonesnap;11001322 wrote:

My web server at home is still sitting at 5.2.9 🙁 I just haven't gotten around to upgrading it. Feels bad man.

Well I wont say so, it is your own web server at home so you are the only customer, you have full rights and reasons to decide what you want. If you just happen to enjoy PHP 5.2.x or earlier versions, I dont see it a problem. The issue with webhosts is that they need to compensate for requests of advanced customers wanting to switch to PHP 5.3.x, or even 5.4.0.

Anyway we've strayed a bit from the topic, havent we? XD

[Bonesnap]

Lord Yggdrasill;11001323 wrote:

If you just happen to enjoy PHP 5.2.x or earlier versions, I dont see it a problem.

Nah, I'm just lazy. 🙁

[Derokorian]

You're not lazy, you're trying to reproduce your production enviroment! 😉

[Lord_Yggdrasill]

Another thing I am thinking about is how to make objects like Member and Message interact each other. The fact is that the two classes aint independent from each other. A member can compose, write, reply or delete a message, while a message can respond to a member's command. Do you have any suggestions on which design pattern I should use to allow easy interaction among objects?

[NogDog]

Depending on the specific task in question (and perhaps as much on personal coding style preferences), you can either pass a Message object to a User object method as/when needed, or the User method can instantiate a message object when needed.

[Lord_Yggdrasill]

Thanks for the advice, I will look into this idea. The point is to have User and Message objects loosely coupled with each other, they are pretty much independent but can interact each other.

So this is the design pattern I come out with so far for the two systems:

User System: Abstract Factory pattern and Decorator Pattern

• Interface Creator

  • abstract class UserCreator implements Creator

    • class MemberCreator extends UserCreator

    • class GuestCreator extends UserCreator

    • class SpiderCreator extends UserCreator

  • abstract class User

    • class Member extends User

    • class Guest extends User

    • class Spider extends User

• interface Decorator

  • abstract class UserDecorator

    • class Admin extends UserDecorator

    • class Banned extends UserDecorator

    • class Friend extends UserDecorator

    • class Ignored extends UserDecorator

Looks quite complicated isnt it? Reality is that I do have a complicated script and database structure, so I dont see it a problem. The system works in a way that each user object(whether member, guest or spider) is created through its corresponding 'creator'. Decorators such as Admin, Banned and Friend can add(or remove as is in the case of 'banned') functionalities to these objects, which also extends from a UserDecorator class.

Anyway this is just a revised idea based on what I've been thinking about and what others have been suggesting in this thread. The message system looks much simpler than this one though, it uses the basic strategy pattern:

• interface Message

  • class SystemMessage implements Message

  • class PrivateMessage implements Message

  • class VisitorMessage implements Message

  • class ShoutboxMessage implements Message

  • class Email implements Message

What do you think? Is there a way I can make it better? I hope you dont get overwhelmed by this, I do tend to think about problems in a sophisticated way at times and sometimes its even inefficient.

[NogDog]

I believe that if you are implementing the Decorator Pattern, then abstract class UserDecorator should extend User.