• 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

"program to interface" principle

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings to everyone. This is my first posting here, and I hope the experience will be good with feedback from responsive peers.

I am on the SCJA track, currently studying all the suggested materials. What I find perplexing to explain is the notion of the "program to interface" principle, which is required for the exam. Is there a formal definition or a good example that you could share with me so I can understand this idea once and for all? Thanks in advance.
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is probably the most 'abstract' term on the exam objectives...well, besides all the references to the keyword abstract.

Essentially, the exam wants you to be able to recognize that when defining method parameters, a method return type, or for that matter, an instance variable, it is always preferable to use the most general object possible that provides the required functionality. Since there is nothing more general than an interface, an interface is always preferable.

Here's a snippet from the SCJA Certification Guide:

When developing code, it�s important to make your code as flexible as possible. One way to make your code incredibly flexible and pluggable is to define instance variables and method parameters using the least specific, or most general, type of object you could imagine.

If you define method parameters that take a very general interface or abstract class as an argument, other developers have the flexibility to pass into your method any class that functionally implements the requirements of that interface or abstract class.

The same thing goes for instance variables as well. Defining instance variables at a very general level, and then allowing those instance variables to be initialized with more specific, concrete objects at runtime, makes your code, and your applications, much more flexible.

When defining instance variables, or figuring out what types of objects to pass as arguments to a method, always chose the most generic type you can, so long as that generic object provides the functionality your application requires.



-Cameron McKenzie
[ January 19, 2007: Message edited by: Cameron W. McKenzie ]
 
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to JavaRanch!

Maybe an example would help.

Suppose you have a class called Veterinarian. An instance of Veterinarian will most likely do things with animals. In other words, it will probably have methods that take different kinds of animals as parameters. One way to do this is to overload each method for each kind of animal...

void examine(Cat c) {...}
void examine(Dog d) {...}
void examine(Ferret f) {...}
//etc.

But as you can see, this will require a different method for each kind of animal. And whenever a new type of animal is introduced, the Veterinarian class will need to be modified.

An alternative approach is to define an interface called Animal, that all types of animals would implement. Then a Cat IS-AN Animal, a Dog IS-AN Animal, and so on. Now, all the Veterinarian class needs is one version of each method...

void examine(Animal a) {...}

Not only does this eliminate the need for multiple overloaded versions, but it also means that the Veterinarian class does not need any modifications when new types of Animals are introduced.

Note that this is closely tied to another important principle: Polymorphism. If we have an Animal a, and we call a.makeSound(); this will invoke the method body of the Animal's true runtime type. For example, if a is really a Cat, it will invoke the Cat's makeSound implementation. On the other hand, if a is a Dog, then calling a.makeSound() will invoke the Dog's makeSound implementation.
[ January 20, 2007: Message edited by: marc weber ]
 
We don't have time to be charming! Quick, read this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic