Help needed planning oo system

[TOA]

Hey guys, hoping you can help.

 

Currently, my boss is on a gamification kick, and wants me to make a game that goes into our site.

 

Basically, when you do things on the site, we give you points (represented by an image onscreen) which you can redeem in a number of ways for different things..

 

I thought it all out, and created a test db, which works well. I created some procedural code to try some things out and it looks like I have everything set up correctly.

 

I've thought up a list of all the classes I think I need, but am not sure the best way to go about this.

 

I've been trying to study up on patterns, but I just get more and more confused (that's another thread) so I don't really know what to do next. I'm also a bit unsure as to what to post to get things started, so if you need to see anything (like table structures, etc) just holler.

 

Any help is greatly appreciated

 

 

[TOA]

To clarify a bit more:

An instance of the game is associated to a user. A user gets points for doing company approved activities. A user has a total number of points (represented by different images for different point values) that they can redeem either buying company approved trinkets or donating to a charity for a dollar match.

 

So here's what I'm thinking:

When the page renders, I create a game object.

 

A game object holds: the user and company object, current season object, list of point objects, list of leaf objects, any user goal and trinket objects.

Game builder queries the db to pass info to points, leaves, trinkets, etc builders.

Builders create concrete instances of points, trinkets, leaves, etc. to be included in game.

Game builder takes all the pieces, combines them and returns an instance of a game.

 

So we have a structure like this:

Client Code

|

v

GameBuilder

|

v

Game Class

|

v

Point,Leaf,Trinket Builders

|

v

Point, Leaf, Trinket Classes

 

 

Does this even seem close? The more I try at this the more I'm confusing myself  :-\

 

Thanks for reading

[jawef]

Don’t be harsh to yourself. You said that the first thing you did were to create procedural code, so the key is not making that code OO but Object Oriented thinking from the scratch. This might take some time and some errors but don’t be anxious about it.

 

I have some ideas to your last post. I don’t want to confuse more, so read them just as ideas. You wrote “current season object,”  I don’t really understand that. Next, make your objects as close to your data model and verbal avoiding properties that are not

serializable like data connection objects or file pointers.

 

The main thing is to watch your data and see the universe that you created. Each entity in this universe has properties and behaviors so it just write down how those entities interact.

 

Hoped I helped a little …

 

[TOA]

Don’t be harsh to yourself. You said that the first thing you did were to create procedural code, so the key is not making that code OO but Object Oriented thinking from the scratch. This might take some time and some errors but don’t be anxious about it.

 

I have some ideas to your last post. I don’t want to confuse more, so read them just as ideas. You wrote “current season object,”  I don’t really understand that. Next, make your objects as close to your data model and verbal avoiding properties that are not

serializable like data connection objects or file pointers.

 

The main thing is to watch your data and see the universe that you created. Each entity in this universe has properties and behaviors so it just write down how those entities interact.

 

Hoped I helped a little …

 

 

Yes, I do know that oo is a different mindset Thanks for that though. It's always important. All I meant was to test the database and flow of information. I can see how that would draw that comment; if I could edit my post I would.

 

A season is more literal than you would think; our "game" is a tree - when you do stuff on the website you get points that are represented on the tree by leaves. 4 seasons in a year. Each person has a "tree". You can use those "leaves"/points to by stuff or donate to charities. Everything starts over every season.

 

In theory it's easy to just "write down the responsibilities". I'm finding it not so in real life.

 

I do have a solid understanding of oop basics. Classes and objects, inheritance and abstracts/interfaces, etc. And I've been doing alot of research on patterns, but it's not helping yet.

 

When I was in college, I took alot of db classes. First they taught you how to write queries and stuff, then they taught you db design, which is where everything in the first part finally made sense to me. I'm at that point in objects. I get patterns and stuff, just not when to use them, and how to recognize which one, and how to plan all this. I'm not learning this in any structured environment like I was then, so it's more of a find your own way kinda deal and I'm a little lost 

 

Thanks for your comments, everything helps.

[TOA]

As a side note, I'm trying to use Visio for UML modeling: is there a better one?

[TOA]

I had to step into another project, so this one got put to the side, but now I'm back on it. Still having issues.

 

I'm having a hard time descriping my classes and responsibilities. Alot of places say "look at the specifications; nouns are classes, verbs are methods" but this is easier said than done. Does someone have an example I could use as a reference?

 

Also, all my data is coming from a relational db, and I've heard that every entity should be a class. Is this an accurate statement?

 

Thanks much

[thehippy]

OO design is not something you can instantly adopt, its much more iterative process.  I started with simple encapsulation, separation of concerns and slowly integrating in and adopting design patterns, architectural design patterns and so on.

 

Since code will speak louder than words, have a look at the source of Phing and Zend Framework as an example good OO in PHP.  Phing is well put together and fairly compact while Zend Framework is complex and broad.  They both have their flaws to be sure, but are still good educational sources.

 

Also, all my data is coming from a relational db, and I've heard that every entity should be a class. Is this an accurate statement?

On a small scale this can be acceptable but on a larger scale is often impractical, so the answer is to find what will work for you and the application.

[TOA]

I started with simple encapsulation, separation of concerns and slowly integrating in and adopting design patterns, architectural design patterns and so on.

 

I'm trying to do the same thing. How did you learn to separate the concerns? Do you have any good tutorials you followed or anything? Was there a piece that finally made it click for you? I can't seem to find anything that more than off-handly brings up this topic in other tutorials. Most go right from basic stuff to patterns. And when they do touch on it, I understand it when I'm looking at it, but the connection to my own just isn't there.

 

I just need a "roadmap" of sorts if you know what I mean, for when I get lost in my code So I need to learn how to plan my classes and how they interact on that high level view.

 

Thanks for helping, I appreciate it