принимающий только интерфейсы Woman объект, реализующий ТОЛЬКО интерфейс Woman. Предположим, такой:
interface Woman : Person { Person giveBirth() }
и вот ты написал класс Hospital<T: Woman> { accept(T t) { /*и вот тут даже реализовал свою коварную проверку, что T еще и не Man, а то не дай бог скрепы погнутся*/} }
так вот, скажи пожалуйста, как всё это обезопасит тебя от того что в моей реализации giveBirth() я просто дерну какой-нибудь нативный драйвер, который крэшнет к хренам всю JVM? как ты на это будешь проверки встраивать в своем коде?
System.exit(0)? 🤣
да хотя бы и
А я вообще не говорил, что нельзя что то сломать с любой проверкой и защитой. Я просто поинтересовался, почему разработчик, сделал так, а не дал возможность, полной ИНВАРИАНТНОСТИ, что бы уменьшить работу человеку, а так получается забили голову доп информацией, которая на деле и не нужна.
Против такого проверка только одна , анализ кода на такой вот код))) но если такое кто-то исполнил, значит вы сильно кого-то достали)
Андрей, один класса может реализовывать несколько интерфейсов. Задача разработчика этого класса - сделать так чтобы их реализация в рамках одного класса не противоречила друг другу. То, что класс реализует какой-то интерфейс - это необходимая И ДОСТАТОЧНАЯ информация для твоего кода, который работает именно с этим интерфейсом. Если кто-то написал класс, который нарушает контракт одного из своих интерфейсов - это не твоя забота вообще, это забота такого чудо-автора. Так понятнее? Ну или давай на другом примере. Вот скажи, ты когда болт определенного диаметра вытачиваешь, ты заморачиваешься, чтоб на него можно было только шестигранную гайку накрутить, а например гайку с такой же резьбой, но с ушами, было уже нельзя?
и каким образом защищается чтобы болт использовали только для накручивания гайки и не засовывали в другие места
Обсуждают сегодня