Why are interface methods public?

I want to define a package interface that will be implemented only by package classes which will be used only by other package classes. Why do the methods have to be public?

In java you don't have multiple inheritance. To
circumvent that it is said to extend the most
important class and implement the others with
interfaces. No. Java does not support multiple inheritance. Interfaces do not exist to supply that functionality. Interfaces can be used to simulate some of the patterns that multiple inheritence represents.
(You can have skeleton implementations to
help you implement those interfaces in other
classes).
But the interface methods are public. So all the
classes you 'extend' via this trick have all methods
public.
This is a bad thing. All of you who have used RMI (or
J2EE) know that you can serialize objects between two
networked machines. ValueObjects pattern from J2EE
toolbox is a good example of this. Now, if you happen
to have several quite similar objects, you obviously
would like them to inherit those common traits from
some base class. If you would also like them to have
some other common functionality (for example server
side 'maintenance' methods, state monitoring, checking
and clearing, you would have to make those methods
public 'cos you only have interface implementation
left - after spending that single credit to actual
inheritance.No. Convienence ("common functionality") should not be used in most cases when designing hierarchies. Inheritence should only be used to represent 'is a' relationships.

Similar Messages

  • Interface (Methods Public ????)

    hello friends,
    In interface , Y are the methods default declared as public???? and Y cannot we declare them as friend or protected ?
    Can anybody tell me in details abt the same ????

    Declaring protected would be unusual too since only
    descendants can access protected methods and an
    interface cannot have descendants of course you mean only descendands and classes
    in the
    same package can access protected methods ... :)Well yes, though redundant for this argument since that is already covered by package-private access. The difference between the two access-levels, the descendants, is an empty set for interfaces.
    This should act a response to the previous post also - because it would make no sense to allow protected. I can see, and demonstrate, cases where package-private is of value however.
    Sun made the decision it seems without full consideration. They cannot now change that decision because of the implicit manner in which package-private is indicated to the compiler (by the absence of another access level). That's a problem since the compiler automatically infers 'public' access for methods in interfaces in cases where the grammar would normally indicate package-private. Changing this would break a massive amount of code.
    An option would be to introduce a new keyword 'friendly' or 'packageprivate' and keep the current rules for implied access. This would allow the new access without breaking much code. The only code to break would be that which uses the new keyword for another purpose.
    These collisions would be uncommon because:
    - The name of a type uses the convention of a leading uppercase first letter.
    - The name of a method uses the conventions for property accessors and
    mutators using the prefixes 'get', 'set', 'is' and 'has' or is a behaviour and
    more likely to use a verb.
    local variables and fields are the only likely collisions - these should be minimal and not used in exposed APIs.
    Talden

  • Why are static methods called with null references,valid ?

    This is my code :
    package inheritance;
    public class inh6{
         public static void method(){
         System.out.println("Called");
         public static void main(String[] args){
              inh6 t4 = null;
         t4.method();
    O/P :
    CalledHere t4 is a null reference and yet we are able to call a method on it,why is null pointerexception not thrown.Why are we able to call static methods using null references ?
    t4 is null means it doesnot refer to any memeory address,hence how is method() called correctly.
    I hope i am clear. :)
    Thank you for your consideration.

    punter wrote:
    jverd wrote:
    Memory addresses have nothing to do with it. I doubt memory addresses are even mentioned once in the JLS.
    By memory address i mean the memory location the reference is pointing to.I know what you mean. But if you think it's relevant, can you show me where in the JLS it says anything about memory locations?
    >
    You can do that because a) t4's type is "reference to inh6" and b) method() is declared static, which means that you don't need an object to call it, just the class. That class comes from the compile time type of t4. The fact that t4 is null at runtime is irrelevant.
    So at compile time the type of t4 is inh6 and hence the method is called.Is it ? Had method() not been static a NullPointerException would have been thrown.Correct.
    With non-static, non-private, non-final methods, which implementation of the method gets called is determined at runtime, buy the class of the object on which it's being called. If any one of those "non"s goes away, then the method is entirely determined at compile time, and in the case of static methods, there's no instance necessary to call the method in the first place.

  • Why are interfaces compiled ?

    My understanding of an interface until now is :
    It is a contract for classes which implement those.
    That means the "compiler" checks classes who declare
    the implementation of a particular interface :
    * that the methods of the appropriate interface are implemented and so on ....
    But why are those interfaces compiled into
    class files ? Do the have any function at runtime for
    the JVM ?
    Thanks for your comments.
    Regards,
    Oskar

    How else would u like java to find where your classes are stored? Java looks at the interface to quickly determine if a function exists...if it doesn't, exception.

  • Why are all methods virtual???

    class Base
         public Base()
              System.out.println("Calling f() from base class ...");
              f();
              return;
         public void f()
              System.out.println("Base class function called!");
              return;
    class Derived extends Base
         public Derived()
              System.out.println("Calling f() from derived class ...");
              f();
              return;
         public void f()
              System.out.println("Derived class function called!");
              return;
         public static void main(String args[])
              new Derived();
              return;
    }The problem in this: the call to f() from the Base class calls the Derived class method. I want it to call the Base class method. How do I do this?
    Ravi

    Sorry, I cant explain the circumstances under which I
    encountered this problem without explaining a whole
    lot about my product. But I cant make it a private
    method because I need to be able to call it from
    outside the package. I found a workaround for my
    problem by putting a call to super.f() in the derived
    class. But I really wonder why the makers of Java
    chose to make it this way!
    RaviIf you can't explain your problem then don't post your questions here. It's not like a small post on a forum board will cause your IP any damage.
    The design of OOP is that if you override a method in a subclass of an object, the reason for doing so is that you are add/changing functionality of that method. If you don't need to add/change functionality of a method then don't override it. Polymorphism ensures that no matter what type of object the compiler thinks you are reffering to, at runtime you will call the correct method of the type of object you encounter then. This is why interfaces work. calling the super class to complete processing of a method is not a hack, or a design problem it's the way to do it. If the class that you are extending changes private data structures in a method, and you override that method, unless you are doing a radical change to the class, you probably need to call the super method to ensure that the proper changes are made.

  • Why are emails in public folders being marked as read when viewed in the viewing pane when I have disabled this in settings

    I am using office 2010 on a windows 7 PC. In outlook I have changed the settings for the reading pane so that emails are not marked as read unless I actually open them. This is working for emails in my inbox and outbox but not for emails in public
    folders. Emails in public folders are marked as read as soon as I click on them. Do public folders have a different setting for marking email as read in the reading pane?
    It is important for me that emails in the public folders are not marked as read when i click on them as I need to read through hundreds of project emails in these folders and need to be able to distinguish between emails I have read and actioned
    and emails I have just clicked on while searching for an email I need. This folder serves as an archive for my emails so i cant delete them once I have read them. I also don't have permission to label them or create tasks from them. 

    Hi,
    I tested in my lab, it worked for public folders. My Outlook version is Outlook 2013.
    Please open Outlook in safe mode to check result.
    If possible, please check if this issue persists from a different client server.
    Best regards,
    Belinda Ma
    TechNet Community Support

  • Why are these protected- finalize() & clone()

    Why are the methods finalize() and clone() declared as protected in Object class when any class that we write extends java.lang.Object? I mean what design considerations made them being declared as protected?

    Object.clone() is protected so that it cannot be called unless the person writing the code intends it to be cloned.
    In other words to make a class cloneable one must over-ride Object.clone() with a public method that does the cloning. In this way the method can only be called if an implementation of the mehtod has been coded.
    Convinced this is poorly explained so reply if you don't get it!
    Cheers,

  • Why are these Webservices not supported in VC ?

    Hi all,
    I am using NW04s SP9, and I plan to make MDM-Application with VC.
    Therefore I introduced MDM-WebService into NW and defined it on VC.
    but "searchRecords" of "MDMSearchRecords" was displayed with "Not supported"
    in the right frame .
    Mmm...
    So I decided to think from a beginning.
    [http://www.27seconds.com/Holidays/US/USHolidayService.asmx?wsdl|http://www.27seconds.com/Holidays/US/USHolidayService.asmx?wsdl]
    I defined above it on VC and I used "Getholidaydate" .
    Good! .
    However,,, "Getholidaysforyear" was also "Not supported".
    Why are these methods "Not supported" ? .
    and how will come to be usable these methods in VC? .
    Thanx in advance.
    Regards,
    k.sugimoto.

    Hi
    Visual Composer supports Web services that are compliant with the Basic Profile 1 standard of the Web Services Interoperability (WS-I) Organization (http://help.sap.com/saphelp_nw70/helpdata/en/e0/92583ab4da4b9cb524f61ba4267d25/content.htm)
    Best regards
    Vincenzo

  • What is the significance of Marker interface? Why are we using, even though

    What is the significance of Marker interface? Why are we using, even though it has no method?

    Well, what's the significance of an interface? They can define a set of methods a class may implement but the class could equally well implement these methods without the interface so why having interfaces at all?
    The answer is that the most important aspect of an interface is that it constitutes a type (you can declare variables of it). And it's a type regardless of how many methods it defines, including none. So the reason for having a marker interface is that you're interested solely in the type aspect of interfaces.

  • Why not static methods in an Interface

    why can't i make static methods part of an Interface?
    for example:
    public interface Names {
        public static String[] getNames(); // <--- "static" not allowed in an Interface.
    }what i want to say is:
    every class that implements the Names interface must have a static method, getNames() , that returns a raw array of Strings.
    why won't jave let me do this with an Interface?
    Edited by: kogose on Feb 4, 2009 5:47 PM

    this is my current solution:
    public interface Symbols {
        public String[] getSymbols();
    public class ETF implements Symbols {
        public String[] getSymbols() {
            return(ETF.symbols);
        private static String[] symbols =    { "DIG", "UYM", ...... }
    public class INDEXES implements Symbols {
        public String[] getSymbols() { return(symbols); }
        private static String[] symbols = { "^DZC", "^UTIL", "^GWI", .... }
    public class NYSE implements Symbols {
        public String[] getSymbols() {
            return(NYSE.symbols);
        private static String[] symbols =  { "GDL", "GDI", .... }
    }then to get the data:
    analyzer.analyze((new ETF()).getSymbols());
    analyzer.analyze((new INDEXES()).getSymbols());
    analyzer.analyze((new NYSE()).getSymbols());
    this looks like a hack to me?
    its weird that i create an object just to invoke one method and get static data.....
    is there an elegant way?

  • Why all are interfaces in JDBC

    why all are interfaces in JDBC
    If anybody knows the answer tell me plz

    Because of encapsulation of major database functionality, such as running queries, processing results, and determining configuration information.
    JDBC interfaces is like a plug, where u can plug in any database to your application by adding there respective JDBC Driver.
    The JDBC Driver is a set of classes that implement the JDBC interfaces to process JDBC calls and return result sets to a Java application. Thats the magic of encapsulation, we just have to program to the interface rather than the implementation. The implementation might change regularly keeping the interface unchanged and hence our application.
    The one of the suggestion of design patterns, is , program to an inteface and not to an implementation.

  • Why are there 2 methods to create thread ?

    Hi,
    To create threads, there are two methods
    1) Inherit the THREAD super-class
    2) Implement the interface RUNNABLE.
    The reason for providing two methods is that, the user can only one level of "implementation inheritance". That is the reason, which comes immediately to mind. But is there another reason(s)? If yes, than what is the reason??
    Any help would be welcome
    Thanks in advance

    I was one of those authors. We all read some other
    author who said the same dumb thing LOL, been there, done that, you have my sympathy :-)
    Could you explain your use of the words "policy" and
    "mechanism"? I completely agree with your conclusion,
    but don't really understand your argument.This is one of the things that I've taken from my experiences with the X Window System (tm, I think). "Mechanism, not policy" was one of the mantras that would be repeated by every author. As I understood it, the idea was that the X protocol, Xlib, and even Xt prescribed the mechanism for a program's interaction with windows on a client screen, but did not prescribe how those windows would interact with the user. That was the "policy" to be implemented by the toolkit and application layers (thus the different appearance of Motif, OpenLook, Xaw, &c, even though they used the same underlying code up through the toolkit).
    I like the mantra, and as I've come to understand OO programming, I try to apply it as a way to identify what could/should be abstracted and what needs to remain concrete. If something abstracts a basic service that can be used in multiple ways -- like threads -- I consider that mechanism. If something is closely tied to the way my application works, I consider that policy. The former are implemented with interfaces and abstract classes, and do not contain application-specific code; the latter are implemented with instantiable classes.

  • Why all the methods in interface should be implemented

    why all the methods in interface should be implemented

    Because you'll break the contract saying "this instance features all methods defined in that interface" otherwise.
    In other words, as long as an interface isn't completely implemented by an instance, it's not validly implemented at all.

  • Why are JDBC related classes Interfaces???

    Why are the JDBC related classes java.sql.CallableStatement
    java.sql.Connection
    java.sql.PreparedStatement
    java.sql.ResultSet
    java.sql.Statement Interfaces??? Where are the implementations of these interfaces found??? What are the pros and cons involved in doing so???
    thx in advance!!!

    Are these classes Interfaces from the very first release of Java specifications??? I'm quite doubtful
    about this.You're also quite wrong.
    They've been interfaces from the very beginning. If they hadn't been, there's no way JDBC drivers could plug & play as nicely as they do.
    This is the beauty of all interfaces, by the way. It's a design worth emulating in your own work.
    If not, in what release have they been made into Interfaces???Why are you so concerned?

  • Access specifiers for interface methods

    When we implement the interface ,we have to specify the implementing method access specifier to be "PUBLIC" ,but not "PROTECTED" or "PRIVATE".
    Compiler is giving an error -- attempting to assign weaker access privileges ,when we specify protected.
    what is the internal reason for this?Why we shouldnt make the access weaker in the implementing class.
    Can any one help me on this.Your help is highly appreciated.

    When we implement the interface ,we have to specify
    the implementing method access specifier to be
    "PUBLIC" ,but not "PROTECTED" or "PRIVATE".
    Compiler is giving an error -- attempting to assign
    weaker access privileges ,when we specify protected.
    what is the internal reason for this?There is absolutely no point in having a private interface method. The interface represents a visible abstraction and private methods are never visible so it is a contradiction in terms.
    An interface is intended to represent an abstraction that a user (software) uses. Protected via child/parent represents a usage that is restricted to a child from a parent. The child can already see the parent so there is no point in having an abstraction for the child. And it would probably be unwise to limit a child by such an abstraction.
    Protected via the package and interfaces is more contentious as to why it is not allowed. There are those that argue that this should be allowed so that a package can use interfaces but restrict them to the package. To me this seems like a minor point given that most interfaces will probably represent an abstraction to other packages and not within a single package. This applies specifically to default access as well.

Maybe you are looking for