Si bien algunas personas pueden odiar los "métodos opcionales", en muchos casos pueden ofrecer una mejor semántica que las interfaces altamente segregadas. Entre otras cosas, permiten las posibilidades de que un objeto gane habilidades o características en su vida útil, o que un objeto (especialmente un objeto envoltorio) no sepa cuándo se construye qué habilidades exactas debe informar.
Aunque difícilmente llamaré a las clases de colecciones Java un 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 preguntar a una colección sobre sus características y habilidades . Un diseño de este tipo permitirá que se utilice una única clase de envoltura con una gran variedad de colecciones sin que se oculten accidentalmente las capacidades que la colección subyacente pueda tener. Si los métodos no fueran opcionales, entonces sería necesario tener una clase de envoltorio diferente para cada combinación de características que las colecciones puedan admitir, o de lo contrario, algunos envoltorios serán inutilizables en algunas situaciones.
Por ejemplo, si una colección admite la escritura de un elemento por índice o la adición de elementos al final, pero no admite la inserción de elementos en el medio, entonces el código que desee encapsularlo en un contenedor que registraría todas las acciones realizadas en él Necesitará una versión de la envoltura de registro que proporcione la combinación exacta de habilidades admitidas, o si no hubiera ninguna disponible, tendría que usar una envoltura que admitiera la adición o escritura por índice, pero no ambas. Sin embargo, si una interfaz de colección unificada proporcionaba los tres métodos como "opcionales", pero luego incluía métodos para indicar cuál de los métodos opcionales sería utilizable, entonces una sola clase envoltura podría manejar colecciones que implementan cualquier combinación de características. Cuando se le pregunta qué funciones admite, un contenedor podría simplemente informar lo que sea que admita la colección encapsulada.
Tenga en cuenta que la existencia de "habilidades opcionales" puede en algunos casos permitir que las colecciones agregadas implementen ciertas funciones de maneras mucho más eficientes de lo que serían posibles si las capacidades estuvieran definidas por la existencia de implementaciones. Por ejemplo, supongamos que se utilizó un método concatenate para formar una colección compuesta de otros dos, el primero de los cuales fue un ArrayList con 1,000,000 elementos y el último de los cuales fue una colección de veinte elementos que solo podría ser iterado desde el comienzo. Si a la colección compuesta se le pidiera el elemento 1,000,013 (índice 1,000,012), podría preguntar a la ArrayList cuántos elementos contenía (es decir, 1,000,000), restar eso del índice solicitado (que produce 12), leer y omitir doce elementos del segundo colección, y luego devolver el siguiente elemento.
En tal situación, aunque la colección compuesta no tendría una forma instantánea de devolver un artículo por índice, pedir la colección compuesta para el artículo 1,000,013 sería aún más rápido que leer 1,000,013 artículos individualmente e ignorar todos pero el último.