using interfaces


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 9 of 9

Thread: using interfaces

  1. #1
    Join Date
    Jan 2006
    Location
    Lourdes, Lubao, Pampanga, Philippines
    Posts
    36

    Unhappy using interfaces

    can anyone explain this code:

    public abstract interface Pet {

    // method(s)
    public abstract void setName(String newName) ;
    public abstract String getName();

    } // close Pet interface

    what are the effects when I use such code?...
    Does it effect a class the implements this interface?...
    Does it effect an abstract class the implements this interface?...
    I can't understand why you need to make an interface abstract and make it's methods abstract...

  2. #2
    Join Date
    May 2005
    Location
    Ontario, Canada
    Posts
    173

    I'm trying to teach myself first!

    It is a very famous question.
    ABSTRACT is a modifier.
    The abstract class modifier describes a class that has abstract methods.
    Abstract methods are declared with the abstract keyword and are empty which means (they have no block defining a body of code for this method)
    A class that has nothing but abstract methods and no instance variables is more properly called an interface.
    What is the Interface and why do we need it?
    The main structural element in Java that enforces an API is the interface.
    An interface is a collection of method declarations with no data and no bodies.
    The methods of an interface are always empty they are simply method signature.
    Why do we need interface?
    In order for two objects to interact, they need to know about the various messages that each will accept.
    To enforce this “knowledge” the object-oriented design paradigm asks that classes specify the application programming interface (API) or simply interface that their objects present to other objects.

  3. #3
    Join Date
    Nov 2004
    Location
    Norway
    Posts
    1,560
    Using "abstract" here is just a noiseword. It has no effect. The classes that implement this interface have to define the methods in the interface, - so the specificarion: "abstract interface" is "butter on fat" as we say over here.
    eschew obfuscation

  4. #4
    Join Date
    May 2005
    Location
    Ontario, Canada
    Posts
    173
    Quote Originally Posted by sjalle
    Using "abstract" here is just a noiseword. It has no effect. The classes that implement this interface have to define the methods in the interface, - so the specificarion: "abstract interface" is "butter on fat" as we say over here.
    If so,
    I would like to see a real good implemetation.
    Thank you in advance.

  5. #5
    Join Date
    Dec 2004
    Location
    San Bernardino County, California
    Posts
    1,468
    Here's an example from a SudokuSolver program with different approaches to solving the initial board (an example of a "Strategy" Pattern implementation). The classes which implement the Solver class are "Solvers" - they can be referred to as a "Solver" - and they are also their own classes.

    First, the interface - which exposes to the caller the methods that all classes which implement the interface will perform - so the caller doesn't worry about HOW the implementing class does it, and only has to worry about what data it needs to feed (argument) and what it's going to get back ...

    Code:
    public interface Solver
    {
        public void initializeSolution( Board initialBoard );
        public Board generateSolution( Board initialBoard );
        public int getSteps();
    }

    Now, the first of the classes which implements the Solver interface ...

    Code:
    public class Backtracker implements Solver
    {
        private int steps = 0;
    
        /** Creates a new instance of Backtracker */
        public Backtracker()
        {
        }
        public void initializeSolution( Board initialBoard )
        {
            
        }
    	/** implements primary method of the Solver interface
    	  *
    	  *  recursive, brute force, naive implementation of backtracking, using
    	  *  a "tried" bitset to track which candidate values have been tried in
    	  *  generating possible solutions. No evaluation of other values in
    	  *  unassigned cells of board; only checking is to determine whether
    	  *  the candidate value would violate the constraints for the cell
    	  */
        public Board generateSolution( Board initialBoard )
        {
            Board solution = (Board)initialBoard.clone();
            Board failure = null;
            Board newSolution = null;
    
            BitSet tried = new BitSet(9);
    ...
    
    	/** implementation of interface method to report number of boards generated
    	  *  to solve problem
    	  */
        public int getSteps()
        {
            return steps;
        }
    And a second class ...

    Code:
    public class BTMRV implements Solver
    {
        private int steps = 0;
    	private	Stack<Board> myOldBoardsStack = new Stack<Board>();
        
        /** Creates a new instance of BTMRV */
        public BTMRV()
        {
            MRV.initializeChoices();
            MRV.initializePossibles();
        }
    
        public void initializeSolution( Board initialBoard )
        {
            MRV.setAssignedCells( initialBoard );
            MRV.setValues( initialBoard );
        }
        
        public Board generateSolution( Board initialBoard)
        {
            Board failure = null;
            Board newSolution = null;
    
            Board solution = (Board)initialBoard.clone();
            Cell focus = (Cell)solution.nextCell();
    
            int testValue;
    
            // increase the count of the steps - the generation of a new node
            // in the search tree
            this.steps++;
    
            if( solution.isComplete() )
            {
                return solution;
            }
            
            while( MRV.possibles[focus.getRow()][focus.getCol()].cardinality() == 9 )
            {
                 solution = myOldBoardsStack.pop();
                 focus = solution.nextCell();
                 MRV.resetStacks();
            }
    ...
    
    	/** implementation of interface method to report number of boards generated
    	  *  to solve problem
    	  */
        public int getSteps()
        {
            return steps;
        }
    Same call by the calling class - don't have to know different methods based on the different implementation
    Same result (hopefully) no matter what the implementation, because a Board or an int or a solution is being returned no matter what class is providing the functionality.

    The GUI classes are full of Interfaces, as are the Collection classes. [So this is a VERY IMPORTANT concept]
    Last edited by nspils; 04-14-2007 at 12:03 PM.

  6. #6
    Join Date
    May 2005
    Location
    Ontario, Canada
    Posts
    173
    Thank you
    Where is the class board?
    Last edited by Kinda Electroni; 04-14-2007 at 01:40 PM.

  7. #7
    Join Date
    Dec 2004
    Location
    San Bernardino County, California
    Posts
    1,468
    "Board" is another class that holds the structures of the Sudoku grid ("rows", "columns" and "boxes")

  8. #8
    Join Date
    Jan 2006
    Location
    Lourdes, Lubao, Pampanga, Philippines
    Posts
    36

    Smile thank you everyone

    so the abstract keyword in the interface does nothing...
    thank for the information...

  9. #9
    Join Date
    Nov 2004
    Location
    Norway
    Posts
    1,560

    Why ?

    Quote Originally Posted by Kinda Electroni
    If so,
    I would like to see a real good implemetation.
    Thank you in advance.
    I wont rule out the possibility that something may have slipped my attention, but I have never seen an abstract interface, and I cannot see what its purpose would be;

    I define an abstract interface and implement it in a class. I then have two choices:

    1: I can either make that class abstract and just declare the interface methods as abstract, bodyless methods,

    2: or make the class non-abstract and implements the methods.

    In the first case I would still have to extend the abstract class and implement the methods in order to use the class and in the second case the implemented methods are just a plain interface implementation regardless of the "abstractness" in the interface.

    What I'm trying to say is that I fail to see why one would use an abstract interface, it seems just as useless as "private final static...".

    PS: whether you use the "abstract" modifier or not for an interface definition doesn't matter, the compiler doesn't care....
    Last edited by sjalle; 04-15-2007 at 07:59 PM.
    eschew obfuscation

Similar Threads

  1. COM Interop and Multiple interfaces
    By .NetDoubts in forum .NET
    Replies: 0
    Last Post: 02-16-2007, 12:49 PM
  2. Interfaces Inheriting from Interfaces
    By Larry Hunter in forum .NET
    Replies: 1
    Last Post: 01-27-2003, 12:45 AM
  3. Object Browser and Interfaces
    By Michael Welch in forum .NET
    Replies: 1
    Last Post: 12-31-2001, 04:16 PM
  4. Re: Interfaces Question
    By Robert Cullen in forum Java
    Replies: 0
    Last Post: 10-23-2001, 08:34 AM
  5. Dealing with interfaces.
    By Richard Burton in forum .NET
    Replies: 5
    Last Post: 02-25-2001, 05:42 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center