Sounds like you're on the right track.
Regarding your sample approach below, I'd have to say that this depends on
how you want to code it, and what the requirements of your application are.
You could have one event object that contains an array/collection of time
slots and venues, or you can have an array/collection that has a single
event which in turn has a single timeslot and venue.
When I think about an event, I don't think of it having multiple times - I
think about each time being a separate event, and the schedule is a
collection of individual events. However, that's me. This sort of thing is
the type that will spawn many different opinions, all of them correct in one
way or another. The bottom line is how YOU think about an event, and what
the application requires of the event object. The rest is just a different
approach to implementation.
>From the OO perspective, you have objects and collections. Collections are
in fact objects, but sometimes it's easier to think of them as being a
little different. A collection is used whereever you can have more than
one. i.e. An event can have many timeslots, so the event object would have
a collection to hold the timeslots (normally a plain array will do the
trick, but this really depends on your coding language).
Your application sounds to me like your object approach should be something
like this:
Schedule Object (Collection of timeslots)
- Timeslot object
- Event Object
- Venue Object
- List Events By Time method
- List Venues by event method
- List Times for event method
- Add Event method (i.e. Schedule.AddEvent(object Timeslot, object Event,
object Venue) )
- Remove Event method (i.e. Schedule.RemoveEvent(object Timeslot, object
Event) )
etc.
Try not to duplicate your data if you don't need to. Having an array of
event objects in your timeslot AND venue objects would be a management pain.
Probably simpler to either allow duplicate timeslot objects for the same
time period, or go with a collection of events that can have a timeslot
property. Another option is to create different objects depending on how
you are looking at the data - If I'm looking at things from an events point
of view, then an events collection with the event object having time and
venue properties makes sense. If I'm looking at things from a venue
perspective, then a venue object with a time collection, and each time
having an event object makes sense. However, this last option may take much
longer to implement.
When I made reference to "query your data", the actual location of the data
doesn't matter - if it's in memory, then your functions/methods will be
written to use the memory, if it's in a database, the functions/methods will
be written to use the database. That's the nice thing about OO - you don't
really care how a function works, just how to call it (it's interface), and
what it returns. This buys you a great deal of flexibility. For instance,
you mentioned you are working with memory based data. If down the road you
needed to put your data into a database, you change the corresponding
functions, but not change their interface (when you can), and no other
changes should be needed. The display routines likely would never need to
be touched.
Are you developing this in CFMX? If so, you can't do a FULL implementation
of OO principles yet (it'd be nice if MX natively supported raising events
between objects), but you can get real close now. If you are developing in
something else, like VB.Net, you have other options open to you for how your
objects work. (different error handling routines, raising events, handling
events, etc.)
Once you get thinking in OO terms (and this IS a shift in thinking from
procedural languages), life will get easier, and you will have other options
available to you. Like converting your CFMX objects into web services.
(yes, I know you can do this sort of thing with procedural languages too,
but I find it's much easier to understand if you understand OO principles).
So, the bottom line is to look at your application in an OO manner, and
decide which object model makes the most sense for you. I can't tell you
this, but hopefully I've helped you understand things enough to be able to
make the choice.
HTH.
Shawn
-----Original Message-----
From: Jim Davis [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 3:34 PM
To: CF-Talk
Subject: RE: OO modeling Hell
I'm getting it I think... one point is that an event can have many times
and venues. Physically you might have this:
Donald Knack, "The Junkman"
12pm-1pm - Hynes Convention Center
2pm-3pm - Hynes Convention Center
4pm-5pm - Hynes Convention Center
7pm-10pm - Boston Common Bandstand
12am-12:10am- Boston Common Frogpond
In the above example there is one "Event", 5 "TimeSlots" and 3 "Venues".
The "Event" object should link to multiple timeslot/venue pairs.
My initial idea was to have a "Performances" (or perhaps "Showings")
property in "Event" that was a two dimensional array of TimeSlot/Venue
references.
Sound good?
> When you look at a venue object, it doesn't really have a direct
> correlation
> to a specific event, or time, so will not have properties for these
> elements. Same with a Timeslot object - there is no real direct
> correlation
> between a venue and an event, so no properties for these here either.
> Yes,
> a timeslot can be associated with a venue and/or an event, but the
> timeslot
> iteself doesn't really care.
Sort of... but one of the major aspects of the system is getting all
events at a venue or by time. So, depending on the work being done at
any time the "primary" object may be Venue, TimeSlot or Event.
This was the idea behind having an array of Event references within
"Venue" and "TimeSlot".
No good?
> So, I'd make a generic timeslot object (with start time, end time, and
any
> needed methods), a generic venue object (with location and any needed
> methods), and then an event object with properites for the event
details
> including timeslot and venue.
>
> When it comes to listing items by timeslots or venues, this would be a
> specialized query of your data. Perhaps the Timeslot object could
have a
Are you saying the object data (the event objects) or the database
directly? In the procedural model I would definitely query a table -
but I'm trying to get away from implementation dependencies in the
running application.
> method "PrintSchedule" that will do whatever is needed to create a
> schedule,
> but scheduling is a time related function so logically should be with
the
> Timeslot object. On the other hand, a Venue might also have a
> "PrintSchedule" method that would list only the events for that
particular
> venue. The implementation details are, of course, best left to you.
But
> post some possibilities here in hopes it might help you determine
where
> things should go.
>
> I should make a disclaimer though - I don't know the specific details
of
> your requirements, so my examples might be completely off...
If it would help the actual system I'm converting is here:
http://www.firstnight.org/Content/NewYears/Artists/Index.cfm
This is the eighth year I've done the site so I've got a very strong
handle on the business requirements but also some very ingrained
procedural concepts for building it. ;^)
The current system works well, but lacks some features (for example
currently there is a one-to-one relationship between Venue and Event so
and example like the one above can't be constructed without
duplication).
Thanks for your time and patience.
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137628
Archives: http://www.houseoffusion.com/lists.cfm?link=t:4
Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Get the mailserver that powers this list at
http://www.coolfusion.com
