Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36830

Re: Confusing interface

Show all headers | View raw

On Friday, July 7, 2017 at 4:25:41 PM UTC-4, Eric Sosman wrote:
> > 2) If you don't override a public method, that method can be called on your subclass.  If that method returns an instance of your super class, the return value will be an instance of your subclass.
> 
>      Wrong, or "not necessarily so."  The method returns whatever it
> returns.  There may be code in the method to snoop out the class of
> the `this' on which it was called, and to tailor the nature of the
> returned object accordingly.  But unless it does something of that
> kind, there's no magic that somehow replaces the object returned
> with a different object of one of its subclasses.
> 
>      clone() usually (*usually*) does such tailoring, but that is not
> a requirement of the language.  If (*if*) clone() returns the object
> it obtains from super.clone() and if that is in turn obtained from
> super.super.clone() and so on all the way up to Object, then the
> object will have the same class as `this'.  However, a particular
> class is allowed to implement its clone() in some other way, and to
> return an object of an "atypical" type.
> 

Of course it seems wrong but I suppose you could write a clone() method which returns an object other than an instance of the current class.
If you write a clone() method such as they did in the DefaultMutableTreeNode class, and it's called from a subclass of that class which does not override it, it returns an instance of the subclass?

    public Object clone() {
        DefaultMutableTreeNode newNode;

        try {
            newNode = (DefaultMutableTreeNode)super.clone();

            // shallow copy -- the new node has no parent or children
            newNode.children = null;
            newNode.parent = null;

        } catch (CloneNotSupportedException e) {
            // Won't happen because we implement Cloneable
            throw new Error(e.toString());
        }

        return newNode;
    }


> > 3) You cannot override a method parameter with a different class.  If you require the super method of your class to only be called from your class with a parameter that is a subclass of what the super class expects, you just check instanceof inside the method.
> 
>      That'd be one way.  Another would be to write two methods, one
> an override and the other an augmentation:
> 
> 	class Super {
> 	    void method(Thing thing) { ... }
> 	}
> 
> 	class Sub extends Super {
> 	    @Override
> 	    void method(Thing thing) {
> 	        if (thing instanceof MyThing)  // might also allow null
> 	            method((MyThing) thing);
> 	        else
> 	            throw new WrongTypeException();
> 	    }
> 
> 	    void method(MyThing thing) {
> 	        ... // might or might not call super.method(thing)
> 	        ... // and maybe do other things in addition
> 	    }
> 	}
> 
> This way, a call whose compile-time type is MyThing (or a subclass
> thereof) goes directly to the augmenting method without the overhead
> of checking, while calls with other compile-time types get screened
> for the proper run-time type.
> 

I see.  So it is best to override a parameter with a subclass of the parameter by overriding and killing the parameter.  If class A extends class B, your super class passes in an instance of B, and you want the same method to only accept instances of A, first copy the signature to accept A and throw invalid.  Then write the signature to accept A, which can call the super method looking for B if you want it to do the same thing. (addCarToLot(Car c), but CarDealerF only wants to allow addCarToLot(Ford c))

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Confusing interface Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 06:10 -0700
  Re: Confusing interface Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-07 09:45 -0400
    Re: Confusing interface Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 07:37 -0700
      Re: Confusing interface Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-07 11:26 -0400
        Re: Confusing interface Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 11:24 -0700
          Re: Confusing interface Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-07 14:50 -0400
            Re: Confusing interface Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 12:00 -0700
              Re: Confusing interface Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-07 15:27 -0400
                Re: Confusing interface Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 12:47 -0700
                Re: Confusing interface Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-07 16:25 -0400
                Re: Confusing interface Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 13:39 -0700
                Re: Confusing interface Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-07 17:43 -0400

csiph-web