Инкапсуляция — черный ящик?

[9mm]

Скрытый ящик?!

[kadkaz]

Инкапсуляция это искусство, а не просто скрытый ящик, т.е. сравнение инкапсуляции со скрытым ящиком считаю не равнозначным.

[9mm]

Я про то что «скрытый ящик» => «недоступный ящик», а то что вы имели в виду называется «чёрный ящик».

Русского языка надо знать!

[CheatEx]

> Overriden. Делать методы с оператором доступа, чтобы можно было переопределить методы. (как минимум protected, используйте очень редко уровень доступа меньше защищенного)
> Last Version is Evil. Не использовать ключевое слово final для функции и классов. Позволять переопределять функции и классы

В теории хорошо. На практике это означает что работать с такими методами безопасно нельзя, надо проверять выходы, ловить исключения. Это разрастание кода библиотек в разы.

[kadkaz]

Данный подход не панацея, а добавляет удобство в использовании. На практике бы предложил разделить ответственность на поведение наследуемого класса таким образом:

• — у public методов и классов отвественность лежит на разрабочике класса родителя
• — у protected методов и классов отвественность лежит на разрабочике потомка

При такой ответственности становится проще создавать такие классы.

[CheatEx]

Для того чтобы переложить ответственность на разработчика потомка нужно детально задокументировать требования к потомку. Очень детально.
Мало того даже после этого, если Петя плохо прочитает документацию и напишет кривое расширение, его коллега Вася с вероятностью 90% сначала проедется по мозгам разработчиков библиотеки и только потом по мозгам Пети.
Ответственность когда что-то пишется и ответственность когда что-то ломается и отлаживается в общем слабо связаны. Да потом можно будет сказать «разработчик потомка — засранец». Вот только автор бибилиотеки перед этим проползёт на брюхе по обоим кодовым базам, а автор расширения получит подробное описание проблемы.

[kadkaz]

Всему нужен баланс. Один из примеров подхода данных принципов является покрывать код тестами, тогда он станет ближе к вновь использованному классу. Созданный таким образом класс будет иметь больше вероятности для нового использования класса, а не переписывания его заново.

[FreeTibet]

Немного холиварная цитата в тему:

— Долгая история. Все дело в том, что местные программисты пошли по неверному пути. Этот путь называется объектно ориентированный подход в программировании. На самом деле это мина с часовым механизмом в красивой упаковке. В очень красивой упаковке. Как с этим бороться, я не знаю. Упустил момент.

— Мастер, ближе к делу.

— Знаешь анекдот, как программист кипятит чайник. Дано: пустой чайник, кран, спички, газовая плита. Программа действий: наполнить чайник водой из-под крана, поставить на плиту, зажечь газ. Ждать, пока закипит чайник. Эта программа оформляется как объект. Второй случай. Все то же самое, но чайник с водой уже стоит на плите. Действия программиста: вылить воду из чайника и выполнить предыдущий объект.

— Грустно. А нырнуть внутрь объекта нельзя? Туда, где надо газ зажечь?

— Нельзя. Можно добавить новое свойство или действие. В нашем случае — воду вылить. Будет новый объект. Но внутрь влезть нельзя. Объект дается как единое целое. Никто не знает, что там внутри. Все давно забыли, откуда ноги растут. В результате получается колоссальное дублирование кода и данных и огромная потеря производительности компьютера. С каждым годом компьютеры требуют все больше памяти, а работают все медленнее.

Павел Шумилов — Иди, поймай свою звезду

[int_index]

Программист, создавший этот объект — идиот. Нужно было сделать проверку на наличие воды в чайнике. Да и основывается сие «поучающее» произведение на анекдоте, к вашему сведению.

[FreeTibet]

Это всего лишь пример, чтобы объяснить суть проблемы не программисту. Вы разве не встречались с подобными объектами на практике?

[andreycha]

Igor: херня
Igor: все дело в архитектуре классов
Igor: он рассказал про плохую архитектуру
Igor: вариантов как всегда много

Andrey: Отдельно кран, чайник, плита?

Igor: про интерфейс класса в том числе
Igor: а чайник, стоящий на плите — это уже сериализованный объект
Igor: точнее заполненный объект, полученный методом десериализации от внешней системы)

Andrey: Т.е. чайник — это депенденси? )

Igor: чайник это DTO
Igor: Ж)

Andrey: :D

Igor: рядом есть ЧайникМенеджер))
Igor: ЧайнаяЦеремонияКонтроллер

[FreeTibet]

Придумать правильную реализацию не сложно. Проблема не в реализации, а в том, что ООП подход провоцирует подобные ситуации.

[spiritedflow]

Я не уверен, что ООП здесь что-то меняет.

Всю процедуру также можно было бы запихнуть в одну Большую Функцию, которая во второй ситуации спровоцирует те же действия: вылить воду, убрать чайник, вызвать Большую Функцию.

Большую Функцию можно отрефакторить, разбить на части. Но тоже самое можно сделать и с классом.

Так что не вижу разницы между ООП и без ООП. И там и там есть плохой дизайн и там и там его можно рефакторить.

[DeusModus]

Ваш перевод нечитаемое говно. Попросите кого-нибуль читать ваш текст перед публикацией, если глаз замылен, а лучше не пишите статей, в предметной области которых вы профан.
// Можно взглянуть на скрытый ящик как уже готовый продукт, который используется для достижения цели, так и материал, составляющая, из которого будет создаваться форма для достижения цели.

[int_index]

Перевод ли это?

[andreycha]

Тем хуже, если это не перевод.

[kadkaz]

Это не перевод. Будем рефакторить:)