• 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

relationship b/n classes and instances

 
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there a difference b/n the relationship b/n classes and the relationship b/n objects that are instances of those classes
Are there any resources where is i can more info on the same?
 
Ranch Hand
Posts: 1871
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Classes basically share a structural relationship which can be created using class diagrams. This is clearly specifed at compile time itself.
However Objects mostly share a behavioural relationship. This can be shown using the Object diagrams. Thus i can have two Objects who do not know each other at the compile time reference each other at runtime.

------------------
Regds.
Mahindrakar
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for that reply .What i wanna know how will this relationship difference have a say at the time of design does this aspect need a consideration at all or not?
 
author
Posts: 621
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are certainly design pattern issues, but I think you can boil it down to uninstantiated classes that offer static (i.e. utility functionality) methods or 'client' specific instances that contain unique data in every instance. In the design phase you won't have to specify how the class is used (really) except for qualifying the methods with static or not. I know this isn't much to go on but perhaps it will seed further discussion.
Sean
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic