-
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...
-
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.
-
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
-
 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.
-
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 11:03 AM.
-
Thank you
Where is the class board?
Last edited by Kinda Electroni; 04-14-2007 at 12:40 PM.
-
"Board" is another class that holds the structures of the Sudoku grid ("rows", "columns" and "boxes")
-
thank you everyone
so the abstract keyword in the interface does nothing...
thank for the information...
-
Why ?
 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 06:59 PM.
eschew obfuscation
Similar Threads
-
By .NetDoubts in forum .NET
Replies: 0
Last Post: 02-16-2007, 11:49 AM
-
By Larry Hunter in forum .NET
Replies: 1
Last Post: 01-26-2003, 11:45 PM
-
By Michael Welch in forum .NET
Replies: 1
Last Post: 12-31-2001, 03:16 PM
-
By Robert Cullen in forum Java
Replies: 0
Last Post: 10-23-2001, 07:34 AM
-
By Richard Burton in forum .NET
Replies: 5
Last Post: 02-25-2001, 04: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
Forum Rules
|
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL
|
Bookmarks