Si bien algunas personas pueden detestar los "métodos opcionales", en muchos casos pueden ofrecer una semántica mejor que las interfaces altamente segregadas. Entre otras cosas, permiten las posibilidades de que un objeto gane habilidades o características durante su vida útil, o que un objeto (especialmente un objeto envolvente) no sepa cuándo se construye qué habilidades exactas debería reportar.
Si bien difícilmente llamaré a las clases de colecciones de Java modelos de buen diseño, sugeriría que un buen marco de colecciones debería incluir en su base una gran cantidad de métodos opcionales junto con formas de preguntarle a una colección sobre sus características y habilidades . Tal diseño permitirá que se use una sola clase de envoltura con una gran variedad de colecciones sin oscurecer accidentalmente las habilidades que la colección subyacente podría poseer. Si los métodos no fueran opcionales, sería necesario tener una clase de contenedor diferente para cada combinación de características que las colecciones podrían admitir, o de lo contrario, algunos contenedores no podrán utilizarse en algunas situaciones.
Por ejemplo, si una colección admite escribir un elemento por índice o agregar elementos al final, pero no admite la inserción de elementos en el medio, entonces el código que desea encapsularlo en un contenedor que registraría todas las acciones realizadas en él necesitaría una versión del contenedor de registro que proporcionó la combinación exacta de habilidades compatibles, o si no hubiera ninguno disponible, tendría que usar un contenedor que admitiera agregar o escribir por índice, pero no ambos. Sin embargo, si una interfaz de colección unificada proporciona los tres métodos como "opcionales", pero luego incluye métodos para indicar cuál de los métodos opcionales sería utilizable, entonces una sola clase de contenedor podría manejar colecciones que implementan cualquier combinación de características. Cuando se le preguntó qué características admite, un contenedor podría simplemente informar lo que sea compatible con la colección encapsulada.
Tenga en cuenta que la existencia de "habilidades opcionales" puede permitir en algunos casos que las colecciones agregadas implementen ciertas funciones de manera mucho más eficiente de lo que sería posible si las habilidades se definieran por la existencia de implementaciones. Por ejemplo, suponga concatenateque se usó un método para formar una colección compuesta de otras dos, la primera de las cuales resultó ser una ArrayList con 1,000,000 de elementos y la última de las cuales fue una colección de veinte elementos que solo se pudo repetir desde el principio. Si a la colección compuesta se le pidiera el elemento 1,000,013 (índice 1,000,012), podría preguntarle a la ArrayList cuántos elementos contenía (es decir, 1,000,000), restar eso del índice solicitado (arrojando 12), leer y omitir doce elementos del segundo colección, y luego devuelve el siguiente elemento.
En tal situación, a pesar de que la colección compuesta no tendría una forma instantánea de devolver un artículo por índice, pedirle a la colección compuesta el 1,000,00013 ítem aún sería mucho más rápido que leer 1,000,013 artículos de forma individual e ignorar todos menos el último uno.