LINUX.ORG.RU

Инкапсуляция.

 


1

2

Так сложилось, что я практически не знаком с ООП языками, но сейчас начал интересоваться ООП. И первое, что обращает на себя внимание - это инкапсуляция.

Собственно, инкапсуляция присутствует неявно и в ФП, например, замыкания - это вариант инкапсуляции. Но ее можно вообще изобразить явно, например:

(define fu (lambda(arg) (if (= arg 'I-am-foo) (bar))))
Тут очевидно, что мы скрываем вызов bar, от всех функций которые не отправляют нужное сообщение. Ключевое слово: ОТ ФУНКЦИЙ. Можно, в других случаях, говорить, что от объектов. Короче, от программных сущностей.

Однако, я часто наблюдаю, что под инкапсуляцией понимается сокрытие не от программных сущностей, а от самого программиста. Например:

Разные языки по-разному решают вопрос о том, как позволить программистам прятать информацию от самих себя. В объектно-ориентированных языках принцип полиморфизма, принципиального незнания мной того, объект какого класса я вызываю по ссылке (базового или наследника), является краеугольным; и это по-своему хорошо, если проведено последовательно.

What a fuck?!!! Нахрена прятать внутреннюю реализацию от самого программиста, а не от программных объектов?

Ответ на: комментарий от anonymous

Пользовался, но не в курсе что оно так называется. Это скорее обфускация а не «сокрытие», потому что если знать как лежат данные то их все равно можно достать мимо интерфейса.

AIv ★★★★★
()

По соображениям безопасности. У объектов есть приватные свойства, которые меняются как-то внутренними методами его. И действие его методов основано на значении этих полей. Если ты случайно изменишь их, объект может начать вести себя неадекватно. Для этого и придумано разделение на public и private. Тебе предоставлен интерфейс объекта. Для работы с ним этого достаточно. Знать реализацию можно его, но не обязательно.

Aswed ★★★★★
()
Ответ на: комментарий от emulek

для списков merge, для массивов - пирамида. На первые qsort плохо переводится, для вторых худший случай - квадрат. А у пирамиды всегда логарифм.

Aswed ★★★★★
()
Ответ на: комментарий от Aswed

Худшего случая можно избежать, на асимптотике это не скажется. И сама асимптотика — это такое дело, константы всё равно оказывают влияние. Плюс куча других факторов: возможность распараллеливания, учёт кешей и т. п.

ilammy ★★★
()
Ответ на: комментарий от Aswed

для вторых худший случай - квадрат.

вероятность худшего случая равна нулю при должном выборе медианы.

А у пирамиды всегда логарифм.

не. Какая-то степень N.

Пруфы этих выводов у Кнута ищи.

emulek
()
Ответ на: комментарий от Aswed

По соображениям безопасности.

ты бредишь. Читай посты выше от Alv. Он всё правильно разъяснил.

emulek
()
Ответ на: комментарий от ilammy

Худшего случая можно избежать

теоретически нельзя, практически — вполне можно.

Плюс куча других факторов: возможность распараллеливания, учёт кешей и т. п.

да. Heapsort черезжопно сортирует. Нерегулярно и непредсказуемо. В теории это не играет роли, но на практике — память она бывает разная.

emulek
()

Да ООП не работает, не парься :)

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.