Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / March 2007

Tip: Looking for answers? Try searching our database.

Can Interfaces be mimicked with classes

Thread view: 
sundarvenkata - 28 Feb 2007 13:49 GMT
Can the functionality of interfaces be mimicked with classes?? If so
why would the language designers choose to include interfaces in the
language design when classes alone would have been sufficient

Thanks,
Sundar
Ingo R. Homann - 28 Feb 2007 14:17 GMT
Hi,

> Can the functionality of interfaces be mimicked with classes?? If so
> why would the language designers choose to include interfaces in the
> language design when classes alone would have been sufficient

You are right, that an abstract class can be a substitude for an
interface in some cases.

Note however, that interfaces allow multiple inheritance where classes
don't.

Ciao,
Ingo
Dimitri Kurashvili - 28 Feb 2007 14:19 GMT
> Can the functionality of interfaces be mimicked with classes??

No, can't.
You can not create class even with two "extended" parents, but you may
"implement" as many interfaces as you like.

> If so why would the language designers choose to include interfaces in the
> language design when classes alone would have been sufficient

Interfaces are something like drawing pencils and classes like
painting colors. Even Van Gogh used pencils ... and you say we should
not use interfaces!
Chris Dollin - 28 Feb 2007 14:33 GMT
I bet this is homework. Oh well, I've already written the reply.

> Can the functionality of interfaces be mimicked with classes??

Not in Java, no. The things you can't put in interfaces -- specifically,
instance variables -- mean that you can inherit, ie, implement,
multiple interfaces without having to solve some knotty efficiency
issues.

> If so
> why would the language designers choose to include interfaces in the
> language design when classes alone would have been sufficient

Premise false.

Signature

Chris "electric hedgehog" Dollin
"If there is a problem, you must confess it, Mr Chaplin."
Mr Carter, /The Beiderbeck Affair/

Tor Iver Wilhelmsen - 04 Mar 2007 13:13 GMT
På Wed, 28 Feb 2007 14:49:04 +0100, skrev sundarvenkata  
<sundarvenkata@gmail.com>:

> Can the functionality of interfaces be mimicked with classes??

Only parially, because the single class inheritance it shares with  
Smalltalk and C# (among others) means you can only inherit in one  
continous line. For the purposes of the type system, an interface is a  
class with only public abstract methods and public static fields. But the  
methods only have a signature, not any implementation you can delegate to  
so they avoid the "diamond" problem of multiple inheritance. So unlike  
classes that allow implementations, you can have many interfaces  
implemented by a class. (You still have a variant of the diamond problem  
if two interfaces use different semantics for the same method signature  
though.

> If so
> why would the language designers choose to include interfaces in the
> language design when classes alone would have been sufficient

Yes, it would be like adding byte, short, char and int when all can fit  
inside a long. :P


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.