Abstract Class Polymorphism?
I want to be able to add any of my sub classes to a collection (hash set) , without duplicating the code. The superclass for all these subclasses is an abstract class.
Is there a possible way of achieving this?
At the moment I have methods for each individual class; before making the parent class abstract, I could use the same method for all, but was advised as I did not want an instance of that parent class, the abstract class was best.
Hope this is not too vague or abstract... :)
I think if you use the wildcard symbol it'll allow you to add a covariant to the collection, for example
public static void addSub(List<? super NameofSuperClass> varName)
When you can to retrieve the data, if you want any methods not in the super class you would still be to cast it.
Is this what you meant? - Peter sorry if it wasn't helpful
Similar Messages
-
Interfaces, Abstract Classes & Polymorphism
I have a friend taking a Java course as part of a larger degree program, and she's asked for some help with an assignment. The assignment is as follows:
This assignment is to write a simple encryption/decryption application. There will be a single application
that the user can use to encrypt or decrypt a phrase passed in on the command line, with the user deciding
which encryption/decryption scheme to use.
The first scheme is to add 1 to each character that is in the phrase, the other is to subtract 1 from each
character that is in the phrase.
To encrypt, you must be able to use the follwing syntax:
java Crypto encrypt Additive "hello"
Output:
"hello" encrypts to: "ifmmmp"
To decrypt:
java ca.bcit.cst.comp2256.a###### decrypt Additive "ifmmp"
Output:
"ifmmp" decrypts to: "hello"
Use Additive or Subtractive as the arguments to choose which encryption/decryption to
use. The problem is, I'm not entirely sure how to use abstract classes and interfaces to do what is being asked. I'm pretty sure I could do the whole program in a single for-loop, but apparently her teacher doesn't want people coming up with their own solutions for the problem. I don't need any code for how to do it, per se, I'm just wondering how one would structure a program like that to include interfaces, polymorphism and abstract classes.
Anyone have any ideas?with the user deciding which encryption/decryption scheme to use.This is the key sentence. encryption/decryption can be done using multiple schemes. The contract for any given scheme can be defined using
public String encrypt(String input);
public String decrypt(String input);There can be multiple implementations for these methods, one set for each scheme.
The contract therefore becomes the interface and each implementation is a concrete implementation of this interface.
The problem doesn't delve deep into the kind of schemes available. If it does and there is a significant overlap between 2 schemes, an abstract class that takes care of the shared logic among 2 schemes comes into picture.
Hope this helps! -
Abstract Class and polymorphism - class diagram
Hi,
]Im trying to draw a class diagram for my overall system but im not too sure how to deal with classes derived from abstract classes. I'll explain my problem using the classic shape inheritance senario...
myClass has a member of type Shape, but when the program is running shape gets instantiated to a circle, square or triangle for example -
Shape s = new circle();
since they are shapes. But at no stage is the class Shape instantiated.
I then call things like s.Area();
On my class diagram should there be any lines going from myClass directly to circle or triangle, or should a line just be joining myClass to Shape class?
BTW - is s.Area() polymorphism?
Thanks,
Conor.Sorry, my drawing did not display very well.
If you have MyClass, and it has a class variable of type Shape, and the class is responsible for creating MyClass, use Composition on your UML diagram to link Shape and MyClass.
If you have MyClass, and it has a class variable of type Shape, and the class is created elsewhere, use Aggregation on your UML diagram to link Shape and MyClass.
If you have MyClass, and it is used in method signatures, but it is not a class variable, use Depedency on your UML diagram to link Shape and MyClass. The arrow will point to Shape.
Shape and instances of Circle, Triangle, Square, etc. will be linked using a Generalization on your UML diagram. The arrow will always point to Shape.
Anything that is abstract (class, method, variable, etc.) should be italicized. Concrete items (same list) should be formatted normally.
BTW, the distinction between Composition, Aggregation and Dependency will vary from project to project or class to class. It's a gray area. Just be consistent or follow whatever guidelines have been established.
- Saish -
Mixing polymorphism with abstract classes???
Hi,
Can you have polymorhism with abstract superclasses in Java?
For example, say I have a superclass called Pet:
abstract class Pet {
private String name;
public String getName() {
return name;
public void setName(String petName) {
name = petName;
public String speak() {
return "I am a Pet";
}Now I have a Cat subclass:
public class Cat extends Pet{
public String speak {
return "i am a cat";
public class Dog extends Pet {
public String fetch() {
return "fetching a stick";
}In my test method I have:
public class TestPet {
public static void main(String[] args) {
Pet p = new Pet();
System.out.println(p.speak());
Pet p = new Dog();
System.out.println(((Dog)p).fetch());
Pet p = new Cat();
System.out.println(p.speak() +" is now a cat");
}So it appears to me that you cannot have polymorphic methods with an abstract superclass - is this right?
Cheers.cotton.m wrote:
List<Pet> pets = new ArrayList<Pet>();
I was working (more or less) along the same lines...
package forums;
import java.util.List;
import java.util.ArrayList;
abstract class Pet
private String name;
public String getName() { return this.name; }
public void setName(String name) { this.name = name; }
public String speak() {
return "I am a Pet";
public abstract String fetch(); // <<<<< the new bit.
public String getClassName() {
final String name = this.getClass().getName();
return name.substring(name.lastIndexOf('.')+1).toLowerCase();
class Cat extends Pet
public Cat(String name) {
setName(name);
public String speak() {
return "I am a cat";
public String fetch() {
return "No. I am a cat!";
public String rollOver() {
return "No. I am a cat!";
class Dog extends Pet
public Dog(String name) {
setName(name);
public String fetch() {
return "Look boss, I'm fetching the stick.";
public String sit() {
return "Look boss, I'm sitting!";
public class PetTest
public static void main(String[] args) {
List<Pet> pets = new ArrayList<Pet>();
pets.add(new Cat("Fungus"));
pets.add(new Dog("Spike"));
for ( Pet pet : pets ) {
System.out.println("\""+pet.speak()+"\" said "+pet.getName()+" the "+pet.getClassName()+".");
System.out.println("\"Go fetch\" said the master.");
System.out.println("\""+pet.fetch()+"\" said "+pet.getName()+".");
System.out.println();
System.out.println("Therefore we conclude that dogs are much better pets.");
}Both these examples demonstrate that polymorphism is very useful when we have a list of different-type-if-things which have a common interface... i.e. different classes which have (a) a common ancestor; or (b) a common interface... allowing us to treat those different types-of-things as if they where one-type-of-thing, except the-different-types actually do different stuff internally, which is appropriate-to-there-specific-type.
That's the essence of polymorphism... and, of course, this seperation of "type" and "implementation" isn't limited to lists-of-stuff... it can be very useful all over the show.
Cheers. Keith.
Edited by: corlettk on 10/05/2009 11:01 ~~ That's a bit clearer. -
Abstract class method polymorphically using constructors?
how can i have a method defined in an abstract superclass call a constructor of the actual class running the method?
abstract class A {
public List getMultple() {
List l = new ArrayList();
for (short i=0;i<4;i++) {
l.add(this());//<obviously this breaks
return l
or something like that. A won't run this method, but its children will...and they can call their constructors, but what do i put here to do that?
i've tried a call back. an abstract method getOne() in the superclass forces each child to define that method and in each of those i return the results of a constructor. that works fine.
the problem is i want to abstract this method out of each of these children classes cause its the exact same in each one, just using a different constructor to get multiple of each in a list. so if i use this callback method, then i am not saving the number of methods in each class, so why bother at all?
any ideas?I still say you are coming at it from the wrong angle. A super class is not the way to go. What you are doing sounds like something very similar to something I did not too long ago.
My requirement was that I had tab delimited text files filed with data that I had to parse. Each line would be used to instantiate one object, so a particular file could be used to instantiate, for example, a thousand objects of the same class. There were different types of files corresponding to different classes to instantiate instances of.
Here is the design I ended up using.
An object of class DataTextFileReader is instantiated to parse the text file and generate objects. It includes code for going line by line, handling bad lines and generating objects and reports. The constructor:
public DataTextFileReader(File inputFile, LineParser<T> theLineParser)LineParser is an interface with one method:
public T read(String line);When you call a load() method of the DataTextFileReader, it does its thing with the aid of the LineParser's read method, to which each line is passed, and stores the generated objects in an ArrayList. This can be returned by using another method. There are other methods for getting the reports, etc.
Obviously, the LineParser chosen needs to have code appropriate for parsing the lines in question, so you have to choose and instantiate the right one.
I find this design to work well. I arrived at it after spending hours giving myself headaches trying to come up with a design where there was a superclass roughly equivalent to the DataTextFileReader mentioned above, and classes extending this that fulfilled the duty of the LineParsers mentioned above... rather like what you are trying to do now.
I did not care for the solution at first because it did not give me the "Ah, I am clever!" sensation I was expecting when I finally cracked the problem using inheritance, but I quickly came to think that it was much better OOD anyway.
The LineParsers mentioned above are essentially embodiments of the Factory pattern, and I would recommend you do something similar in your case. Obviously your "constructors" all have to be different, so you should make a separate class for each of those. Then you can put the code that performs the query and loops to create loads of objects in another class called something like DatabaseDepopulator, using appropriate generics as in my example. Really it is the same problem, now that I look at it.
This will also result in better separation of concepts, if you ask me. Why should the class constructor know how to parse a database result query, much less perform the query? It has nothing to do with databases (I presume). That is the job of an interpreter object.
As a final note, remember... 95% of the time you feel like the language won't let you do what you want, it is because you shouldn't anyway.
Drake -
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. -
Concept of Abstraction and Polymorphism
Hi friends,
I'm just new to Java.I studied a little bit of C, I'm currently studing VB and Java.
There are one or two concepts in Java that are very hard to grasp for me.
The first is abstraction and the second is polymorphism.
Can anybody outline to me in simple words(use simple example if needed)what those 2 concepts are all about?
Thanks a lot
MarcoIn your example, you could make Vehicle an abstract
class. You can't simply have a vehicle, but you can
have a car which IS a vehicle. In your abstract class
Vehicle, you might define an abstract method public
int getSeats() (you want it to be abstract because it
changes from one type of vehicle to the next). So the
class Car extends Vehicle, overrides the method
getSeats() and returns 5. The class Ute extends
Vehicle, overrides the method getSeats() and returns 2
(you might make a SuperCabUte that extends Ute and
returns 5, or whatever).Radish is right,
Think of it as modelling of real life. You would generalise the description of your car as a Vehicle (abstraction, which can be implemented as an interface in Java) where in fact you own a car
Similarly you can have an inteface called RealEstate where in fact you own a TwoStoreyHouse ( a class that implements the RealEstate interface)
the interface can describe the general 'characterstics' of real estate properties ie land size, council rates etc.
HTH...hey.... -
Can anyone please tell me as to why we need both an abstract class & an interface? I was asked in an interview as to why we need 2 separate concepts when we can get the similar functionality of an interface by using an abstract class. I had just sited their differences like:
1) An abstract class can have both abstract & normal methods & that we can specify different access specifiers for its class members.
2) ABAP does not support Multiple inheritance but that we could simulate the same using interfaces concept in ABAP.
But he wasnt satisfied with the answer. I guess he was expecting something from a practical point of view. I did try searching the old threads but there wasnt anything similar to this. Anyone please explain by citing a scenario as to why we would need 2 separate concepts & not just one .
Thanks in advanceHi
Abstract classes
Abstract classes are normally used as an incomplete blueprint for concrete (that is, non-abstract) subclasses, for example to define a uniform interface.
Classes with at least one abstract method are themselves abstract.
Static methods and constructors cannot be abstract.
You can specify the class of the instance to be created explicitly: CREATE OBJECT <RefToAbstractClass> TYPE <NonAbstractSubclassName>.
Abstarct classes themselves cant be instantiated ( althrough their subclasses can)
Reference to abstract classes can refer to instance of subclass
Abstract (instance) methods are difined in the class , but not implemented
They must be redefined in subclasses
CLASS LC1 DEFINAITION ABSTARCT
PUBLIC SECTION
METHODS ESTIMATE ABSTARCT IMPORTING
ENDCLASS.
<b>Interfaces</b>
Interfaces only describe the external point of contact of a class (protocols), they do not contain any implementation.
Interfaces are usually defined by a user. The user describes in the interface which services (technical and semantic) it needs in order to carry out a task.
The user never actually knows the providers of these services, but communicates with them through the interface.
In this way the user is protected from actual implementations and can work in the same way with different classes/objects, as long as they provide the services required. This is known as polymorphism with interfaces. -
I'm confused. Is this true or false.
The great thing about polymorphism is that you can call one method. If the subclass inherited that method, it will be customized and perform a different duty. That way, the action it performs will depend on 1>whether or not it's a sub or super class and also 2>if the method was overridden if it was a subclass.
Now, my confusion. If an object reference is to a Super-abstract-class... how do the method calls and properties go?? well let me let you answer for me. Thanks so much in advance for this clarification.Yes. You are - pretty much.
The abstract class, as such, can never be instantiated. BUT a class derived from the superclass IS an instance of the superclass.
Silly example:
abstract public class Animal {
public Animal() {
public abstract int getNumberOfLegs();
}That's our animal class, and we know that anything that's an animal has a number of legs - but we can't just create a "generic" animal.
public class Cat extends Animal {
public Cat() {
super();
public int getNumberOfLegs() {
return legCount;
public void maim(int legsToRemove) {
legCount -= legsToRemove;
if(legCount < 0 ) legCount = 0;
private int legCount = 4;
}A Cat is a specific type of animal, so we can find out how many legs it has (usually 4). Note again that a cat IS an animal, so Cat IS an instance of Animal.
Java even provides a special operator to test this:
Cat cat = new Cat();
System.out.println("A cat is a cat: " + (cat instanceof Cat));
System.out.println("A cat is an animal: " + (cat instanceof Animal));The term used to describe the "Guarantee" that a subclass of an abstract class (or an implementation of an interface) is usually and technically a "contract", but I prefer to think of it as a "Promise" since you can break the promise by messing with the bytecode - at which point the JVM will spot the lie and complain !
D. -
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
SantoshIn 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 -
Abstract classes and inheritance
I'm trying to do some simple inheritance but I'm a little stuck. Without giving too much away here's what I have (or am trying to have). I have an abstract "Test" class and a number of concrete classes that extend that abstract class. In my main method I have an array of Test objects. Each object in the array is a certain kind of "Test" and each one has its own way of doing most things but it doesn't make sense to have just a plain Test object because it is an abstraction. In my code I go through the array and execute a method, runTest(), for each Test in the array. However, my abstract Test class doesn't have a runTest() method b/c it will never get used and java complains. At runtime shouldn't java figure out, OK this is TestA, so go to TestA's runTest method (polymorphism?). What should I put in my runTest method in the abstract class? I know I can put anything there but what is standard?
JFactor2004 wrote:
... Each object in the array is a certain kind of "Test" and each one has its own way of doing most things but it doesn't make sense to have just a plain Test object because it is an abstraction. In my code I go through the array and execute a method, runTest(), for each Test in the array. However, my abstract Test class doesn't have a runTest() method b/c it will never get used and java complains. If you want to instantiate the Test class
you need to provide an implementation for the runTest() method,
something like/*type*/ runTest() { throw new UnsupportedOperationException(); } -
Abstract class reference itself
How do I reference an abstract class to itself.
public abstract class SomeClass {
public static SomeType SomeMethod(){
SomeClass mine = new SomeClass();
}It gives me an error saying it can not instantiate the class.Possible source of confusion: you can declare a variable of type abstract class and assign it an object of a derived class that fully implements the abstract class. For instance:
abstract class SomeClass
public static void SomeMethod(){}
public abstract void greeting();
class AnotherClass extends SomeClass
public void greeting()
System.out.println("hello");
public class DemoAbstractClasses
public static void main(String args[])
SomeClass A = new AnotherClass(); // A's type is an abstract class
A.greeting(); //polymorphism
} -
Diffrence between a Interface and a abstract class?
Hi OO ABAP Gurus
Please clear below point to me.
Diffrence between a Interface and a abstract class?
Many thanks
Sandeep Sharma..Hi
Abstract classes
Abstract classes are normally used as an incomplete blueprint for concrete (that is, non-abstract) subclasses, for example to define a uniform interface.
Classes with at least one abstract method are themselves abstract.
Static methods and constructors cannot be abstract.
You can specify the class of the instance to be created explicitly: CREATE OBJECT <RefToAbstractClass> TYPE <NonAbstractSubclassName>.
Abstarct classes themselves cant be instantiated ( althrough their subclasses can)
Reference to abstract classes can refer to instance of subclass
Abstract (instance) methods are difined in the class , but not implemented
They must be redefined in subclasses
CLASS LC1 DEFINAITION ABSTARCT
PUBLIC SECTION
METHODS ESTIMATE ABSTARCT IMPORTING
ENDCLASS.
Interfaces
Interfaces only describe the external point of contact of a class (protocols), they do not contain any implementation.
Interfaces are usually defined by a user. The user describes in the interface which services (technical and semantic) it needs in order to carry out a task.
The user never actually knows the providers of these services, but communicates with them through the interface.
In this way the user is protected from actual implementations and can work in the same way with different classes/objects, as long as they provide the services required. This is known as polymorphism with interfaces.
Interfaces features
INTERFACE I_COUNTER.
METHODS: SET_COUNTER IMPORTING VALUE(SET_VALUE) TYPE I, INCREMENT_COUNTER, ENDINTERFACE.
CLASS C_COUNTER1 DEFINITION. PUBLIC SECTION.
INTERFACES I_COUNTER.
PRIVATE SECTION.
DATA COUNT TYPE I.
ENDCLASS.
CLASS C_COUNTER1 IMPLEMENTATION.
METHOD I_COUNTER~SET_COUNTER.
COUNT = SET_VALUE.
ENDMETHOD.
METHOD I_COUNTER~INCREMENT_COUNTER.
ADD 1 TO COUNT.
ENDMETHOD.
ENDCLASS.
Refer
https://forums.sdn.sap.com/click.jspa?searchID=10535251&messageID=2902116
Regards
Kiran -
Purpose/Advantage of Abstract Class
Hi,
I'm aware of the functionality of the Abstract class.
But what is the purpose or advantage of using it. Where ever we are using an Abstract class, we can replace it with a normal class & achieve the same functionality. Is there any scenario like only Abstract class can be used?
Thanks & Regards,
Adithya M.By using the Abstract class, we achieve the Polymorphism. Polymorphism simplifies the binding of the objects. By using the abstract class as the reference as object definition time, we can easily replace it with the concrete object at the runtime. This is called as the Dynamic Binding.
When we use the dynamic binding, the caller or the user of the object doesn't need to worry of what type of object is being passed to it at design time. At runtime the object would be assigned to it.
You can achieve the same Polymorphism and Dynamic binding using the interfaces, too. But the advantage using the Abstract class is, you could have the implementation of the non-abstract methods of the class where as Interface would only define the object. This non-abstract methods could contain the common logic which is valid for both Super class and Subclass.
Regards,
Naimesh Patel -
Help abstract classes linked list
I have a base abstract class Vegetable which is basically Node for a linkedlist
The base class Vegetable has a few abstract methods Pumpkin, Carrot, Potato basically extends Vegetable
Another class called VegetableCollection
basically in VegetableCollection
can this be done if the objects are different types eg Pumpkin, potato, Carrot?
public void add(Vegetable addObject)
head = new Vegetable(addObject);
}I have a base abstract class Vegetable which is basically Node for a linkedlist
The base class Vegetable has a few abstract methods Pumpkin, Carrot, PotatoYou probably wouldn't have abstract methods with those names. Abstract methods are methods that you will need to define in every subclass. And a subclass called Pumpkin probably won't have meaningful definitions for methods called Carrot and Potato.
can this be done if the objects are different types eg Pumpkin, potato, Carrot?
public void add(Vegetable addObject)
head = new Vegetable(addObject);
}Here is an example of "polymorphism" at work:
import java.util.*;
abstract class Vegetable
public abstract void identify();
class Carrot extends Vegetable
public void identify()
System.out.println("I'm a Carrot.");
class Pumpkin extends Vegetable
public void identify()
System.out.println("I'm a Pumpkin.");
public class Test
public static void main(String args[])
LinkedList<Vegetable> myVegetables = new LinkedList<Vegetable>();
myVegetables.add(new Carrot());
myVegetables.add(new Pumpkin());
Iterator<Vegetable> i = myVegetables.iterator();
Vegetable v = null;
while(i.hasNext())
v = i.next();
v.identify();
output:
I'm a Carrot.
I'm a Pumpkin.To get polymorphism to work, you need to:
1) Define a base class with a method that you want in all the subclasses.
2) Override the method in the subclasses so that it does what's necessary for that subclass.
3) Store the subclass objects in a variable(or collection) whose type is the base class.
4) Call the method on the base type variable. Then through the magic of polymorphism, java will examine the actual object stored in the base type variable to determine what subclass it is, and then java will call the version of the method in that subclass.
As the previous poster mentioned, you need to define a class called Node, which has head, previous, and next members. Your Node class will also have a member variable called veggie, which will be of type Vegetable. Then you can assign a Carrot, Pumpkin, or Potato object to that member variable.
I assume this is an exercise where you have to create your own linked list. Otherwise, you can use the linked lists provided by java, which are very easy to use.
Maybe you are looking for
-
imovie shuts down my imac during the creating movie and burning process
-
Doubts in entering Challan details thorough text file....
Hi Experts... When im trying to put the data in excel sheet which it has to be imported in f16 ,here im confused with the payroll period. The paydate and the date of deduction are showing as 20070526.For this period what is the payroll period. Which
-
ComboBox1 populates ComboBox2, then populates ComboBox3
I want to use combo box for Date of Birth, as I want to make sure the users will not enter invalid date. So I used the setItems function and followed the instructions in the thread here http://forums.adobe.com/message/3014009#3014009. Everything work
-
I got a new phone and did the "restore from iCloud backup" and now none of my new stuff can sync to iCloud due to amount of storage. Is there anything I can do besides buying more memory? I had a gb or 2 left prior to getting the new phone
-
I have now been on hold for over an hour and twenty minutes. This is the fourth call for the same problem....Photoshop CS4 will not install on a new MacPro. To see Adobes customer/tech support decline from exemplary to pathetic is astounding. Sorry A