Method signature (Chapter : Abstract class and Polymorphism)

Hi all,
I found some quaint thing about signature method. It's said: "A child class may define additional methods with signatures different from the parent's method." but
"It is an error if a child defines a method with the same signature as a parent method, but with a different return type."
The thing is: return type is not belong to method's signature !!!
Can someone explain this point?
Thanks and have a nice day ( 11:00 am in Germany)
H.A

"It is an error if a child defines a method with the
same signature as a parent method, but with a
different return type."
The thing is: return type is not belong to method's
signature !!!
Can someone explain this point?Yes.
Even though return type isn't part of the "signature" (as the JLS defines "signature"), the JLS requires that child methods with the same signature as parent classes have the same return type.
Think about it for a minute: Return type isn't part of the signature, but it is part of the contract. If Parent has public Whatsit foo() then it's promising that every instance of Parent, AND every instance of any Child that is a subclass of Parent (since a Child also IS A Parent), will have that method, and callers of that method will receive a Whatsit as a return value.
If I try to override it in Child with public Doobley foo() then a call might try to do this: Parent parent = factory.createParent(); // happens to return a Child, which is allowed, because a Child is a Parent
Whatsit w = parent.foo(); // OH NO! We got bad a Doobley instead of a Watsit! See the problem?
Now, it turns out that 1.5 adds covariant return types, which allows a child method to return a subtype of what the parent returns. So the above would work IFF Doobley is a subclass or subinterface of Whatsis, or is a class that implements Whatsis. This works because the child is still keeping the parent's contract. He's just actually promising a bit more than what the parent promises.

Similar Messages

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

Method inheritence from abstract classes, and arguments

