Is this a safe use of to more specific class?

[GregFreeman]

I am attaching a simplified example and but I'm going to describe an example of where I'm running into this problem.

 

Lets say I have a class "Dialog" and from that I have a child class "Channel Config Dialog" The Dialog class accepts Dialog Pages and puts them in its private data, and the Channel Config Dialog accepts Channel Config Dialog Pages (a subclass of dialog page), but wants to reuse the fact that its parent already caries around pages. So there is a protected set method defined in the dialog class that allows the Channel Config Dialog to put Channel Config pages into the Parent Dialog Class's private data. 

 

So, I do this by having a static method in the child class, call it "set pages," and this method only accepts Channel Config Dialog Pages on its connector pane. This method then calls the protected method of the parent class to set the pages in the parent data. However, now the pages are being carried around on a parent Dialog Pages wire. If I want to call a Channel Config Dialog Pages method I'm out of luck. So, I was using to more specific class, assuming it's fairly safe because I have specified the connector pane on the child class's "Set Pages" method to not accept any Dialog Page type other than the type it expects. What I can't determine is if this is Ok or if it's pointing to a bad design decision and there is a better way.

 

If you are confused hopefully the attached code helps

 

 

 

 

config.zip

[mje]

In my opinion there's nothing inherently wrong about using the to more specific class primitive in this situation. There definitely other ways to tackle this but let's stick with your original implementation.

 

Be aware that since the base class likely manages access to the Channel Config Dialog Pages at the Dialog Page level, you have to be careful about assuming you can say all the contained Dialog Pages are in fact Channel Config Dialog Pages. Even if the accessor is protected, you have to make sure that all access to the contained Dialog Pages is protected and that none of the public methods of the parent can set Dialog Pages. If this seems inherently fragile, it is, but it isn't necessarily wrong. Just be mindful of error handling.

 

I'd also suggest ditching the property node in favor of an accessor which is more modeled after the polymorphic primitives that LabVIEW uses where they have a "type" input. This is a prime candidate for the preserve run-time class primitive:

 

 

Why would I do this? It puts the type checking all in one place so you don't need to do it each time you want to access your pages. It also is very handy for coding because the wire type changes dynamically at edit time depending on what you wire to the type input:

 

[GregFreeman]

Thanks, this makes sense. 

 

 

 

There definitely other ways to tackle this but let's stick with your original implementation.

 

Would you care to elaborate on this a bit more? I'm all for learning other ways to implement things, especially if it means trading run-time checking for compile time checking.

Edited April 16, 2013 by for(imstuck)

[mje]

Nothing elaborate really. For this specific problem you can flip things around to delegate ownership of any pages to implementing classes, and have the parent class define a method that returns any pages which get operated on. For example Dialog:GetConfigPages returns an array of pages which is called by any Dialog method that needs those pages. The Dialog implementation can return any pages which might always be there, or an empty array by default. Any implementing method appends it's own pages to those returned by its parent.

 

However I don't think this suggestion is any more "correct" than your implementation-- I've certainly used both models.

[GregFreeman]

Many thanks.