• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

An OO question which I can't think of any easy way to summarize

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Guys.

A slightly long winded question here: Please bear with me while I explain it as well as I can.

I have two conceptual things (I hesitate to call them classes yet..): Job and Activity. An activity might be "Send an sms" or "forward an sms to email" or something - it tracks what the job has done (and has to do). I also want to record that a Job has, say, sent 100 SMS messages or whatever. The job needs to have a number of activities associated with it.

From a DB perspective, this is pretty straightforward. One table for the job, one for the Activity (to hold the name field), and a linking table to facilitate the one-to-many relationship. The mapping table also holds the number of occurrences of that activity for that job - so, if a job had sent 100 messages it would be stored here.

My question is: Should I have two classes - Job and Activity, and have a field in the Activity class to hold number - or should I have three classes - Job, Activity and ActivityType - so that I can distinguish between the idea of the activity, and individual instances of that activity? It's almost like the relationship between class and object.

Any thoughts anyone?
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think your reasoning for how to split up the tables in the database is fine, if you want to start from the data representation. However, I think you may be missing some important considerations if you want to drive this solution from the conceptual O-O model.

The most important aspect of a problem that needs to be considered when designing an O-O model is behaviour. I notice that you haven't really mentioned any behaviour in your description, above. Your description of your "things" is solely in terms of what information they must keep, rather than what they are responsible for doing. Following this train of thought: losing the distinction between responsibility for having and the responsibility for doing often leads to the nagging feeling that O-O modelling is a sham, and a waste of time.

So, let's try a slightly different approach.

Forget about your Job and Activity for the moment. Consider the whole of the subsystem you are building. What different things will it need to do? Can you think of ways of splitting these do responsibilities so that each group has a single clear role?

If this is still baffling, please feel free to give us a few examples of the things your software will be called to do, and I'm sure we will have a go at partitioning them into class/object responsibilities for you.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alister Pate:

From a DB perspective, this is pretty straightforward. One table for the job, one for the Activity (to hold the name field), and a linking table to facilitate the one-to-many relationship.

Actually, from a database perspective, this is not generally the right way to handle a one to many relationship. What one should do is omit the linking table, but instead have each row in the Activity table refer to the key in the Job table. Linking tables are only needed for many to many relationships, and not one to many relationships.
 
Alister Pate
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the input guys.

I'll think about it in terms of responsibilities - you are right - I do tend to make things purely passive information blocks. This is probably the result of too early an introduction to J2EE with its session beans and entity beans! So I tend to write verb-classes which do things (like session beans) and noun-classes which hold data (like entity beans) and don't have much behaviour. I'm deliberately modeling it in a J2EE sort of way so that if I need to port it to an EJB server it won't be too much of a conceptual leap.

I'll have a think about this.

Perhaps I need to go back to basics here and rethink the entire system. It's probably a bit late for this project, but for next time, maybe.

Warren, the relationship I am modelling is that a Job can have a number of different activities associated with it - so, for instance, a job might have 100 sms-send-activities - so one table for job, one for activity (to capture the idea of an "sms-send-activity"), and a table to capture the relationship, including the idea of "100-ness", if you see what I mean. You're right of course, it is a many-to-many relationship. Each activity can relate to a number of jobs - and each job might have a number of activities. Sorry, I was being a bit dense.
 
reply
    Bookmark Topic Watch Topic
  • New Topic