Инкапсуляция, отсутствие её — проблема?

Здравствуйте дорогие товарищи.

Недавно посещал одно интересное собеседование по Java.
Прозвучал вопрос , что такое инкапсуляция - ну в общем, выдал всё как есть. А дальше собеседующий приводит мне пример: представим, что мы - разработчик крупного фреймворка, какова будет наша главная проблема, если нет инкапсуляции?

Всяческие мои ответы про несекюрный доступ к служебным методам и переменным, про то, что юзер будет наружу видеть кучу кишок, которые ему не нужны и про то, что юзер может ломать всю логику фреймворка - были пропущены с комментариями "это не то" :) .

Hа мои встречные вопросы - только безумные глазки и хитрая ухмылка :) . Единственное, что он ответил, подсказал так что и не сильно помогло, - "с этой проблемой столкнулся создатель JDK".

Так что же, какова наша главная проблема?
  • Вопрос задан
  • 1636 просмотров
Решения вопроса 2
Отсутсвие инкапсуляции в данном контексте, очевидно, в первую очередь означает излишне обширный публичный интерфейс. А публичный интерфейс разработчик фреймворка просто так менять не может - нужно соблюдать обратную совместимость. Соответственно, чем больше у нас торчит наружу ушей, тем сложнее поддерживать и развивать фреймворк. Достаточно посмотреть на код Битрикса, например, чтобы увидеть к чему это приводит.
Думаю, вопрос был именно об этом.
Ответ написан
Комментировать
angrySCV
@angrySCV
machine learning, programming, startuping
инкапсуляция - "сокрытие реализации", не знаю что там от вас на собеседовании ожидали, обычно сложно угадать что там человек себе понапридумывал, что хочет услышать, я не обращаю на это внимание тк это не представляет никакого интереса.
хотя, я бы может сказал что-то типа такого:
если не скрывать реализацию - может быть проблема при изменении этой реализации, например на более эффективную, и тогда прийдётся переписывать много кода, тем кто использует вашу библиотеку, им это доставит адскую боль. никто же не хочет переписывать свой код при обновлении вашего фреймворка)
но реальность конечно куда сложнее, и код рано или поздно всё равно приходится переписывать)))))
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@bromzh
Drugs-driven development
Да нет особой проблемы. Просто ответственность за правильное использование апи перекладывается с разработчика апи на разработчика, использующего это апи.

Ну и к слову: наследование классов нарушает инкапсуляцию (для protected-полей и методов). А приватные поля/методы можно спокойно получить через рефлексию.
Вообще, инкапсуляция в виде модификаторов доступа - так себе. Лучше это реализовывать через замыкания и контексты. Но в java такого нет (и не будет). Так что и так сойдёт.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы