• 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

Definition of Services in Java

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All,
I'm not a beginning java developer, but I've noticed that different authors use different terms for the same thing in java when it comes to the OOP concepts. Anyway, I haven't found a simple explanation of what a service is that an object offers to it's clients? I've read that it's the contract that defines what services are offered and the implementation that defines how these services are provided, so methods don't seem to be services as they are part of the implementation.

Anyone want to shed some light on this?

Thanks,
James
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suppose any public method could be considered a service to some client object. You might mentally narrow it down to those methods you document and invite other objects to call because there are obscure situations where a method has to be public even though you don't want just anybody to call it.

You can use an interface to define a contract and then implement the contract with one or more concrete classes. This is a fine practice, but not something you have to do 100% of the time. Another choice is to define the contract with an abstract class and extend it with one or more concrete classes. Again, a nice technique but not mandatory.

Even if you just have a single concrete class with some public methods you can call it a "service contract" because it's nice to promise not to change methods that others are using.

I wouldn't say there are firm rules for using words like service and contract. A given class might provide services to some and act as client to services of others, so it's just a role that it plays for a moment.

Hope that helps! I'm always tickled when people ask questions like this. It's fun to get turned on to all the mysteries of OO. It can keep you interested and learning for a long time!
 
James Drinkard
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, that helps! Thanks for the information. I wasn't trying to split hairs, but I realized I didn't have a full grasp of the concept. I just found a definition, not sure if it's the best one: A service is a contractually defined behavior that can be implemented and provided by any component for use by any component, based solely on the contract.

If found that you can use something by having knowledge of it, but not really understand it. If you can explain it to someone else, then that constitutes understanding.
 
reply
    Bookmark Topic Watch Topic
  • New Topic