Хоча деякі люди можуть ненавидіти "необов'язкові методи", вони в багатьох випадках можуть пропонувати кращу семантику, ніж високосегреговані інтерфейси. Крім усього іншого, вони передбачають можливості того, що об’єкт може набути здібностей або характеристик протягом свого життя, або що об'єкт (особливо об'єкт обгортки) може не знати, коли будується, про які саме здібності він повинен повідомляти.
Хоча я навряд чи буду називати класи колекцій Java парагонами гарного дизайну, я б припустив, що хороша рамка колекцій повинна містити у своїй основі велику кількість додаткових методів разом із способами запитання колекції про її характеристики та здібності . Така конструкція дозволить використовувати один клас обгортки з великою різноманітністю колекцій, не випадково затушовуючи здібності, якими може володіти базова колекція. Якщо методи не були необов'язковими, необхідно було б мати інший клас обгортки для кожної комбінації функцій, які колекції можуть підтримувати, або ж деякі обгортки можуть бути непридатними в деяких ситуаціях.
Наприклад, якщо колекція підтримує запис елемента за індексом або додавання елементів в кінці, але не підтримує вставлення елементів в середину, то код, який хоче інкапсулювати його в обгортку, який би записував усі дії, які виконуються над ним, потрібна версія оболонки обліку журналу, яка передбачала точне поєднання підтримуваних здібностей, або якщо жодна не була доступна, доведеться використовувати обгортку, яка підтримує додавання або записування за індексом, але не обидва. Якщо, однак, єдиний інтерфейс колекції забезпечував усі три методи як "необов'язкові", але потім включав методи, які вказували, який із необов'язкових методів був би придатний для використання, то один клас обгортки міг би обробляти колекції, що реалізують будь-яку комбінацію функцій. На запитання, які функції він підтримує, обгортка може просто повідомити, що підтримує інкапсульована колекція.
Зауважте, що існування "необов'язкових здібностей" може в деяких випадках дозволяти зведеним колекціям реалізовувати певні функції способами, які були набагато ефективнішими, ніж це було б можливо, якби здібності визначалися існуванням реалізацій. Наприклад, припустимо, що concatenateметод був використаний для формування складної колекції з двох інших, першим з яких став ArrayList з 1 000 000 елементів, а останній - колекцією з двадцяти елементів, яку можна було повторити лише з самого початку. Якщо складена колекція запитала елемент 1000,013-й (індекс 1000,012), вона могла запитати ArrayList, скільки предметів у ній міститься (тобто, 1 000 000), відняти це з запитуваного індексу (вихід 12), прочитати та пропустити дванадцять елементів з другого колекція, а потім поверніть наступний елемент.
У такій ситуації, навіть якщо складений збірник не мав би миттєвого повернення елемента за індексом, запитування складеної колекції для 1000 013-го предмета все-таки буде набагато швидше, ніж зчитування з нього 1000 013 предметів окремо і ігнорування всіх, крім останнього один.