Abstract classes, Interfaces, and concrete classes

I have another technical interview tomorrow and somehow I keep getting asked the same question and I feel my answer is not really up to par. The question is:
"What is the advantage of subclassing an abstract class versus concrete class?"
"What is the difference of using an interface versus an abstract class, which is better to use?"
For the first question, I usually answer performance is the advantage because you don't have to instantiate the class.
For the second question, I usually say that you can put implementation in an abstract class and you can't in an interface. I really can't answer the second part to this question.
Any ideas?

For the first question, I usually answer performance
is the advantage because you don't have to instantiate
the class. Try invoking the class B in the following somewhere in another class.
abstract class A{
   A(){
      System.out.println("abstract instantiated");
class B extends A{
  B(){super();}
}

Similar Messages

  • Whats the difference between an INTERFACE and a CLASS?

    Whats the difference between an INTERFACE and a CLASS?
    Please help.
    Thanx.

    http://search.java.sun.com/search/java/index.jsp?col=javaforums&qp=%2Bforum%3A31&qt=Difference+between+interface+and+class

  • Track public classes, interfaces and methods by ID

    Hi All,
    I'm wondering whether there is a tool to assign a unique ID to classes, interfaces and methods (eg. within Javadoc) and track these IDs.
    The reason I'd need such a feature is that I'd like to do requirements tracking in an easy but complete way. I have a document containing functional specifications (with IDs) and on the other side there is the source code; where the javadoc of the public methods and classes is my software specification. What I now want to do is make a link between the IDs in the functional spec to the IDs in the sofware spec (ie. the source code).
    Does anybody know of such a tool (commercial or not)?
    Thanks,
    Daniel

    I'm a bit confused as to whether or not I understand you correctly. Please tell me if the following pseudocode is somewhat like the solution you are looking for:
    class MethodFunctionality {
       private Class methodClass;
       private String methodSignature;
       private List methodFunctions;
        *   Returns true if the method is used for the specified
        *   requirement, false otherwise.
       public boolean fulfills(int requirementId) {
          if methodFunctions.contains(requirementId)
             return true;
          else
             return false;
       public String getMethodSignature() {
          return this.methodSingature;
       public Class getMethodClass() {
          return this.methodClass;
        *   Returns an array with IDs of each functional
        *   requirement covered by the method.
       public int[] getCoverage() {
          return this.methodFunctions;
    class ClassFunctionality {
       private Map methodDetails;
       private List classFunctions;
       public MethodFunctionality getMethodDetails(String methodSignature) {
          return (MethodFunctionality) this.methodDetails.get(methodSignature);
        *   Returns true if the class is used for the specified
        *   requirement, false otherwise.
       public boolean fulfills(int requirementId) {
          if classFunctions.contains(requirementId)
             return true;
          else
             return false;
        *   Returns an array with IDs of each functional
        *   requirement covered by the class.
       public int[] getCoverage() {
          return this.classFunctions;
    }Mapping classes and methods to functionality like this would both allow you to query each class and method for all the functional requirements they claim to cover and would allow you to collect all classes and methods involved for a particular functional requirement.

  • ATG-Client-Class-Path and ATG-Class-Path

    What is the difference between ATG-Client-Class-Path and ATG-Class-Path (defined in MANIFEST.MF)? Is it mandatory that these two should have same values all the time? If the values are different, where the application will behave differently?
    Thanks,
    Gopinath Ramasamy

    ATG-Class-Path specifies resources that a module requires and same are assembled in the EAR's lib folder when EAR is created using runAssembler. While ATG-Client-Class-Path mention those resources which are required for client side functionality (like ACC) of that module. If you don't specify this it would not affect your application anyways as EAR will be assembled from ATG-Class-Path. Please refer this for details and all the supported manifest attributes:
    http://docs.oracle.com/cd/E35318_01/Platform.10-1-1/ATGPlatformProgGuide/html/s0403applicationmodulemanifestfile01.html

  • Interface and Inner Class

    Hi,
    In interface we can't provide method body.
    but we can provide method body like this,
    public interface TestInterface {
         public class Add {
              public int add() {
                   return 100;
    what is the logic behind Inner Class inside interface.
    plz help.Thanks in advance.

    there isn't really any logic to it, it's just something that's semantically possible. there wasn't a conscious decision to allow this, it's just a by-product of the enclosing types mechanism, and while it wouldn't be a good idea to do this, there's no technical reason why it shouldn't be possible, either

  • Problem in generic value copier class / reflection and generic classes

    Hello experts,
    I try to archive the following and am struggling for quite some time now. Can someone please give an assessment if this is possible:
    I am trying to write a generic data copy method. It searches for all (parameterless) getter methods in the source object that have a corresponding setter method (with same name but prefixed by "set" instead of "get" and with exactly one parameter) in the destination object.
    For each pair I found I do the following: If the param of the setter type (T2) is assignable from the return type of the getter (T1), I just assign the value. If the types are not compatible, I want to instantiate a new instance of T2, assign it via the setter, and invoke copyData recursively on the object I get from the getter (as source) and the newly created instance (as destination). The assumption is here, that the occurring source and destination objects are incompatible but have matching getter and setter names and at the leaves of the object tree, the types of the getters and setters are compatible so that the recursion ends.
    The core of the problem I am struggling with is the step where I instantiate the new destination object. If T2 is a non-generic type, this is straightforward. However, imagine T1 and T2 are parametrized collections: T1 is List<T3> and T2 is List<T4>. Then I need special handling of the collection. I can easily iterate over the elements of the source List and get the types of the elements, but I can not instantiate only a generic version of the destinatino List. Further I cannot create elements of T4 and add it to the list of T2 and go into recursion, since the information that the inner type of the destination list is T4 is not available at run-time.
    public class Source {
       T1 getA();
       setA(T1 x);
    public class Dest {
       T2 getA();
       setA(T2 x);
    public class BeanDataCopier {
       public static void copyData(Object source, Object destination) {
          for (Method getterMethod : sourceGetterMethods) {
             ... // find matching getter and setter names
             Class sourceParamT = [class of return value of the getter];
             Class destParamT = [class of single param of the setter];
             // special handling for collections -  I could use some help here
             // if types are not compatible
             Object destParam = destination.getClass().newInstance();
             Object sourceParam = source.[invoke getter method];
             copyData(sourceParam, destParam);
    // usage of the method
    Souce s = new Source(); // this is an example, I do not know the type of s at copying time
    Dest d = new Dest(); // the same is true for d
    // initialize s in a complicated way (actually JAX-B does this)
    // copy values of s to d
    BeanDataCopier.copyData(s, d);
    // now d should have copied values from s Can you provide me with any alternative approaches to implement this "duck typing" behaviour on copying properties?
    Best regards,
    Patrik
    PS: You might have guessed my overall use case: I am sending an object tree over a web service. On the server side, the web service operation has a deeply nested object structure as the return type. On the client side, these resulting object tree has instances not of the original classes, but of client classes generated by axis. The original and generated classes are of different types but have the identically named getter and setter methods (which again have incompatible parameter types that however have consistent names). On the client side, I want to simply create an object of the original class and have the values of the client object (including the whole object tree) copied into it.
    Edited by: Patrik_Spiess on Sep 3, 2008 5:09 AM

    As I understand your use case this is already supported by Axis with beanMapping [http://ws.apache.org/axis/java/user-guide.html#EncodingYourBeansTheBeanSerializer]
    - Roy

  • Custom class loader and local class accessing local variable

    I have written my own class loader to solve a specific problem. It
    seemed to work very well, but then I started noticing strange errors in
    the log output. Here is an example. Some of the names are in Norwegian,
    but they are not important to this discussion. JavaNotis.Oppstart is the
    name of my class loader class.
    java.lang.ClassFormatError: JavaNotis/SendMeldingDialog$1 (Illegal
    variable name " val$indeks")
    at java.lang.ClassLoader.defineClass0(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:431)
    at JavaNotis.Oppstart.findClass(Oppstart.java:193)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
    at JavaNotis.SendMeldingDialog.init(SendMeldingDialog.java:78)
    at JavaNotis.SendMeldingDialog.<init>(SendMeldingDialog.java:54)
    at JavaNotis.Notistavle.sendMelding(Notistavle.java:542)
    at JavaNotis.Notistavle.access$900(Notistavle.java:59)
    at JavaNotis.Notistavle$27.actionPerformed(Notistavle.java:427)
    JavaNotis/SendMeldingDialog$1 is a local class in the method
    JavaNotis.SendMeldingDialog.init, and it's accessing a final local
    variable named indeks. The compiler automatically turns this into a
    variable in the inner class called val$indeks. But look at the error
    message, there is an extra space in front of the variable name.
    This error doesn't occur when I don't use my custom class loader and
    instead load the classes through the default class loader in the JVM.
    Here is my class loading code. Is there something wrong with it?
    Again some Norwegian words, but it should still be understandable I hope.
         protected Class findClass(String name) throws ClassNotFoundException
             byte[] b = loadClassData(name);
             return defineClass(name, b, 0, b.length);
         private byte[] loadClassData(String name) throws ClassNotFoundException
             ByteArrayOutputStream ut = null;
             InputStream inn = null;
             try
                 JarEntry klasse = arkiv.getJarEntry(name.replace('.', '/')
    + ".class");
                 if (klasse == null)
                    throw new ClassNotFoundException("Finner ikke klassen "
    + NOTISKLASSE);
                 inn = arkiv.getInputStream(klasse);
                 ut = new ByteArrayOutputStream(inn.available());
                 byte[] kode = new byte[4096];
                 int antall = inn.read(kode);
                 while (antall > 0)
                     ut.write(kode, 0, antall);
                     antall = inn.read(kode);
                 return ut.toByteArray();
             catch (IOException ioe)
                 throw new RuntimeException(ioe.getMessage());
             finally
                 try
                    if (inn != null)
                       inn.close();
                    if (ut != null)
                       ut.close();
                 catch (IOException ioe)
         }I hope somebody can help. :-)
    Regards,
    Knut St�re

    I'm not quite sure how Java handles local classes defined within a method, but from this example it seems as if the local class isn't loaded until it is actually needed, that is when the method is called, which seems like a good thing to me.
    The parent class is already loaded as you can see. It is the loading of the inner class that fails.
    But maybe there is something I've forgotten in my loading code? I know in the "early days" you had to do a lot more to load a class, but I think all that is taken care of by the superclass of my classloader now. All I have to do is provide the raw data of the class. Isn't it so?

  • Processing classes, cumulations, and evaluation classes for Surcharge

    Hi Experts,
    As I am working on Indian payroll in form 24Q the surcharge is not calculating properly it is displaying the TDS amount.
    and in surcharge column of form 16 is appearing total Taxable amount.
    Can any body send the nessessary sreen shots of process, cumulations and evaluation classes for the surcharge wage type.
    Thanks in advance
    Regards
    Srinivas

    solved thanks

  • Abstract class, Interface and two models issue

    Hi!
    I will post my code and then ask the question (text between code snippets is bold, so you don't miss it, it's not shouting):
    public class AppScreen extends JFrame
                           implements ActionListener {
      private MemoryTableModel model;
      public AppScreen() {
        this.model = new MemoryTableModel();
           //code
      public void actionPerformed(ActionEvent actEvt) {
          if(table.getSelectedRow() != -1) {
            model.deleteRow(table.getSelectedRow());
          else {
            ErrDialog.noRowErr();
      public MemoryTableModel getModel() {
        return model;
    public class MemoryTableModel extends BasicTableModel
                                  implements MemoryTableInterface {
      public MemoryTableModel() {
        //code
      public synchronized void insertRow(String file, String time) {
        //code
      public synchronized void editRow(int selectedRow, String file, String time) {
        //code
    public synchronized void deleteRow(int selectedRow) {
        //code
    public abstract class BasicTableModel extends AbstractTableModel {
      private final String FILE_COLUMN = "Executable file";
      private final String TIME_COLUMN = "Time";
      protected String[] columnNames   = new String[2];
      protected List<RowRecord> data   = new ArrayList<RowRecord>();
      BasicTableModel() {
        //code
      public int getColumnCount() {
        //code
      public int getRowCount() {
        //code
      public String getValueAt(int row, int col) {
        //code
      public Class<? extends String> getColumnClass(int c) {
        //code
      public String getColumnName(int col) {
        //code
      public List<RowRecord> getData() {
        //code
      public int getTimeColumn() {
        //code
      public int getFileColumn() {
        //code
    public interface MemoryTableInterface {
      public void insertRow(String file, String time);
      public void editRow(int selectedRow, String file, String time);
      public void deleteRow(int selectedRow);
    In this form, everything works fine. But now, I would like to choose between two models at the start, so I thought I would do this:
    public class AppScreen extends JFrame
                           implements ActionListener {
      private BasicTableModel model;
      public AppScreen() {
        if(...) {
          this.model = new MemoryTableModel();
        else {
          this.model = new JDBCTableModel();
    public void actionPerformed(ActionEvent actEvt) {
          if(table.getSelectedRow() != -1) {
            model.deleteRow(table.getSelectedRow());
          else {
            ErrDialog.noRowErr();
      public BasicTableModel getModel() {
        return model;
    public class JDBCTableModel extends BasicTableModel
                                implements JDBCTableInterface {
      public JDBCTableModel(Connection conn)
        throws ClassNotFoundException, SQLException {
        //code
      public void insertRow(String file, String time) throws SQLException {
        //code
      public void editRow(int selectedRow, String newFile, String newTime)
          throws SQLException {
        //code
      public void deleteRow(int selectedRow) throws SQLException {
        //code
    public interface JDBCTableInterface {
      public void insertRow(String file, String time) throws SQLException;
      public void editRow(int selectedRow, String file, String time)
          throws SQLException;
      public void deleteRow(int selectedRow) throws SQLException;
    }But I'm getting error message from AppScreen that method deleteRow(int) is undefined for the type BasicTableModel. I thought if I initialize variable model as some implementation of BasicTableModel, it will be OK. Apparently it's not, so:
    where and what am I missing or
    how can I realize this choosing between two models so I don't have to write "if(model == MemoryModel) else if(model == JDBCModel)" around every method where I have to decide.
    Thanks!

    I would like to have issues interfacing with two classy models, as well. ;-)
    You need to have your BasicTobleModel class implement your JDBCTableInterface interface (even if it doesn't implement those methods itself), if that is how you intend to use that class.
    Edit: Too slow.

  • Question about throws exception in interface and realized class

    Hi,all
    If I define a method In the interface like that-
    public void Execute() throws NumberFormatException; In the realized class, I can define this method like that-
    public void Execute() throws RuntimeException{
            System.out.println("test");       
    }This is a right realization. But if I manage it to throws Exception or to throws Throwable in the class it leads a error. Why add this restrict only to Exception? What is the purpose of this way?
    Greetings and thanks,
    Jason

    When you say "throws NumberFormatException" you are really saying:
    When using classes implementing this interface, you have to be prepared to deal with them throwing a NumberFormatException. Other exceptions won't happen.
    When you come to implement it, it might not be possible for it to throw a NumberFormatException, so there's no reason why you should have to lie about that. Code handling it directly will be fine (it doesn't throw a NFE) and code handling it via the interface will be fine (it will handle NFEs, they just don't happen).
    If your concrete implementation throws other sorts of exception, such as Exception or IOException, and so on, it's incompatible with code that's manipulating the interface. The interface says "NFEs might get thrown, nothing else will." while your implementation says "IOExceptions might get thrown".
    So that explains why you can't use arbitrary exceptions. The special case is RuntimeException. RuntimeExceptions don't have to be caught, and it's expected that they can happen at any time - so there's no point trying to catch and handle them as a general case.
    The classic example of a RuntimeException is a NullPointerException. You don't need to declare your method as throwing a NullPointerException even though it might get thrown. And you don't have to add NullPointerException to the throws part of the interface definition, because you already know that the concrete implementation could throw a NPE at any time.
    Hope that helps (a little).
    I'd recommend reading the API documentation on RuntimeException and Exception to get a clearer insight into this.
    Dave.

  • Extending interfaces and xtending classes

    Hello there,
    I've extended an interface from two interfaces like this:
    interface1 extends interface2, interface3
    and although the compiler doesn't seem to mind, I'm not sure
    whether this is really correct. With classes this is not possible
    and I would need to implement multiple interfaces, but then how
    would I deal with a collection of objects which I would like to
    be of type interface1?
    Many thanks

    Here's a link that explains it in more detail:
    [url
    http://forum.java.sun.com/post.jsp?forum=31&thread=3800
    &message=1625659&reply=true&doPost=true&subject=April
    Fools:)&body=Fooled You]Interfacesoopps, should be:
    [url http://forum.java.sun.com/post.jsp?forum=31&thread=38004&message=1625659&reply=true&doPost=true&subject=YoGee Fooled You:)&body=Fooled You]Interfaces

  • Error Message like Illegal Start of Type,and Class interface and enum expec

    import java.applet.*;
    import java.awt.*;
    //Inheriting the Applet class with firstApplet class
    public class firstApplet extends Applet{
         private Button reset,submit;
         private TextArea addr;
         private TextField name,addr,sex,mar;
         Panel p=new Panel();
         Choice m_choice = new Choice();
         Label namel=new Label("Name");
         Label addrl=new Label("Address");
         Label sexl=new Label("Sex");
         Label marl=new Label("Maital");
         //In it function
    public void init()
         setLayout(new FlowLayout());
         add(m_choice);
         m_choice.addItem("Select Mode");
         m_choice.addItem("Create");
         m_choice.addItem("Edit");
         m_choice.addItem("Delete");
         m_choice.addItem("Search");
         add(namel);
         name=new TextField(20);
         add(name);
         add(addrl);
         addr=new TextArea(5,20);
         add(addr);
         add(sexl);
         sex=new TextField(10);
         add(sex);
         add(marl);
         mar=new TextField(20);
         add(mar);
         submit =new Button("Submit");
         add(submit);
         reset =new Button("Reset");
         add(reset);
         t=new TextField(30);
         add(t);
    public boolean action(Event e,Object o){
         if (e.target instanceof Button){
                   String s= (String)o;
                   if(s.equals ("Submit"))
                        t.setText("Error Occured While Saving to the database");
                   else if (s.equals("Reset")){
                        name.setText("");
                        addr.setText("");
                        sex.setText("");
                        mar.setText("");
                        t.setText("");}
                   return true;
         else
              return false;
    }I this program while compiling i am getting the above specified.This is the Code i used.At that Bolded else and return false lines are showing as error lines.Why this error is coming?Pls send help me with some hint,Because i am new to Java.

    Be consistent about your placement of {} and use of indentation. Sun's code
    conventions provide an example: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

  • Mixing generic and concrete classes

    I am going over the generics tutorial by Gilad Bracha offered by Sun. Something strikes me as wrong
    Collection c;
    Collection<Part> k = c; //compile-time unchecked warning
    Collection<Part> k = (Collection<Part>) c; //compile-time unchecked warningFor me, the first unchecked warning is mildly acceptable, but my honest opinion is it should be an error not a warning. Isint this effectively an automatic narrowing cast? I personally like my cases to be inside of (), and not hidden. I could be wrong.
    The second unchecked warning however should not even be given. If the 2nd warning is acceptable, then why not flag all casts as 'unchecked warnings?'
    I have a feeling this has to do with this 'erasure' stuff and the resultant class files. I would appreciate any light you could shed on this for me.

    Well Java is really a hobby for me and i end up doing other stuff for several months at a time. And now I am back into Java. I'm finding that I usually do it in the fall and winter, strange..
    Plus 1.5 is so exciting, I'm like a baby all over again with so much to learn!
    I am learning that generics is all compile-time, so I kind of understand that there is really no such thing as casting a generic type. Or that it makes no sense since casting and generics live in different "times" for lack of a better term.
    I think i get it. The second would give the false impression that a cast is actually taking place, and would thus pollute the notion of casting with this fake cast. And the first is not a warning about that line in particular, but a warning about the fact that you are taking your type-safety into your own hands when you subvert the system in this fashion. Which also applies to the second. In fact the cast is immaterial.
    OK, I see now how they are the same thing. But why is generic casting even allowed if its meaningless?

  • 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                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         

  • Inheritance, abstract and concrete

    Given:
    *abstract public class Foo {
    * protected static int bat;
    * public static int bat() {
    * return bat;
    *public class Bar extends Foo {
    * private static int bat = 5;
    Assuming that you have complete rewrite power over both classes, is there any way to have a situation where:
    * Foo f = new Bar();
    * int x = f.bat();
    will set x == 5 without putting an identical
    * public static int bat() {
    * return bat;
    in every single class that extends Foo?

    It's a complicated situation. I have a large number
    of user-defined classes that are all being stored
    together. I want to be able to pass them to the same
    functions, so I don't have to rewrite the functions a
    dozen times with only the variable class changing, so
    I defined them all as extensions of one abstract
    class, but I also need to be able to tell them apart
    when I need to handle them differently. It seemed to
    me that the best way to do that was by giving each
    different concrete class a distinct id number, that
    the handler can use in the rare cases when it's
    needed. I thought the id should be declared static
    because it belongs to the class, not to individual
    instances of the class. But I want to keep it
    private, so nobody can mess with it, so I also need a
    public function to return it. And since it works
    with a static value, it has to be declared as a
    static function.This sounds wrong.
    If they are user defined classes then it is not possible for you to tell them apart.
    Or your terminology means something different.
    If you are writing a plug in engine where something is added later, then the engine can no rely on anything specific about the plug ins. If it does, they are not plug ins.
    If you need to handle them differently with some common categories of functionality then you should be using interfaces and helper classes.
    Pseudo code would be like this...
          interface CommonStuff
                String getName();
         interface Communications
               boolean sendInfo();
         interface Storage
               boolean storeIt();
        class PlugInEngine
             void process(Object o)
                    if (o instanceof Communications)
                          ((Communications)o).sendInfo();
                    if (o instanceof Storage)
                          ((Communications)o).storeIt();
                    if (o instanceof CommonStuff)
                          log("Finished name=" + ((CommonStuff)o).getName());
        }

Maybe you are looking for