With due deference, what you just said I disagree with. The scenario you
described is not a necessary evil, it's a hack.
The only situation where that isn't a hack is if your class extends a native
type such as Sprite, but there's no ISprite. That problem is either solved by
adding the Sprite functions you need to your interface, or, if you need to
addChild() your interface, then you cast as Sprite because there's no other way.
Outside of that specific case, you should never run into the situation you
described, and if you do, it's time for a quick refactor.
If you want a function in SomeConcreteClass to be accessible outside the
class/inheritance/package (i.e. public) and you have an interface for that
class, then you should include that function in the interface. Sometimes you
may not put public methods in the interface because you want them to be public
to other packages inside your app, but not to "the outside world", and you
shouldn't be casting to the interface of that class in those cases. Why would
you cast as the interface when you don't need the interface?
Using interfaces incorrectly or inappropriately is the disease, not a symptom of
strict typing. If anything, strict typing forces these issues to appear in your
code before it's too late.
No matter what, proper typing never leads to code smell. Improper typing or
mixed typing like what you described is code smell in the sense that it's
indicative of poor architecture decisions.
On 6/7/2010 3:46 PM, Juan Pablo Califano wrote:
I agree with you, but I'add for the sake of completeness that, sometimes,
relaxing the rules a bit becomes a necessary evil, like for instance, when
doing a cast.
When you do this:
// bar is typed as ISomeInterface somewhere else
var foo:SomeConcreteClass = bar as SomeConcreteClass; // or
SomeConcreteClass(bar)
foo.methodOnlyPresentInConcreteClass();
You are basically bypassing the rules of type system. You're telling the
compiler that an object declared as ISomeInterface at compile time will be
an instance of SomeConcreteClass at runtime. You're asking the compiler to
trust you and not blow up when compiling your code. Some times this is
avoidable with some refactoring (and or a better design). Sometimes it's not
possible or impractical (this also depends on how purist you are, I guess).
Nevertheless, having too many casts is usually considered a code smell for
this very reason.
Cheers
Juan Pablo Califano
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
