Às vezes, o downcasting é necessário e apropriado. Em particular, geralmente é apropriado nos casos em que se possui objetos que podem ou não ter alguma habilidade, e se deseja usá-la quando existe enquanto manipula objetos sem essa habilidade de alguma maneira padrão. Como um exemplo simples, suponha que String
se pergunte a se é igual a algum outro objeto arbitrário. Para que um String
seja igual ao outro String
, ele deve examinar o comprimento e a matriz de caracteres de apoio da outra sequência. Se a String
é perguntado se é igual a Dog
, no entanto, ele não pode acessar o comprimento de Dog
, mas não deveria; em vez disso, se o objeto ao qual String
se supostamente se comparar não for umString
, a comparação deve usar um comportamento padrão (relatando que o outro objeto não é igual).
O momento em que o downcasting deve ser considerado o mais duvidoso é quando o objeto que está sendo transmitido é "conhecido" como sendo do tipo apropriado. Em geral, se um objeto é conhecido como a Cat
, deve-se usar uma variável do tipo Cat
, em vez de uma variável do tipo Animal
, para se referir a ele. Há momentos em que isso nem sempre funciona, no entanto. Por exemplo, uma Zoo
coleção pode conter pares de objetos em slots de matriz pares / ímpares, com a expectativa de que os objetos em cada par possam agir um contra o outro, mesmo que não possam agir sobre os objetos em outros pares. Nesse caso, os objetos em cada par ainda teriam que aceitar um tipo de parâmetro não específico, de forma que eles pudessem, sintaticamente , passar os objetos de qualquer outro par. Assim, mesmo se Cat
'splayWith(Animal other)
O método só funcionaria quando other
fosse a Cat
, Zoo
seria necessário transmitir a ele um elemento de um Animal[]
, portanto, seu tipo de parâmetro teria que ser em Animal
vez de Cat
.
Nos casos em que o downcasting é legitimamente inevitável, deve-se usá-lo sem receio. A questão-chave é determinar quando é possível evitar sensivelmente o downcasting e evitá-lo quando possível.