StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POHow do you work around the need to cast an interfaced object back to its base class?
text
Body
copied!<p>This question is meant to apply to interfaces in general, but I'll use AS3/Flex for my language. It should be [mostly] obvious how to apply it in different languages.</p> <p>If I create a base class, and it extends an interface, there is an explicit contract defined: for every method in the interface, the base class <em>must</em> implement said method.</p> <p>This is easy enough. But I don't understand why you have the capacity to cast an interfaced instance back to its original base class. Of course, I've had to do this a few times (the example below is very close to the situation I'm struggling with), but that doesn't mean I understand it :^)</p> <p>Here's a sample interface:</p> <pre><code>public interface IFooable extends IUIComponent { function runFoo():void; } </code></pre> <p>Let's say I create a base class, which extends VBox and implements the interface:</p> <pre><code>public class Foo extends VBox implements IFooable { public Foo() { super(); //stuff here to create Foo..blah blah } public function runFoo():void { // do something to run foo } } </code></pre> <p>Now, the reason I used the interface, is because I want to guarantee "runFoo" is always implemented. It is a common piece of functionality all of my classes should have, regardless of how they implement it. Thus, my parent class (an Application) will instantiate Foo via its interface:</p> <pre><code>public function init():void { var foo:IFooable = new Foo(); foo.percentHeight = 100; //works because of IUIComponent } </code></pre> <p><em>But</em>, if I want to add Foo to the Application container, I now have to cast it back to the base class (or to a different base class):</p> <pre><code>public function init():void { var foo:IFooable = new Foo(); foo.percentHeight = 100; addChild(foo as DisplayObject); //_have_ to cast, because addChild takes a 'DisplayObject' class type //could also do this: //addChild(foo as VBox); } </code></pre> <p>Wasn't the original intention to hide the implementation of Foo? There is still an assumption that Foo <em>is</em> a DisplayObject. Unfortunately, being able to add the custom object to a container seems impossible without casting.</p> <p>Am I missing something entirely? Is this really just a phenomenon in Flex/AS3? If you have a container in the base API of a language, and it only allows you to add children of a certain class type, how do you then abstract out implementation?</p> <p>For the record, <a href="https://stackoverflow.com/questions/539436/cast-interface-to-its-concrete-implementation-object-or-vice-versa">this question</a> appears to ask if this sort of operation is <em>possible</em>, but it doesn't really address why it might be bad design (and how to fix it).</p> <hr> <p>2nd Thought:</p> <p><strong>Abstract Classes</strong>:</p> <p>As Matthew pointed out, abstract classes helps solve some of this: I could create a base abstract class which inherits from the DisplayObject (or, in my case, the VBox, since it is a child of DisplayObject), and have the base class implement the interface. Thus, any class which extends the abstract class would then be required to implement the methods therein.</p> <p>Great idea -- but AS3 doesn't have abstract classes (to my knowledge, anyway).</p> <p>So, I <em>could</em> create a base class which implements interface and extends the VBox, and inherit from it, and I could insert code in those methods which need to be extended; such code would throw an error if the base class is the executor. Unfortunately, this is run-time checking as opposed to compile-time enforcement.</p> <p>It's still a solution, though.</p> <hr> <p><strong>Context</strong>:</p> <p>Some context might help:</p> <p>I have an application which can have any number of sub-containers. Each of these sub-containers will have their own respective configuration options, parameters, etc. The application itself, however, has a global ApplicationControlBar which will contain the entry-point Menu for accessing these configuration options. Therefore, whenever I add a sub-component to the main Application (via "addChild"), it will also "register" its own configuration options with the ApplicationControlBar menu. This keeps the knowledge of configurability with the containers themselves, yet allows for a more unified means of accessing them.</p> <p>Thus, when I create each container, I want to instantiate them via their interface so I can guarantee they can register with the ApplicationControlBar. But when I add them to the application, they need to be the base class.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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