Doubt on abstract classes

Hi,
I have doubt in abstract classes,please clarify my doubt.....my doubt is
I have one abstract class,in that i have three methods...
Now I have created one subclass for that abstract class....
I defined all those methods that are there in abstract class in the sub class......and I wrote some other methods in that sub class....
Now my question is ----->can I make the methods that are declared in abstract class invisible to the people who are using the sub class???
Please tell me the answer...
Thanks in advance,
sirisha.

ya I got it....
Please see the code and tell me wether it is correct or not...
abstract class One
int i=10;
private void display()
System.out.println("One:display");
public void show()
System.out.println("One:show");
public abstract int intadd(int j);
class Two extends One
int i=100;
public void display()
super.display();
System.out.println("TestThr:display");
public void show()
//super.show();
System.out.println("TestThr:show");
public int intadd(int j)
if (j==1)
     return i;
     else
return super.i;
public class TestThr
public static void main(String args[])
Two t=new Two();
     t.display();
     t.show();
     System.out.println(t.intadd(1));
}

Similar Messages

Access overriden method of an abstract class

class Abstract
abstract void abstractMethod(); //Abstract Method
void get()
System.out.print("Hello");
class Subclass extends Abstract
void abstractMethod()
System.out.print("Abstract Method implementation");
void get()
System.out.print("Hiiii");
In the above code, i have an abstract class called "Abstract", which has an abstract method named "abstractMethod()" and another method called "get()".
Now, this class is extended by "Subclass", it provides implementation for "abstractMethod()", and also overrides the "get()" method.
Now my problem is that i want to access the "get()" method of "Abstract" class. Since it is an abstract class, i cant create an object of it directly, and if i create an object like this:
Abstract obj = new Subclass();
then, obj.get() will call the get() method of Subclass, but how do i call the get() method of Abstract class.
Thanks in advance

hey thanks a lot,, i have another doubt regarding Abstract classes.
i was just trying something, in the process, i noticed that i created an abstract class which does not have any abstract method, it gave no compilation errors. was wondering how come this is possible, and what purpose does it solve?

Abstract Class & Interface

Hi ,
I have a fundamental doubt regarding Abstract Class & Interface!!!
What is their real benefit...whether we implement an interface or extend an Abstract class we have to write the code for the abstract method in the concrete class.Then where the benefit remained....
And it is said that Abstract class provide default behaviour...what is the actual meaning of that?
Thanks & Regards
Santosh

In this section we will redesign our OneRowNim game to fit within a hierarchy of classes of two-player games. There are many games that characteristically involve two players: checkers, chess, tic-tac-toe, guessing games, and so forth. However, there are also many games that involve just one player: blackjack, solitaire, and others. There are also games that involve two or more players, such as many card games. Thus, our redesign of OneRowNim as part of a two-player game hierarchy will not be our last effort to design a hierarchy of game-playing classes. We will certainly redesign things as we learn new Java language constructs and as we try to extend our game library to other kinds of games.
This case study will illustrate how we can apply inheritance and polymorphism, as well as other object-oriented design principles. The justification for revising OneRowNim at this point is to make it easier to design and develop other two-player games. As we have seen, one characteristic of class hierarchies is that more general attributes and methods are defined in top-level classes. As one proceeds down the hierarchy, the methods and attributes become more specialized. Creating a subclass is a matter of specializing a given class.
8.6.1. Design Goals
One of our design goals is to revise the OneRowNim game so that it fits into a hierarchy of two-player games. One way to do this is to generalize the OneRowNim game by creating a superclass that contains those attributes and methods that are common to all two-player games. The superclass will define the most general and generic elements of two-player games. All two-player games, including OneRowNim, will be defined as subclasses of this top-level superclass and will inherit and possibly override its public and protected variables and methods. Also, our top-level class will contain certain abstract methods, whose implementations will be given in OneRowNim and other subclasses.
Generic superclass
A second goal is to design a class hierarchy that makes it possible for computers to play the game, as well as human users. Thus, for a given two-player game, it should be possible for two humans to play each other, or for two computers to play each other, or for a human to play against a computer. This design goal will require that our design exhibit a certain amount of flexibility. As we shall see, this is a situation in which Java interfaces will come in handy.
[Page 376]
Another important goal is to design a two-player game hierarchy that can easily be used with a variety of different user interfaces, including command-line interfaces and GUIs. To handle this feature, we will develop Java interfaces to serve as interfaces between our two-player games and various user interfaces.
8.6.2. Designing the TwoPlayerGame Class
To begin revising the design of the OneRowNim game, we first need to design a top-level class, which we will call the TwoPlayerGame class. What variables and methods belong in this class? One way to answer this question is to generalize our current version of OneRowNim by moving any variables and methods that apply to all two-player games up to the TwoPlayerGame class. All subclasses of TwoPlayerGamewhich includes the OneRowNim classwould inherit these elements. Figure 8.18 shows the current design of OneRowNim.
Figure 8.18. The current OneRowNim class.
What variables and methods should we move up to the TwoPlayerGame class? Clearly, the class constants, PLAYER_ONE and PLAYER_TWO, apply to all two-player games. These should be moved up. On the other hand, the MAX_PICKUP and MAX_STICKS constants apply just to the OneRowNim game. They should remain in the OneRowNim class.
The nSticks instance variable is a variable that only applies to the OneRowNim game but not to other two-player games. It should stay in the OneRowNim class. On the other hand, the onePlaysNext variable applies to all two-player games, so we will move it up to the TwoPlayerGame class.
Because constructors are not inherited, all of the constructor methods will remain in the OneRowNim class. The instance methods, takeSticks() and getSticks(), are specific to OneRowNim, so they should remain there. However, the other methods, getPlayer(), gameOver(), getWinner(), and reportGameState(), are methods that would be useful to all two-player games. Therefore these methods should be moved up to the superclass. Of course, while these methods can be defined in the superclass, some of them can only be implemented in subclasses. For example, the reportGameState() method reports the current state of the game, so it has to be implemented in OneRowNim. Similarly, the getWinner() method defines how the winner of the game is determined, a definition that can only occur in the subclass. Every two-player game needs methods such as these. Therefore, we will define these methods as abstract methods in the superclass. The intention is that TwoPlayerGame subclasses will provide game-specific implementations for these methods.
[Page 377]
Constructors are not inherited
Given these considerations, we come up with the design shown in Figure 8.19. The design shown in this figure is much more complex than the designs used in earlier chapters. However, the complexity comes from combining ideas already discussed in previous sections of this chapter, so don't be put off by it.
Figure 8.19. TwoPlayerGame is the superclass for OneRowNim and other two-player games.
To begin with, note that we have introduced two Java interfaces into our design in addition to the TwoPlayerGame superclass. As we will show, these interfaces lead to a more flexible design and one that can easily be extended to incorporate new two-player games. Let's take each element of this design separately.
[Page 378]
8.6.3. The TwoPlayerGame Superclass
As we have stated, the purpose of the TwoPlayerGame class is to serve as the superclass for all two-player games. Therefore, it should define the variables and methods shared by two-player games.
The PLAYER_ONE, PLAYER_TWO, and onePlaysNext variables and the getPlayer(), setPlayer(), and changePlayer() methods have been moved up from the OneRowNim class. Clearly, these variables and methods apply to all two-player games. Note that we have also added three new variables, nComputers, computer1, computer2, and their corresponding methods, getNComputers() and addComputerPlayer(). We will use these elements to give our games the capability to be played by computer programs. Because we want all of our two-player games to have this capability, we define these variables and methods in the superclass rather than in OneRowNim and subclasses of TwoPlayerGame.
Note that the computer1 and computer2 variables are declared to be of type IPlayer. IPlayer is an interface containing a single method declaration, the makeAMove() method:
public interface IPlayer {
public String makeAMove(String prompt);
Why do we use an interface here rather than some type of game-playing object? This is a good design question. Using an interface here makes our design more flexible and extensible because it frees us from having to know the names of the classes that implement the makeAMove() method. The variables computer1 and computer2 will be assigned objects that implement IPlayer via the addComputerPlayer() method.
Game-dependent algorithms
The algorithms used in the various implementations of makeAMove() are game-dependentthey depend on the particular game being played. It would be impossible to define a game playing object that would suffice for all two-player games. Instead, if we want an object that plays OneRowNim, we would define a OneRowNimPlayer and have it implement the IPlayer interface. Similarly, if we want an object that plays checkers, we would define a CheckersPlayer and have it implement the IPlayer interface. By using an interface here, our TwoPlayerGame hierarchy can deal with a wide range of differently named objects that play games, as long as they implement the IPlayer interface. Using the IPlayer interface adds flexibility to our game hierarchy and makes it easier to extend it to new, yet undefined, classes. We will discuss the details of how to design a game player in Section 8.6.7.
The IPlayer interface
Turning now to the methods defined in TwoPlayerGame, we have already seen implementations of getPlayer(), setPlayer(), and changePlayer() in the OneRowNim class. We will just move those implementations up to the superclass. The getNComputers() method is the assessor method for the nComputers variable, and its implementation is routine. The addComputerPlayer() method adds a computer player to the game. Its implementation is as follows:
[Page 379]
public void addComputerPlayer(IPlayer player) {
if (nComputers == 0)
computer2 = player;
else if (nComputers == 1)
computer1 = player;
else
return; // No more than 2 players
++nComputers;
As we noted earlier, the classes that play the various TwoPlayerGames must implement the IPlayer interface. The parameter for this method is of type IPlayer. The algorithm we use checks the current value of nComputers. If it is 0, which means that this is the first IPlayer added to the game, the player is assigned to computer2. This allows the human user to be associated with PLAYERONE if this is a game between a computer and a human user.
If nComputers equals 1, which means that we are adding a second IPlayer to the game, we assign that player to computer1. In either of these cases, we increment nComputers. Note what happens if nComputers is neither 1 nor 2. In that case, we simply return without adding the IPlayer to the game and without incrementing nComputers. This, in effect, limits the number of IPlayers to two. (A more sophisticated design would throw an exception to report an error. but we will leave that for a subsequent chapter.)
The addComputerPlayer() method is used to initialize a game after it is first created. If this method is not called, the default assumption is that nComputers equals zero and that computer1 and computer2 are both null. Here's an example of how it could be used:
OneRowNim nim = new OneRowNim(11); // 11 sticks
nim.add(new NimPlayer(nim)); // 2 computer players
nim.add(new NimPlayerBad(nim));
Note that the NimPlayer() constructor takes a reference to the game as its argument. Clearly, our design should not assume that the names of the IPlayer objects would be known to the TwoPlayerGame superclass. This method allows the objects to be passed in at runtime. We will discuss the details of NimPlayerBad in Section 8.6.7.
The getrules() method is a new method whose purpose is to return a string that describes the rules of the particular game. This method is implemented in the TwoPlayerGame class with the intention that it will be overridden in the various subclasses. For example, its implementation in TwoPlayerGame is:
public String getRules() {
return "The rules of this game are: ";
Overriding a method
[Page 380]
and its redefinition in OneRowNim is:
public String getRules() {
return "\n*** The Rules of One Row Nim ***\n" +
"(1) A number of sticks between 7 and " + MAX_STICKS +
" is chosen.\n" +
"(2) Two players alternate making moves.\n" +
"(3) A move consists of subtracting between 1 and\n\t" +
MAX_PICKUP +
" sticks from the current number of sticks.\n" +
"(4) A player who cannot leave a positive\n\t" +
" number of sticks for the other player loses.\n";
The idea is that each TwoPlayerGame subclass will take responsibility for specifying its own set of rules in a form that can be displayed to the user.
You might recognize that defining geTRules() in the superclass and allowing it to be overridden in the subclasses is a form of polymorphism. It follows the design of the toString() method, which we discussed earlier. This design will allow us to use code that takes the following form:
TwoPlayerGame game = new OneRowNim();
System.out.println(game.getRules());
Polymorphism
In this example the call to getrules() is polymorphic. The dynamic-binding mechanism is used to invoke the getrules() method defined in the OneRowNim class.
The remaining methods in TwoPlayerGame are defined abstractly. The gameOver() and getWinner() methods are both game-dependent methods. That is, the details of their implementations depend on the particular TwoPlayerGame subclass in which they are implemented.
This is good example of how abstract methods should be used in designing a class hierarchy. We give abstract definitions in the superclass and leave the detailed implementations up to the individual subclasses. This allows the different subclasses to tailor the implementations to their particular needs, while allowing all subclasses to share a common signature for these tasks. This enables us to use polymorphism to create flexible, extensible class hierarchies.
Figure 8.20 shows the complete implementation of the abstract TwoPlayerGame class. We have already discussed the most important details of its implementation.
Figure 8.20. The TwoPlayerGame class
(This item is displayed on page 381 in the print version)
public abstract class TwoPlayerGame {
public static final int PLAYER_ONE = 1;
public static final int PLAYER_TWO = 2;
protected boolean onePlaysNext = true;
protected int nComputers = 0; // How many computers
// Computers are IPlayers
protected IPlayer computer1, computer2;
public void setPlayer(int starter) {
if (starter == PLAYER_TWO)
onePlaysNext = false;
else onePlaysNext = true;
} // setPlayer()
public int getPlayer() {
if (onePlaysNext)
return PLAYER_ONE;
else return PLAYER_TWO;
} // getPlayer()
public void changePlayer() {
onePlaysNext = !onePlaysNext;
} // changePlayer()
public int getNComputers() {
return nComputers;
} // getNComputers()
public String getRules() {
return "The rules of this game are: ";
} // getRules()
public void addComputerPlayer(IPlayer player) {
if (nComputers == 0)
computer2 = player;
else if (nComputers == 1)
computer1 = player;
else
return; // No more than 2 players
++nComputers;
} // addComputerPlayer()
public abstract boolean gameOver(); // Abstract Methods
public abstract String getWinner();
} // TwoPlayerGame class
Effective Design: Abstract Methods
Abstract methods allow you to give general definitions in the superclass and leave the implementation details to the different subclasses.
[Page 381]
8.6.4. The CLUIPlayableGame Interface
We turn now to the two interfaces shown in Figure 8.19. Taken together, the purpose of these interfaces is to create a connection between any two-player game and a command-line user interface (CLUI). The interfaces provide method signatures for the methods that will implement the details of the interaction between a TwoPlayerGame and a UserInterface. Because the details of this interaction vary from game to game, it is best to leave the implementation of these methods to the games themselves.
Note that CLUIPlayableGame extends the IGame interface. The IGame interface contains two methods that are used to define a standard form of communication between the CLUI and the game. The getGamePrompt() method defines the prompt used to signal the user for a move of some kindfor example, "How many sticks do you take (1, 2, or 3)?" And the reportGameState() method defines how the game will report its current statefor example, "There are 11 sticks remaining." CLUIPlayableGame adds the play() method to these two methods. As we will see shortly, the play() method contains the code that will control the playing of the game.
[Page 382]
Extending an interface
The source code for these interfaces is very simple:
public interface CLUIPlayableGame extends IGame {
public abstract void play(UserInterface ui);
public interface IGame {
public String getGamePrompt();
public String reportGameState();
} // IGame
Note that the CLUIPlayableGame interface extends the IGame interface. A CLUIPlayableGame is a game that can be played through a CLUI. The purpose of its play() method is to contain the game-dependent control loop that determines how the game is played via a user interface (UI). In pseudocode, a typical control loop for a game would look something like the following:
Initialize the game.
While the game is not over
Report the current state of the game via the UI.
Prompt the user (or the computer) to make a move via the UI.
Get the user's move via the UI.
Make the move.
Change to the other player.
The play loop sets up an interaction between the game and the UI. The UserInterface parameter allows the game to connect directly to a particular UI. To allow us to play our games through a variety of UIs, we define UserInterface as the following Java interface:
public interface UserInterface {
public String getUserInput();
public void report(String s);
public void prompt(String s);
Any object that implements these three methods can serve as a UI for one of our TwoPlayerGames. This is another example of the flexibility of using interfaces in object-oriented design.
To illustrate how we use UserInterface, let's attach it to our KeyboardReader class, thereby letting a KeyboardReader serve as a CLUI for TwoPlayerGames. We do this simply by implementing this interface in the KeyboardReader class, as follows:
public class KeyboardReader implements UserInterface
[Page 383]
As it turns out, the three methods listed in UserInterface match three of the methods in the current version of KeyboardReader. This is no accident. The design of UserInterface was arrived at by identifying the minimal number of methods in KeyboardReader that were needed to interact with a TwoPlayerGame.
Effective Design: Flexibility of Java Interfaces
A Java interface provides a means of associating useful methods with a variety of different types of objects, leading to a more flexible object-oriented design.
The benefit of defining the parameter more generally as a UserInterface instead of as a KeyboardReader is that we will eventually want to allow our games to be played via other kinds of command-line interfaces. For example, we might later define an Internet-based CLUI that could be used to play OneRowNim among users on the Internet. This kind of extensibilitythe ability to create new kinds of UIs and use them with TwoPlayerGamesis another important design feature of Java interfaces.
Generality principle
Effective Design: Extensibility and Java Interfaces
Using interfaces to define useful method signatures increases the extensibility of a class hierarchy.
As Figure 8.19 shows, OneRowNim implements the CLUIPlayableGame interface, which means it must supply implementations of all three abstract methods: play(), getGamePrompt(), and reportGameState().
8.6.5. Object-Oriented Design: Interfaces or Abstract Classes?
Why are these methods defined in interfaces? Couldn't we just as easily define them in the TwoPlayerGame class and use inheritance to extend them to the various game subclasses? After all, isn't the net result the same, namely, that OneRowNim must implement all three methods.
These are very good design questions, exactly the kinds of questions one should ask when designing a class hierarchy of any sort. As we pointed out in the Animal example earlier in the chapter, you can get the same functionality from an abstract interface and an abstract superclass method. When should we put the abstract method in the superclass, and when does it belong in an interface? A very good discussion of these and related object-oriented design issues is available in Java Design, 2nd Edition, by Peter Coad and Mark Mayfield (Yourdan Press, 1999). Our discussion of these issues follows many of the guidelines suggested by Coad and Mayfield.
Interfaces vs. abstract methods
We have already seen that using Java interfaces increases the flexibility and extensibility of a design. Methods defined in an interface exist independently of a particular class hierarchy. By their very nature, interfaces can be attached to any class, and this makes them very flexible to use.
Flexibility of interfaces
Another useful guideline for answering this question is that the superclass should contain the basic common attributes and methods that define a certain type of object. It should not necessarily contain methods that define certain roles that the object plays. For example, the gameOver() and getWinner() methods are fundamental parts of the definition of a TwoPlayerGame. One cannot define a game without defining these methods. By contrast, methods such as play(), getGamePrompt(), and reportGameState() are important for playing the game but they do not contribute in the same way to the game's definition. Thus these methods are best put into an interface. Therefore, one important design guideline is:
[Page 384]
Effective Design: Abstract Methods
Methods defined abstractly in a superclass should contribute in a fundamental way to the basic definition of that type of object, not merely to one of its roles or its functionality.
8.6.6. The Revised OneRowNim Class
Figure 8.21 provides a listing of the revised OneRowNim class, one that fits into the TwoPlayerGame class hierarchy. Our discussion in this section will focus on the features of the game that are new or revised.
Figure 8.21. The revised OneRowNim class, Part I.
(This item is displayed on page 385 in the print version)
public class OneRowNim extends TwoPlayerGame implements CLUIPlayableGame {
public static final int MAX_PICKUP = 3;
public static final int MAX_STICKS = 11;
private int nSticks = MAX_STICKS;
public OneRowNim() { } // Constructors
public OneRowNim(int sticks) {
nSticks = sticks;
} // OneRowNim()
public OneRowNim(int sticks, int starter) {
nSticks = sticks;
setPlayer(starter);
} // OneRowNim()
public boolean takeSticks(int num) {
if (num < 1 || num > MAX_PICKUP || num > nSticks)
return false; // Error
else // Valid move
{ nSticks = nSticks - num;
return true;
} // else
} // takeSticks()
public int getSticks() {
return nSticks;
} // getSticks()
public String getRules() {
return "\n*** The Rules of One Row Nim ***\n" +
"(1) A number of sticks between 7 and " + MAX_STICKS +
" is chosen.\n" +
"(2) Two players alternate making moves.\n" +
"(3) A move consists of subtracting between 1 and\n\t" +
MAX_PICKUP + " sticks from the current number of sticks.\n" +
"(4) A player who cannot leave a positive\n\t" +
" number of sticks for the other player loses.\n";
} // getRules()
public boolean gameOver() {   /*** From TwoPlayerGame */
return (nSticks <= 0);
} // gameOver()
public String getWinner() {        /*** From TwoPlayerGame */
if (gameOver()) //{
return "" + getPlayer() + " Nice game.";
return "The game is not over yet."; // Game is not over
} // getWinner()
The gameOver() and getWinner() methods, which are nowinherited from the TwoPlayerGame superclass, are virtually the same as in the previous version. One small change is that getWinner() now returns a String instead of an int. This makes the method more generally useful as a way of identifying the winner for all TwoPlayerGames.
Similarly, the getGamePrompt() and reportGameState() methods merely encapsulate functionality that was present in the earlier version of the game. In our earlier version the prompts to the user were generated directly by the main program. By encapsulating this information in an inherited method, we make it more generally useful to all TwoPlayerGames.
Inheritance and generality
The major change to OneRowNim comes in the play() method, which controls the playing of OneRowNim (Fig. 8.22). Because this version of the game incorporates computer players, the play loop is a bit more complex than in earlier versions of the game. The basic idea is still the same: The method loops until the game is over. On each iteration of the loop, one or the other of the two players, PLAYER_ONE or PLAYER_TWO, takes a turn making a movethat is, deciding how many sticks to pick up. If the move is a legal move, then it becomes the other player's turn.
Figure 8.22. The revised OneRowNim class, Part II.
(This item is displayed on page 386 in the print version)
/** From CLUIPlayableGame */
public String getGamePrompt() {
return "\nYou can pick up between 1 and " +
Math.min(MAX_PICKUP,nSticks) + " : ";
} // getGamePrompt()
public String reportGameState() {
if (!gameOver())
return ("\nSticks left: " + getSticks() +
" Who's turn: Player " + getPlayer());
else
return ("\nSticks left: " + getSticks() +
" Game over! Winner is Player " + getWinner() +"\n");
} // reportGameState()
public void play(UserInterface ui) { // From CLUIPlayableGame interface
int sticks = 0;
ui.report(getRules());
if (computer1 != null)
ui.report("\nPlayer 1 is a " + computer1.toString());
if (computer2 != null)
ui.report("\nPlayer 2 is a " + computer2.toString());
while(!gameOver()) {
IPlayer computer = null; // Assume no computers
ui.report(reportGameState());
switch(getPlayer()) {
case PLAYER_ONE: // Player 1's turn
computer = computer1;
break;
case PLAYER_TWO: // Player 2's turn
computer = computer2;
break;
} // cases
if (computer != null) {                           // If computer's turn
sticks = Integer.parseInt(computer.makeAMove(""));
ui.report(computer.toString() + " takes " + sticks + " sticks.\n");
} else {                                          // otherwise, user's turn
ui.prompt(getGamePrompt());
sticks =
Integer.parseInt(ui.getUserInput()); // Get user's move
if (takeSticks(sticks)) // If a legal move
changePlayer();
} // while
ui.report(reportGameState()); // The game is now over
} // play()
} // OneRowNim class
Let's look now at how the code decides whether it is a computer's turn to move or a human player's turn. Note that at the beginning of the while loop, it sets the computer variable to null. It then assigns computer a value of either computer1 or computer2, depending on whose turn it is. But recall that one or both of these variables may be null, depending on how many computers are playing the game. If there are no computers playing the game, then both variables will be null. If only one computer is playing, then computer1 will be null. This is determined during initialization of the game, when the addComputerPlayer() is called. (See above.)
In the code following the switch statement, if computer is not null, then we call computer.makeAMove(). As we know, the makeAMove() method is part of the IPlayer interface. The makeAMove() method takes a String parameter that is meant to serve as a prompt, and returns a String that is meant to represent the IPlayer's move:
public interface IPlayer {
public String makeAMove(String prompt);
[Page 385]
In OneRowNim the "move" is an integer, representing the number of sticks the player picks. Therefore, in play() OneRowNim has to convert the String into an int, which represents the number of sticks the IPlayer picks up.
On the other hand, if computer is null, this means that it is a human user's turn to play. In this case, play() calls ui.getUserInput(), employing the user interface to input a value from the keyboard. The user's input must also be converted from String to int. Once the value of sticks is set, either from the user or from the IPlayer, the play() method calls takeSticks(). If the move is legal, then it changes whose turn it is, and the loop repeats.
[Page 386]
There are a couple of important points about the design of the play() method. First, the play() method has to know what to do with the input it receives from the user or the IPlayer. This is game-dependent knowledge. The user is inputting the number of sticks to take in OneRowNim. For a tic-tac-toe game, the "move" might represent a square on the tic-tac-toe board. This suggests that play() is a method that should be implemented in OneRowNim, as it is here, because OneRowNim encapsulates the knowledge of how to play the One-Row Nim game.
Encapsulation of game-dependent knowledge
[Page

Difference between abstract class and the normal class

Hi...........
can anyone tell me use of abstract class instead of normal class
The main doubt for me is...
1.why we are defining the abstract method in a abstract class and then implementing that in to the normal class.instead of that we can straight way create and implement the method in normal class right...../

Class vs. interface
Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme. I use interfaces when I see that something in my design will change frequently.
For example, the Strategy pattern lets you swap new algorithms and processes into your program without altering the objects that use them. A media player might know how to play CDs, MP3s, and wav files. Of course, you don't want to hardcode those playback algorithms into the player; that will make it difficult to add a new format like AVI. Furthermore, your code will be littered with useless case statements. And to add insult to injury, you will need to update those case statements each time you add a new algorithm. All in all, this is not a very object-oriented way to program.
With the Strategy pattern, you can simply encapsulate the algorithm behind an object. If you do that, you can provide new media plug-ins at any time. Let's call the plug-in class MediaStrategy. That object would have one method: playStream(Stream s). So to add a new algorithm, we simply extend our algorithm class. Now, when the program encounters the new media type, it simply delegates the playing of the stream to our media strategy. Of course, you'll need some plumbing to properly instantiate the algorithm strategies you will need.
This is an excellent place to use an interface. We've used the Strategy pattern, which clearly indicates a place in the design that will change. Thus, you should define the strategy as an interface. You should generally favor interfaces over inheritance when you want an object to have a certain type; in this case, MediaStrategy. Relying on inheritance for type identity is dangerous; it locks you into a particular inheritance hierarchy. Java doesn't allow multiple inheritance, so you can't extend something that gives you a useful implementation or more type identity.
Interface vs. abstract class
Choosing interfaces and abstract classes is not an either/or proposition. If you need to change your design, make it an interface. However, you may have abstract classes that provide some default behavior. Abstract classes are excellent candidates inside of application frameworks.
Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class.

Problems implementing abstract classes

hello.
this is james mcfadden. I am developing a multiplayer BlackJack card game in Java. the game consists of three programs: BlackJack.java, BlackJackServer.java and BlackJackClient.java (three 3 programs are shown below). i don't know how to implement abstract classes. i am trying to get the BlackJack.java program working with the BlackJackServer.java program. there should be "extends BlackJackServer" somewhere in the BlackJack.java program, but i don't know where.
import javax.swing.*;
public class BlackJack extends JPanel{
   public BlackJack(){
      //FlowLayout is default layout manager for a JPanel
      add(new JButton("Hit"));
      add(new JButton("Stay"));
      add(new JButton("New Game"));
   public static void main(String[] args){
      JFrame frame=new JFrame("BlackJack");
      frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      frame.setSize(500,500);
      frame.setLocation(200,200);
      BlackJack bj=new BlackJack();
      frame.setContentPane(bj);
      frame.setVisible(true);
import java.io.*;//Provides for system input and output through data streams, serialization and the file system
import java.net.*;//Provides the classes for implementing networking applications
import java.util.*;//Contains the collections framework, legacy collection classes, event model, date and time facilities, internationalization, and miscellaneous utility classes
import java.awt.*;//Contains all of the classes for creating user interfaces and for painting graphics and images
import javax.swing.*;//Provides a set of lightweight components that, to the maximum degree possible, work the same on all platforms
public class BlackJackServer extends JFrame{
   private JTextArea jta=new JTextArea();//a text area for displaying text
   public static void main(String[] args){
          new BlackJackServer();//invokes the constructor BlackJackServer()
   }//end main
   public BlackJackServer(){
      setLayout(new BorderLayout());//places the text area on the frame
      add(new JScrollPane(jta),BorderLayout.CENTER);//lays out a text area, arranging and resizing its components to fit in the centre region;and provides a scrollable view of a lightweight component
      setTitle("BlackJack Server");//Sets the title for this frame to the specified string
      setSize(500,300);//Resizes this component so that it has a width and a height
      setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);//Sets the operation that will happen by default when the user closes this frame
      setVisible(true);//shows the frame
      try{
         ServerSocket serverSocket=new ServerSocket(8000);//creates a server socket
         jta.append("Server started at "+new Date()+'\n');//displays the current date in the text area
         Socket socket=serverSocket.accept();//listens for a connection request
         DataInputStream inputFromClient=new DataInputStream(socket.getInputStream());//creates a data input stream
         DataOutputStream outputToClient=new DataOutputStream(socket.getOutputStream());//creates a data output stream
         while(true){
            float bet=inputFromClient.readFloat();//receives bet from the client
            float doublebet=bet+bet;//computes double the bet
            outputToClient.writeFloat(doublebet);//sends double the bet back to the client
            jta.append("Bet received from client: "+bet+'\n');//displays the bet in the text area
            jta.append("Double the bet found: "+doublebet+'\n');//displays double the bet in the text area
         }//end while
      }//end try
      catch(IOException ex){
         System.err.println(ex);//displays an error message
      }//end catch
   }//end constructor
}//end class BlackJackServer
import java.io.*;//Provides for system input and output through data streams, serialization and the file system
import java.net.*;//Provides the classes for implementing networking applications
import java.awt.*;//Contains all of the classes for creating user interfaces and for painting graphics and images
import java.awt.event.*;//Provides interfaces and classes for dealing with different types of events fired by AWT components
import javax.swing.*;//Provides a set of lightweight components that, to the maximum degree possible, work the same on all platforms
public class BlackJackClient extends JFrame{
   private JTextField jtf=new JTextField();//a text field for receiving text
   private JTextArea jta=new JTextArea();//a text area for displaying text
   private DataOutputStream toServer;//output stream
   private DataInputStream fromServer;//input stream
   public static void main(String[] args){
      new BlackJackClient();//invokes the constructor BlackJackClient()
   public BlackJackClient(){
      JPanel p=new JPanel();//holds the label and text field
      p.setLayout(new BorderLayout());//sets the layout of the content pane of this component by default
      p.add(new JLabel("Enter bet"),BorderLayout.WEST);//displays the bet and lays out a JLabel, arranging and resizing its components to fit in the western region
      p.add(jtf,BorderLayout.CENTER);//lays out the text field, arranging and resizing its components to fit in the centre region
      jtf.setHorizontalAlignment(JTextField.RIGHT);//Sets the horizontal alignment of the text to the right
      setLayout(new BorderLayout());//places the text area on the frame
      add(p,BorderLayout.NORTH);//lays out the text field, arranging and resizing its components to fit in the northern region
      add(new JScrollPane(jta),BorderLayout.CENTER);//lays out a text area, arranging and resizing its components to fit in the centre region;and provides a scrollable view of a lightweight component
      jtf.addActionListener(new ButtonListener());//invokes the ButtonListener class
      setTitle("BlackJack Client");//Sets the title for this frame to the specified string
      setSize(500,300);//Resizes this component so that it has a width and a height
      setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);//Sets the operation that will happen by default when the user closes this frame
      setVisible(true);//shows the frame
      try{
         Socket socket=new Socket("localhost",8000);//creates a socket to connect to the server
         fromServer=new DataInputStream(socket.getInputStream());//creates an input stream to receive data from the server
         toServer=new DataOutputStream(socket.getOutputStream());//creates an output stream to send data to the server
      }//end try
      catch(IOException ex){
         jta.append(ex.toString()+'\n');//displays an error message
      }//end catch
   private class ButtonListener implements ActionListener{
      public void actionPerformed(ActionEvent e){
         try{
            float bet=Float.parseFloat(jtf.getText().trim());//gets the bet from the text field
            toServer.writeFloat(bet);//Converts the float argument to an int using the floatToIntBits method in class Float, and then writes that int value to the underlying output stream
            toServer.flush();//Flushes this output stream and forces any buffered output bytes to be written out
            float doublebet=fromServer.readFloat();//gets double the bet from the server
            jta.append("Bet is "+bet+"\n");//displays the bet in the text area
            jta.append("Double the bet received from the server is "+doublebet+'\n');//displays double the bet in the text area
         }//end try
         catch(IOException ex){
            System.err.println(ex);//displays an error message
         }//end catch
      }//end method
   }//end class
}//end class BlackJackClient

there should be "extends BlackJackServer" somewhere in the BlackJack.java programI very much doubt that.
It's possible you might need to create a BlackJackServer object or something like that. But I don't see the point in subclassing it.

Abstract Class that implements Comparable

I am trying to understand how a comparable interface works with an abstract class. Any help is greatly appreciated.
I have a class ClassA defined as follows:
public abstract class ClassA implements Comparable I have a method, compareTo(..), within ClassA as follows:
public int compareTo(Object o) I have a sub-class ClassB defined as follows:
public class ClassB extends ClassAI am receiving a compile error:
Class must implement the inherited abstract method packagename.ClassA.compareTo(Object)
Should or can the compareTo be abstract in ClassA and executed in ClassB? Just not sure how this works.

???? if you are inheriting from an abstract class your subclass must implement methods that were declared in the parent (abstract) class but not implemented
When in doubt, refer to the Java Language Specification..

ABSTRACT class and method

Dear all Abaper experts,
I am doubt on a abap object program shown as below. It is a ABSTRACT class and method. However, during compiling, an error message is displayed "The abstract method 'WRITE_STATUS' may not be implemented". What does it mean?
REPORT ZOOP_ABSTRACT.
* Class Declaration
CLASS vehicle DEFINITION ABSTRACT.
PUBLIC SECTION.
    METHODS: accelerate,
             write_status ABSTRACT.
PROTECTED SECTION.
    DATA speed TYPE i.
ENDCLASS.
CLASS plane DEFINITION INHERITING FROM vehicle.
PUBLIC SECTION.
    METHODS: rise.
PROTECTED SECTION.
    DATA altitude TYPE i.
ENDCLASS.
CLASS ship DEFINITION INHERITING FROM vehicle.
ENDCLASS.
* Class Implementation
CLASS vehicle IMPLEMENTATION.
METHOD accelerate.
    speed = speed + 1.
ENDMETHOD.
ENDCLASS.
CLASS plane IMPLEMENTATION.
METHOD rise.
    altitude = altitude + 1.
ENDMETHOD.
METHOD write_status.
    WRITE: / 'Plane speed:', speed.
    WRITE: / 'Altitude:', altitude.
ENDMETHOD.
ENDCLASS.
CLASS ship IMPLEMENTATION.
ENDCLASS.
* Global Data
DATA: plane_ref TYPE REF TO plane,
      ship_ref TYPE REF TO ship.
* Classical Processing Blocks
START-OF-SELECTION.
CREATE OBJECT: plane_ref,
                 ship_ref.
CALL METHOD: plane_ref->accelerate,
               plane_ref->rise,
               plane_ref->write_status,
               plane_ref->accelerate,
               plane_ref->write_status.
All answers are welcome and appreciate for the help.

Hi,
try this code I've rearranged your Class Implementation and just added the foll code;
write_status REDEFINITION in the Definition part of the Subclass.
* Class Declaration
CLASS vehicle DEFINITION ABSTRACT.
PUBLIC SECTION.
    METHODS: accelerate,
             write_status ABSTRACT.
PROTECTED SECTION.
    DATA speed TYPE i.
ENDCLASS.
* Class Implementation
CLASS vehicle IMPLEMENTATION.
METHOD accelerate.
    speed = speed + 1.
ENDMETHOD.
ENDCLASS.
CLASS plane DEFINITION INHERITING FROM vehicle.
PUBLIC SECTION.
    METHODS: rise,
             write_status redefinition.
PROTECTED SECTION.
    DATA altitude TYPE i.
ENDCLASS.
CLASS plane IMPLEMENTATION.
METHOD rise.
    altitude = altitude + 1.
ENDMETHOD.
METHOD write_status.
    WRITE: / 'Plane speed:', speed.
    WRITE: / 'Altitude:', altitude.
ENDMETHOD.
ENDCLASS.
CLASS ship DEFINITION INHERITING FROM vehicle.
PUBLIC SECTION.
    METHODS: write_status redefinition.
ENDCLASS.
CLASS ship IMPLEMENTATION.
METHOD write_status.
    WRITE: / 'In Ship Class.'.
ENDMETHOD.
ENDCLASS.
* Global Data
DATA: plane_ref TYPE REF TO plane,
      ship_ref TYPE REF TO ship.
* Classical Processing Blocks
START-OF-SELECTION.
CREATE OBJECT: plane_ref,
                 ship_ref.
CALL METHOD: plane_ref->accelerate,
               plane_ref->rise,
               plane_ref->write_status,
               plane_ref->accelerate,
               plane_ref->write_status,
               ship_ref->write_status.
Best Regards,
Sunil.

Whether Thread is abstract class

Hi all..
plz clarify my doubt
1)If u extend Thread class u have to override run()
method. i.e in that sence run() is an abstract method
in Thread class so since Thread class contains one
abstract method it should be abstract class...i.e
Thread is an abstract class. and we know that an
abstrcat class cannot be instantiated using new
operator but i saw
Thread t =new Thread();
whats wrong...whare i mis understood...
thank u
regards
jagadeesh

1)If u extend Thread class u have to override run()
method. i.e in that sence run() is an abstract method
in Thread class Overriding run() in Thread is optional.
so since Thread class contains one
abstract method it should be abstract class...i.e
Thread is an abstract class.A class does not have to be abstract to contains abstract methods.

Situation where you are interface & abstract class?

please let me know if any one knowns answer for the above question

But my doubt in which situation we r using interface
and abstarct classesWithout repeating the debates, you should use interfaces to define the contract for developers to use. This is usually done when nothing is known about the concrete implementation but the design is ready. This is also useful when you need to have multiple inheritance.
Abstract classes are useful when you want to force the implementation of some of the methods onto the developers, rather than everyone having their own implementations. This is preferred when there is some concrete idea of some of the methods in the class while the implementations of the remaining methods can vary with the specialization of the sub-classes.
You might want to read this:
http://www.javaworld.com/javaworld/javaqa/2001-04/03-qa-0420-abstract.html

What is the diff b/w Abstract class and an interface ?

Hey
I am always confused as with this issue : diff b/w Abstract class and an interface ?
Which is more powerful in what situation.
Regards
Vinay

Hi, Don't worry I am teach you
Abstract class and Interface
An abstract class can have instance methods that implement a default behavior. An Interface can only declare constants and instance methods, but cannot implement default behavior and all methods are implicitly abstract. An interface has all public members and no implementation. An abstract class is a class which may have the usual flavors of class members (private, protected, etc.), but has some abstract methods.
Edited by SASIKUMARA
SIT INNOVATIONS- Chennai
Message was edited by:
sasikumara
Message was edited by:
sasikumara

Abstract class with set and get methods

hi
how to write set and get methods(plain methods) in an abstartc class
ex: setUsername(String)
String getUsername()
and one class is extending this abstract class and same methods existing in that sub class also..... how to write......plz provide some ideas
am new to programming....
asap
thnx in advance

yes... as i told u.... i am new to coding......
and my problem is ..... i have 2 classes one is abstract class without abstract methods.. and another class is extending abstract class.....
in abstract class i have 2 methods...one is setusername(string) and getusername() ..... how to write these two methods.... in abstract class i have private variables username...... when user logins ..... i need to catch the user name and i need to validate with my oracle database and i need to identify the role of that user and based on role of that user i need to direct him to appropriate jsp page.......
for that now i am writing business process classes..... the above mentioned two classes are from business process.....
could u help me now
thnx in advance

Calling a super.ssuper.method but your super is a abstract class.

Dear guys,
Is that possible to invoke your super's super's method but your super is a abstract class?
like:
class GO { public void draw() { } }
abstract class GORunner extends GO {}
class GOCounter extends GORunner {
public void draw() {
super.super.draw();
I want to do this because I would like to take advantages of the abstract as an layer to achieve some polymorphism programming Therefore, in the later stage of the programming some code may only refer to GORunner but actually it is holding a GOCounter object.
Thank!!

BTW you don't need to write this
public void draw() {
super.draw();
}It works but its basically the same as not having it at all.

Calling a method from an abstract class in a seperate class

I am trying to call the getID() method from the Chat class in the getIDs() method in the Outputter class. I would usually instantiate with a normal class but I know you cant instantiate the method when using abstract classes. I've been going over and over my theory and have just become more confused??
Package Chatroom
public abstract class Chat
   private String id;
   public String getID()
      return id;
   protected void setId(String s)
      id = s;
   public abstract void sendMessageToUser(String msg);
Package Chatroom
public class Outputter
public String[] getIDs()
     // This is where I get confused. I know you can't instantiate the object like:
        Chat users=new Chat();
        users.getID();
I have the two classes in the package and you need to that to be able to use a class' methods in another class.
Please help me :(

I have just looked over my program and realised my class names are not the most discriptive, so I have renamed them to give you a clearer picture.
package Chatroom
public abstract class Chatter
private String id;
public String getID()
return id;
protected void setId(String s)
id = s;
I am trying to slowly build a chatroom on my own. The Chatter class is a class that will be used to represent a single logged in user and the user is given an ID when he logs in through the setId and getID() methods.
package Chatroom;
import java.util.Vector;
public class Broadcaster
private Vector<Chatter> chatters = new Vector<Chatter>();
public String[] getIDs()
// code here
The Broadcaster class will keep a list of all logged-in users keeps a list of all the chats representing logged-in users, which it stores in a Vector.I am trying to use the getIDs() method to return an array of Strings comprising the IDs of all logged-in users, which is why im trying to use the getID() method from the Chat class.
I apologise if I come across as clueless, it's just I have been going through books for about 4 hours now and I have just totally lossed all my bearings

EJB question: How to use abstract class in writing a session bean?

I had written an abstract class which implements the session bean as follow:
public abstract class LoggingSessionBean implements SessionBean {
protected SessionContext ctx;
protected abstract Object editRecord(Object obj) throws Exception;
public LoggingSessionBean()
super();
private final String getBeforeUpdateImage(Object obj) throws Exception {
// implement the details of extracting the backup image ...
public void setSessionContext(SessionContext ctx)
this.ctx = ctx;
private final void writeThisImageToDatabase(String aStr) {
// connect to database to write the record ...
public final Object update(final Object obj) {
try {
final String aStr = getBeforeUpdateImage(obj);
writeThisImageToDatabase(aStr);
editRecord(obj);
} catch (Exception e) {
ctx.setRollbackOnly();
This abstract class is to write the backup image to the database so that other session beans extending it only need to implement the details in editRecord(Object Obj) and they do not need to take care of the operation of making the backup image.
However, some several questions for me are:
1. If I write a class ScheduleSessionBean extending the above abstract class and the according 2 interfaces ScheduleSession and ScheduleSessionHome for this session bean (void update(Object obj); defined in ScheduleSession), do I still need to write the interfaces for LoggingSession and LoggingSessionHome?
2. If I wrote the interface LoggingSession extending EJBObject where it defined the abstract methods "void update(Object obj);" and "void setSessionContext(SessionContext ctx);", that this meant I needed to write the ScheduleSession to implement the Logging Session?
3. I used OC4J 9.0.4. How can I define the ejb-jar.xml in this case?

Hi Maggie,
1. do I still need to write
the interfaces for LoggingSession and
LoggingSessionHome?"LoggingSessionBean" can't be a session bean, because it's an abstract class. Therefore there's no point in thinking about the 'home' and 'remote' interfaces.
2. this
meant I needed to write the ScheduleSession to
implement the Logging Session?Again, not really a question worth considering, since "LoggingSessionBean" can't be an EJB.
3. I used OC4J 9.0.4. How can I define the
ejb-jar.xml in this case?Same as you define it for any version of OC4J and for any EJB container, for that matter, since the "ejb-jar.xml" file is defined by the EJB specification.
Let me suggest that you create a "Logging" class as a regular java class, and give your "ScheduleSessionBean" a member that is an instance of the "Logging" class.
Alternatively, the "ScheduleSessionBean" can extend the "Logging" class and implement the "SessionBean" interface.
Good Luck,
Avi.

".. is an abstract class. It can't be instantiated"

Does anyone have an idea of how I can get rid of the above error message? Here is a bit of my code:
import java.io.*;
import java.util.Vector;
class Project3 {
private BiTree company = new BiTree();
public static void main(String[] args) throws IOException {
Project3 run = new Project3();
run.Command();
public void Command() throws IOException {}
public interface comparable {
//not sure if need this in this class, or at all
public int compare(Object object1,Object object2);
public void add() {
Employee newOne = new Employee();
System.out.println("Enter name");
BufferedReader stdin = new BufferedReader (new InputStreamReader (System.in));;
String name = stdin.readLine();
System.out.println("Enter title");
BufferedReader stdin = new BufferedReader (new InputStreamReader (System.in));;
String title = stdin.readLine();
System.out.println("Enter payrate");
BufferedReader stdin = new BufferedReader (new InputStreamReader (System.in));;
payrate = Double.parseDouble.stdin.readLine();
newOne.setTitle(title);
newOne.setName(name);
newOne.setPayrate(payrate);
company.insert(newOne);
}

It is not possible to create instances of an abstract class.
I hope this example helps,
abstract class Vehicle
public static void main(String arg[])
Vehicle a;
a = new Automobile(); // ok, since Automobile is a kind of Vehicle
// The class Automobile, a special case of Vehicle
class Automobile extends Vehicle

Doubt on abstract classes

Similar Messages

Maybe you are looking for