avoid instanceof in Java

前端 未结 9 2249
清歌不尽
清歌不尽 2021-02-12 20:40

I have been told at some stage at university (and have subsequently read in upteen places) that using instanceof should only be used as a \'last resort\'. With this

相关标签:
9条回答
  • 2021-02-12 21:13

    EDIT

    There are two primary things you can do here to relieve yourself of this specific instance of instanceof. (pun?)

    1. Do as my initial answer suggested and move the method you are targeting up to the class you are iterating. This isn't ideal in this case, because the method doesn't make sense to the parent object, and would be polluting as Ted has put it.

    2. Shrink the scope of the objects you are iterating to just the objects that are familiar with the target method. I think this is the more ideal approach, but may not be workable in the current form of your code.

    Personally, I avoid instanceof like the plague, because it makes me feel like I completely missed something, but there are times where it is necessary. If your code is laid out this way, and you have no way to shrink the scope of the objects you are iterating, then instanceof will probably work just fine. But this looks like a good opportunity to see how polymorphism can make your code easier to read and maintain in the future.

    I am leaving the original answer below to maintain the integrity of the comments.

    /EDIT

    Personally, I don't think this is a good reason to use instanceof. It seems to me that you could utilize some polymorphism to accomplish your goal.

    Have you considered making setUITweenManager(...) a method of GameObject? Does it make sense to do this?

    If it does make sense, you could have your default implementation do nothing, and have your GameGroup override the method to do what you want it to do. At this point, your code could just look like this then:

    private void allocateUITweenManager() {
       for(GameObject go:mGameObjects){
           go.setUITweenManager(mUITweenManager);
       }
    }
    

    This is polymorphism in action, but I am not sure it would be the best approach for your current situation. It would make more sense to iterate the Collection of UITweenable objects instead if possible.

    0 讨论(0)
  • 2021-02-12 21:13

    The problem with instanceof is that you can suffer from future object hierarchy changes. The better approach is to use Strategy Pattern for the cases where you are likely to use instanceof. Making a solution with instanceof you are falling into a problem Strategy is trying to solve: to many ifs. Some guys have founded a community. Anti-IF Campaign could be a joke but untipattern is serious. In a long term projects maintaining 10-20 levels of if-else-if could be a pain. In your case you'd better make a common interface for all objects of your array and implement setUITweenManager for all of them through an interface.

    interface TweenManagerAware{
       setUITweenManager(UITweenManager manager);
    }
    
    0 讨论(0)
  • 2021-02-12 21:13

    It is always a bit "fishy" to me to mix objects of different classes in the same Collection. Would it be possible / make sense to split the single Collection of GameObjects into multiple Collections, one of mere GameObjects, another of UITweenables? (e.g. use a MultiMap keyed by a Class). Then you could go something like:

    for (UITweenable uit : myMap.get(UITweenable.class)) {
      uit.setUITweenManager(mUITweenManager);
    }
    

    Now, you still need an instanceof when you insert into the map, but it's better encapsulated - hidden from the client code who doesn't need to know those details

    p.s. I'm not a fanatic about all the SW "rules", but Google "Liskov Substitution Principle".

    0 讨论(0)
提交回复
热议问题