Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Given the types above, <code>anExpressionOfTypeSubClassOrIClass.implementedMethod()</code> must be used. Note that the <em>Type of an expression</em> - the <em>view</em> it provides - must have the method intended to be used. In this case, an expression of type SuperClass cannot be used here because it has no declared <code>implementedMethod</code> member.</p> <p>One approach - and arguably the preferred approach - is to use <a href="http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html" rel="nofollow">abstract methods</a>. Even though abstract methods are not strictly required for <a href="http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming" rel="nofollow">Polymorphism</a> they describe scenarios such as this where a subclass should provide the implementation. (The abstract methods could be replaced with empty method <em>expecting</em> - but not requiring - to be overridden in sublcasses, but why not use <code>abstract</code> for its designed purpose?)</p> <pre><code>abstract class SuperClass implements IClass { // Don't implement this, but declare it abstract // so that we can conform to IClass as well public abstract void implementedMethod(); public void method () { // Now this object (which conforms to IClass) has implementedMethod // which will be implemented by a concrete subclass. implementedMethod(); } } </code></pre> <p>This has the "negative" aspects that SuperClass cannot be directly instantiated (it is abstract, after all) and that SuperClass must implement (or, as shown, delegate out via abstract) the expected signature. In this case I also chose to make SuperClass implement IClass even though it's not strictly required because it guarantees that the SuperClass and all subclasses can be <em>viewed</em> as an IClass.</p> <p>Alternatively, remember that <em>Types of Expressions are just views</em> of objects and are not necessarily the same as the actual <em>Concrete Type</em> of object. While I would advise against using the following code because it <em>loses some type-safety</em>, I think it shows the important point.</p> <pre><code>class SuperClass { public void method () { // We try to cast and NARROW the type to a // specific "view". This can fail which is one // reason why it's not usually appropriate. ((IClass)this).implementedMethod(); } } class SubClass extends SuperClass implements IClass { // .. } class BrokenSubClass extends SuperClass () { } // OK! Although it is the SAME OBJECT, the SuperClass // method can "view" the current instance (this) as an IClass // because SubClass implements IClass. This view must be // explicitly request through a cast because SuperClass itself // does not implement IClass or have a suitable method to override. (new SubClass()).method(); // BAD! ClassCastException, BrokenSubClass cannot be "viewed" as IClass! // But we didn't know until runtime due to lost type-safety. (new BrokenSubClass()).method(); </code></pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload