Hello all..
I'm developing a ticket sales system and would like to do it using OOP.
I, as a programmer, have trouble keeping all my code in order and I think that this approch will help me tremendously. I'm looking for some experienced OOP develpers to help me with the design phase.
I have done some planning and have figured out that i'll need the following objects (feel free to recommend that I add or remove any if you see fit)
1. Venue (i.e. where the events will take place)
2. Event (i.e. The event to which the tickets will be sold)
3. Section (i.e. These sections are used to divide the venue for pricing purposes)
4. Ticket (i.e. one row per ticket. contains the location of the ticket in the venue as well as what event it is for)
There will be others but these are the ones i'm concerned about right now..
my question:
How will these related to each other? I've had some training and leaned that Inheritance is determined by using the "is a" phrase.. and none of the objects above "are" any of the others..
How do I express that Events have tickets and sections? and that sections have tickets.. Venues will have events..or.. events will have venues.. either way i suppose..
How would you approach this?
TIA!
Will
Questions about potential objects in my project
Moderator: General Moderators
-
waskelton4
- Forum Contributor
- Posts: 132
- Joined: Mon Sep 09, 2002 6:42 pm
I'd recommend reading Harry Fuecks's "PHP Anthology" for a good introduction to object oriented programming.
Also, this post will give you some deeper understanding of OOP.
Also, this post will give you some deeper understanding of OOP.
How about something like:
Code: Select all
class BoxOffice
{
function BoxOffice($venue_id, $event_id, $section_id, $user_id)
{
}
/*
return (bool)
*/
function hasSeat()
{
// db query
}
function save()
{
// db transaction
}
}
$box_office =& new BoxOffice($venue_id, $event_id, $section_id, $user_id);
if($box_office->hasSeat()) {
$box_office->save();
}
Last edited by McGruff on Sat Aug 06, 2005 6:26 pm, edited 1 time in total.
Re: Questions about potential objects in my project
Hi...
What you have here is a data centric design. You have worked out the essential data, as you would for a database, but have no idea how it moves around the system.
Imagine trying to understand a building by thinking about the bits that move around: stationary, people, chairs, various documents and deliveries. You might eventually do it, but it would be a long task. And you would be constantly asking a question like "How will these related to each other?"
Let's take a step back. What pieces of code are the most important? If you look around a typical application you will see various function (and class) declarations, plenty of glue code as arrays are emptied and refilled, some control structures and somewhere tucked away almost from view, code that actually does stuff. It's difficult to spot, but it's usually where a decision was made, something was calculated or a method was called thet actually kicked off some kind of process. This is the important stuff and should drive your application.
The problem is that you only recognise this stuff once you are working with the application. However, there is an easy starting point. Stuff is done by people, but when they do tey are acting under a role. You want to look for roles. Here are my candidate roles so far (that will become classes)...
No really, that's it. It's then pretty obvious that I want to book something, so I add a book() method. McGruff has already done this subconciously I suspect. The planning phase in OO is actually pretty easy, which gets me on to...
Secret number two:
Don't design ahead. OO gives you encapsulation. This means that you can hide stuff. If it's hidden, you can change your mind. This is the real benefit of OO, it allows you to change your mind. That is unless you change an interface (a method name or parameters). If you do that you have to edit the code that uses it. OO is not a panacea.
Now if OO gives you freedom to change your mind, why are you so eager to fix the design. Keep the initial design minimal. Then code some and see what happens. Now, once you have code, you can start to put in the design. Yes I know it sounds paradoxical, but it actually works like that. OO code is fluid once you get the hang of it. An example of this comes out of...
Secret number 3:
Don't plan on using inheritance. If one class inherits from another, they are tightly coupled. This is the opposite of encapsulation. You change one and you have changed the other automatically. You didn't even have a say in it. Instead pass objects around and have one call methods on another. The class passed in (or created on the spot) is a helper forthe client class. The booker clas will probably need lot's of helpers, such as Transaction, PaymentGateway, TicketRepository, Authenticator and so on. I don't know which yet, so I am holding off for now.
The exception is when you get very similar types. It is easy to fool yourself over this, so you wait for the code to tell you (yes it speaks to you, you just have to tune your ears). If you see repeated code in two classes, classes that are used interchangeably and have identical method signatres, then create a superclass and move the common code into the superclass. This is the only, repeat only, time you should introduce inheritance. Otherwise think, "I want this job done, what type of role would help me".
So that is what I would do differently. Just bring in the data as you need it. You often find you won't need it at all, and your whole problem gets simpler. Don't worry if you have lot's of small objects either, that's a good thing. In fact don't worry generally, as that's "analysis paralysis"
.
yours, Marcus
Secret number one:waskelton4 wrote:1. Venue (i.e. where the events will take place)
2. Event (i.e. The event to which the tickets will be sold)
3. Section (i.e. These sections are used to divide the venue for pricing purposes)
4. Ticket (i.e. one row per ticket. contains the location of the ticket in the venue as well as what event it is for)
...
How would you approach this?
What you have here is a data centric design. You have worked out the essential data, as you would for a database, but have no idea how it moves around the system.
Imagine trying to understand a building by thinking about the bits that move around: stationary, people, chairs, various documents and deliveries. You might eventually do it, but it would be a long task. And you would be constantly asking a question like "How will these related to each other?"
Let's take a step back. What pieces of code are the most important? If you look around a typical application you will see various function (and class) declarations, plenty of glue code as arrays are emptied and refilled, some control structures and somewhere tucked away almost from view, code that actually does stuff. It's difficult to spot, but it's usually where a decision was made, something was calculated or a method was called thet actually kicked off some kind of process. This is the important stuff and should drive your application.
The problem is that you only recognise this stuff once you are working with the application. However, there is an easy starting point. Stuff is done by people, but when they do tey are acting under a role. You want to look for roles. Here are my candidate roles so far (that will become classes)...
Code: Select all
class Booker { }Secret number two:
Don't design ahead. OO gives you encapsulation. This means that you can hide stuff. If it's hidden, you can change your mind. This is the real benefit of OO, it allows you to change your mind. That is unless you change an interface (a method name or parameters). If you do that you have to edit the code that uses it. OO is not a panacea.
Now if OO gives you freedom to change your mind, why are you so eager to fix the design. Keep the initial design minimal. Then code some and see what happens. Now, once you have code, you can start to put in the design. Yes I know it sounds paradoxical, but it actually works like that. OO code is fluid once you get the hang of it. An example of this comes out of...
Secret number 3:
Don't plan on using inheritance. If one class inherits from another, they are tightly coupled. This is the opposite of encapsulation. You change one and you have changed the other automatically. You didn't even have a say in it. Instead pass objects around and have one call methods on another. The class passed in (or created on the spot) is a helper forthe client class. The booker clas will probably need lot's of helpers, such as Transaction, PaymentGateway, TicketRepository, Authenticator and so on. I don't know which yet, so I am holding off for now.
The exception is when you get very similar types. It is easy to fool yourself over this, so you wait for the code to tell you (yes it speaks to you, you just have to tune your ears). If you see repeated code in two classes, classes that are used interchangeably and have identical method signatres, then create a superclass and move the common code into the superclass. This is the only, repeat only, time you should introduce inheritance. Otherwise think, "I want this job done, what type of role would help me".
So that is what I would do differently. Just bring in the data as you need it. You often find you won't need it at all, and your whole problem gets simpler. Don't worry if you have lot's of small objects either, that's a good thing. In fact don't worry generally, as that's "analysis paralysis"
yours, Marcus
-
waskelton4
- Forum Contributor
- Posts: 132
- Joined: Mon Sep 09, 2002 6:42 pm
Re: Questions about potential objects in my project
Well.. mostly true. I think I know how the data moves around.. I'm just not sure how to approach it. (but I think you answered that below)lastcraft wrote:Secret number one:
What you have here is a data centric design. You have worked out the essential data, as you would for a database, but have no idea how it moves around the system.
My model will be setup like so..lastcraft wrote:Let's take a step back. What pieces of code are the most important? If you look around a typical application you will see various function (and class) declarations, plenty of glue code as arrays are emptied and refilled, some control structures and somewhere tucked away almost from view, code that actually does stuff. It's difficult to spot, but it's usually where a decision was made, something was calculated or a method was called thet actually kicked off some kind of process. This is the important stuff and should drive your application.
visual layer pages = forms and tables that display data and allow the ability to edit or delete it via form submissions or links.
decision layer pages = the pages that the forms will submit to or the links will reference. These pages will hold all of the object methods that will change or add data to the DB.
process layer classes = the classes (that will probably be held in multiple pages) that will perform all of the queries on the data to add/change/delete the data. Will also hold classes to return data for display.
Ok.. so I guess it's clear that i'm probably more of a DBA than a programmer. But this is a HUGE piece of advice that clears things up for me substantially.lastcraft wrote:The problem is that you only recognise this stuff once you are working with the application. However, there is an easy starting point. Stuff is done by people, but when they do tey are acting under a role. You want to look for roles. Here are my candidate roles so far (that will become classes)...
Huh?? Why not...lastcraft wrote:Secret number two:
Don't design ahead.
Ahhh.. I see.lastcraft wrote: OO gives you encapsulation. This means that you can hide stuff. If it's hidden, you can change your mind. This is the real benefit of OO, it allows you to change your mind. That is unless you change an interface (a method name or parameters). If you do that you have to edit the code that uses it. OO is not a panacea.
I'm actually pleased to hear that I don't have to design the ENTIRE project to its finish. I'm not a very organized programmer and use a very sloppy prototyping system most of the time.
Two of the helpers would be McGruff's methods.. right?lastcraft wrote:Secret number 3:
Don't plan on using inheritance. If one class inherits from another, they are tightly coupled. This is the opposite of encapsulation. You change one and you have changed the other automatically. You didn't even have a say in it. Instead pass objects around and have one call methods on another. The class passed in (or created on the spot) is a helper forthe client class. The booker class will probably need lot's of helpers, such as Transaction, PaymentGateway, TicketRepository, Authenticator and so on. I don't know which yet, so I am holding off for now.
After reading your post and McGruff's I'm thinking that the classes that I mentioned in my original post will be used to perform single actions for their respective objects and that the booker or boxoffice class will be used to coordinate those actions. Sound appropriate?
Can't think of an example right off but I think I see where this would come into play..lastcraft wrote:The exception is when you get very similar types. It is easy to fool yourself over this, so you wait for the code to tell you (yes it speaks to you, you just have to tune your ears). If you see repeated code in two classes, classes that are used interchangeably and have identical method signatres, then create a superclass and move the common code into the superclass. This is the only, repeat only, time you should introduce inheritance. Otherwise think, "I want this job done, what type of role would help me".
Thank you so much for that explanation.. I think the part about focusing on encapsulation and using inheritance minimally will help me out TONS.lastcraft wrote:So that is what I would do differently. Just bring in the data as you need it. You often find you won't need it at all, and your whole problem gets simpler. Don't worry if you have lot's of small objects either, that's a good thing. In fact don't worry generally, as that's "analysis paralysis".
yours, Marcus
How does my model look? It makes sense to me .. does it seem like it will work?
Thanks Again !!
Will