I'm trying to do something a little weird. I'm writing a pretty complicated wrapper/adapter for two platforms, and I'd like to have an abstract method passed on to child classes, but with the type of the single argument specified by the child class. Is this possible?
Example
public abstract class AbstractParent {
public abstract void foo([ambiguousType] arg);
public class ChildOne extends AbstractParent {
public void foo(TypeA arg) {
//body
public class ChildTwo extends AbstractParent {
public void foo(TypeB arg) {
//body
}TypeA and TypeB have no common supertype beyond Object, and I'd rather not just do instanceof checks and throw errors. Does anyone know of a solution? Can I elaborate any better?

Perhaps you could use generics?
    public abstract class AbstractParent<E> {
        public abstract void foo(E arg);
    public abstract class ChildOne extends AbstractParent<String> {
        public void foo(String arg) {
    public abstract class ChildTwo extends AbstractParent<Integer> {
        public void foo(Integer arg) {
    }

Difference between abstract class and the normal class

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

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

ABSTRACT class and method

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

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

Abstract Classes and Method

Hi all,
I want to appear for SCJP exam and studying for the same ,
Can anyone tell whether concrete methods in an abstract class can be overridden by its subclass or not ... ???
Thanks in advance ,
Suvo

Hai
Actually the overridden concept is supported when the methods are default, protected, public with some constraints, not only when they are protected and public.
The access specifier in the overriding method (in the derived class) should not be more limiting than that of the overriden method (in the base class). This means that if the access specifier for base class method is protected then the access specifier for the derived class method should not be default or private but can be protected, public. The order of increasing visibility of various specifiers is:
default
protected
public
Thanks,
Hari
Edited by: Hari on Jun 3, 2011 8:45 PM

Java abstract classes and methods

Can anyone please tell me any real time example of abstract classes and methods.
I want to know its real use. If anyone have ever used it for some purpose while programming please do tell me.

Ashu_Web wrote:
No please.. I just want to know if you have used it while programming. Like "an abstract class can be used to put all the common method names in it without having to write actual implementation code."That would describe an Interface better than an abstract class. Abstract classes usually have at least some implementation.
I want to know its usage in programming, not just a definition. I guess you understand what I am looking for.Yes, and I gave you one: java.util.AbstractList. It can be found inside the src.zip in your JDK directory and it is a pretty good example for an abstract class that provides some implementation and defines exactly what is necessary to make a full List implementation.

Abstract class and a static method

Can i call a static method within an abstract class ?

public class AbstractDemo {
public static void main(String[] args) {
    BiPlane biPlane = new BiPlane();
    System.out.println("biplane propulsion = " + biPlane.getPropulsionType());
    JumboJet jumboJet = new JumboJet();
    System.out.println("jet load = " + jumboJet.confirmMaxLoad());
    System.out.println("jet speed = " + jumboJet.getTopSpeed());
    System.out.println(Airplane.confirmMaxLoad());
abstract class Airplane {
static String confirmMaxLoad() {
    return "go_get_um, yeehaa!";
public abstract String getPropulsionType();
abstract String getTopSpeed();
class BiPlane extends Airplane {
public BiPlane() {
    System.out.println("BiPlane constructor");
static String confirmMaxLoad() {
    return "400 lbs";
public String getPropulsionType() {
    return "propeller";
final String getTopSpeed() {
    return "130 knots";
class JumboJet extends Airplane {
public JumboJet() {
    System.out.println("JumboJet constructor");
public String getPropulsionType() {
    return "jet";
public String getTopSpeed() {
    return "mach .87";
}

When should I use abstract classes and when should I use interfaces?

Can any body tell me in which scenario we use /we go for Interface and which scenario we go for abstract class, because as per my knowledge what ever thing we can do by using Interface that thing can also done through abstract class i mean to say that the
behavior of the two class.
And other thing i also want to know that which concept comes first into the programming abstract class or Interface.
S.K Nayak

The main differences between an abstract class and an interface:
Abstract
An abstract class can contain actual working code (default functionality), and can have either virtual or abstract method.
An abstract class must be sub-classed and only the sub-classes can be instantiated. Abstract methods must be implemented in the sub-class. Virtual methods may be overridden in the sub-class (although virtual methods typically contain code, you still may
need/want to override them). A good use for an abstract class is if you want to implement the majority of the functionality that a class will need, but individual sub-classes may need slightly different additional functioality.
Interface
An interface only contains the method signatures (method name and parameters), there is no code and it is not a class.
An interface must be implemented by a class. An interface is not a class and so it cannot be sub-classed. It can only be implemented by a class. When a class implements an interface, it must have code in it for each method in the interface's definition.
I have a blog post about interfaces:
http://geek-goddess-bonnie.blogspot.com/2010/06/program-to-interface.html
(sorry, I have no blog posts specific to abstract classes)
~~Bonnie DeWitt [C# MVP]
http://geek-goddess-bonnie.blogspot.com

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(); }

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

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

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

Calling a method from an abstract class in a seperate class

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

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

Non-abstract methods in a Abstract class

Abstract Class can contain Non-abstract methods.
and Abstract Classes are not instantiable as well
So,
What is the purpose of Non-abstract methods in a Abstract class.
since we can't create objects and use it
so these non-abstract methods are only available to subclasses.
(if the subclass is not marked as abstract)
is that the advantage that has.(availability in subclass)
??

For example, the AbstractCollection class (in
java.util) provides an implementation for many of the
methods defined in the Collection interface.
Subclasses only have to implement a few more methods
to fulfill the Collection contract. Subclasses may
also choose to override the AbstractCollection
functionality if - for example - they know how to
provide an optimized implementation based on
characteristics of the actual subclass.Another example is the abstract class MouseAdapter that implements MouseListener, MouseWheelListener, MouseMotionListener, and that you can use instead of these interfaces when you want to react to one or two types of events only.
Quoting the javadocs: "If you implement the MouseListener, MouseMotionListener interface, you have to define all of the methods in it. This abstract class defines null methods for them all, so you can only have to define methods for events you care about."

Abstract class and RMI

Hi!
I have a desgin where I have an abstract class that in its constructor registers itself in a registry and define three abstract methods. Then I have a class that extends the abstract class and implements the three methods.
One of the methods inserts som text in a textArea defined in the child of the abstract class but when I call this method remotly I get a nullpointer exception saying that the textArea has not been initialized. The child ofcause calls super in its constructor.
So my question is can you not extend an abstract class that register it self in the constructor and then call methods remotly that uses variables that have been initialized in a childs constructor?
Have your any idea to why I get the nullpointer exception?
Peter

>
This sounds like there might be a misunderstanding
about the nature of methods and variables. If, for
instance, your client looks something like this:
RObject roo = ...// get via RMI
TextArea text = roo.getTextArea();
text.setText("...");
My design is more like this:
public interface Subscriber extends Remote {
public void notifySubscriber();
public abstract class A implements Subscriber {
a() {
    server.addSubscriber(this);
public abstract method1();
// some more abstract methods
public void notifySubscriber() {
    // do some stuff
    method1();
public class B extends A {
JTextArea text;
A() {
    super();
    text = new JTextArea();
public void method1() {
    // do some stuff
    // then text is null when called remotly
    text.setText("Hello");
}Hope this makes my design more clear and you can see the problem.
Thanks in advance

Question about abstract classes and instances

I have just read about abstract classes and have learned that they cannot be instantiated.
I am doing some exercises and have done a class named "Person" and an abstract class named "Animal".
I want to create a method in "Person" that makes it possible to set more animals to Person objects.
So I wrote this method in class Person and compiled it and did not get any errors, but will this work later when I run the main-method?
public void addAnimal(Animal newAnimal)
animal.add(newAnimal);
}Is newAnimal not an instance?

Roxxor wrote:
Ok, but why is it necessary with constructors in abstract classes if we don�t use them (because what I have understand, constructors are used to create objects)?Constructors don't create objects. The new operator creates objects. An object's c'tor is invoked after the object has already been created. The c'tors job is to initialize the newly-created object to a valid state. Whenever a child object is created, the parent's c'tor is run before the child's c'tor, so that by the time we're inside the child's c'tor, setting up the child's state, we know that the parent (or rather the "parent part" of the object we're initializing) is in a valid state.
Constructor rules:
1) Every class has at least one ctor.
1.1) If you do not define an explicit constructor for your class, the compiler provides a implicit constructor that takes no args and simply calls super().
1.2) If you do define one or more explicit constructors, regardless of whether they take args, then the compiler no longer provides the implicit no-arg ctor. In this case, you must explicitly define a public MyClass() {...} if you want one.
1.3) Constructors are not inherited.
2) The first statement in the body of any ctor is either a call to a superclass ctor super(...) or a call to another ctor of this class this(...) 2.1) If you do not explicitly put a call to super(...) or this(...) as the first statement in a ctor that you define, then the compiler implicitly inserts a call to super's no-arg ctor super() as the first call. The implicitly called ctor is always super's no-arg ctor, regardless of whether the currently running ctor takes args.
2.2) There is always exactly one call to either super(...) or this(...) in each constructor, and it is always the first call. You can't put in more than one, and if you put one in, the compiler's implicitly provided one is removed.

Method signature (Chapter : Abstract class and Polymorphism)

Similar Messages

Maybe you are looking for