Проблемы инкапсуляции

[@bfDeveloper]

Хорошая статья по хорошему вопросу.
Оставлю это здесь. Это, имхо, одна из лучших теоретических статей про инкапсуляцию. Хорошо отражает то, что вы пишете про теоретиков.

[@Neutral]

[@johnnythekid]

да-да, я тоже «Дюну» вспомнил

[@Neutral]

это всё из-за картинки в топике =)

[@lightcaster]

Залез проверить, есть ли что-то про Дюну в комментах :).

[@Vladson]

Играть в неё на сеге, мне лично было приятнее чем смотреть фильм…

[@johnnythekid]

а книге никто не?..

[@Colwin]

Читал все :-)
ИМХО, гораздо понятнее и интереснее фильма.

[@prefrontalCortex]

404. Я пропустил всё веселье? :(

[@Neutral]

Скриншот из х/ф «Дюна», Преподобная Мать говорит Полу Атрейдесу:
— Положи свою правую руку в коробку.
— Что в коробке?
— Боль.

[@youlose]

Мне кажется что вы придумали то, что называется «adapter» паттерном программирования ООП.

[@AlexanderYastrebov]

Только не адаптер, а фасад

[@youlose]

Да, согласен, но адаптер, тоже, в принципе, подходит.

[@AlexanderYastrebov]

У автора не стояла задача адаптировать интерфейс, у него стояла задача его упростить — поэтому фасад.

[@youlose]

Да, действительно, вы абсолютно правы.

[@d7k]

Обертка или Wrapper одно из его названий («банда четырех»). В свое время проверял.

[@serf]

Шаблон адаптера, не ново, приходит на ум даже не читая умных книжек, черный ящик запакованный в белый (серый) ящик :) Если «оборачиваемая» библиотека обловляется, может вставть проблема синхронизации (хотя она встанет и без обертки).

[@subecho]

Каким образом приведенный пример решают описанную вначале проблему? Он может послужить иллюстрацией к паттернам Фасад и Адаптер но не более

[@vaniaPooh]

У GoF прямо так и написано: вы можете использовать шаблон Фасад не только для организации внешнего интерфейса ко всему продукту, но и для упрощения взаимодействия между отдельными его подсистемами.

[@mrjj]

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

[@VolCh]

Это хорошо, если у вас нормальный класс… А если просто кусок «потока сознания», задействующий глобальные переменные, инклудящий другие такие же куски и т. п…

[@Alexnn]

en.wikipedia.org/wiki/Indirection

A famous aphorism of David Wheeler goes: «All problems in computer science can be solved by another level of indirection»;[1] this is often deliberately mis-quoted with «abstraction layer» substituted for «level of indirection». Kevlin Henney's corollary to this is, "...except for the problem of too many layers of indirection."

Вольно по-русски: все проблемы программирования можно решить, добавляя ещё одну обвертку… но только не проблему слишком большого количества обверток!

[@elw00d]

Уровень абстракции же, зачем придумывать странные слова :)

[@CheatEx]

www.youtube.com/watch?feature=player_detailpage&v=VKQMWZHiQVQ#t=120s — иллюстрирует проблему в целой куче аспектов :)

[@elw00d]

Проблема недоверия к чужим черным ящикам решается двумя путями:
1. Документирование
2. Привлечение комьюнити
Поэтому проектам, выложенным на гитхабе, с хорошей документацией и многочисленным комьюнити, обычно доверяют. Если же нет возможности выложить код в опенсорс и потратить время на полноценное документирование, то можно хотя бы прокомментировать код и сделать маленькое описание рядом в текстовом файле, а потом дать коллегам посмотреть. Это не занимает много времени, зато ваш последователь 2 раза подумает, прежде чем выкинуть ваш ящик с тем, чтобы заменить его своим.

[@Mr_Floppy]

Чем обернуть своим ящиком.

[@rumatavz]

В чем свзяь паттерна адаптер и тех проблем с черными ящиками, которые вы обозначили?

[@youlose]

Адаптер, Adapter или Wrapper/Обёртка — структурный шаблон проектирования, предназначенный для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс

В данном случае «недоступный» в смысле — неохота разбираться с ним. Но выше мы уже выяснили что больше подходит определение паттерна «фасад».

[@mrjj]

Уфф, смешелись в кучу кони, люди.

Инкапсуляция сама по себе не есть проблема, — это директива на уменьшение связанности фрагментов кода и локализации деталей, связанных с конкретной реализацией.

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

[@Alexznadr]

в начале статьи «инкапсуляция это ууу плохо», и в конце — «инкапсуляция» как метод борьбы с инкапсуляцией. Вы правда не видите подвоха? Проблема с вашим кодом вовсе не в инкапсуляции

[@FB3]

Если тут про юнит тесты имеется ввиду, то странно писать тесты для полученного класса при отсутствии тестов для класса, с которым он взаимодействует… Тот большой класс наверняка можно протестировать, а потом отрефакторить. Если есть код и есть возможность его менять, то нужно это делать, когда возникает необходимость. А так да, про фасад уже сказали.
В общем, тут в кучу смешались шаблоны проектирования и тестирование кода, поэтому возник такой комментарий. На самом деле нельзя написать тесты к тому, что получилось, потому что нет тестов к тому большому классу, а соответственно, неизвестно его поведение в различных ситуациях.

[@VolCh]

А в различных и не надо, надо в нужных для приложения. И тесты будут не юнит, а интеграционные или функциональные, пускай и с помощью того же инструментария, что и юнит. Если нужные тесты не проходят, например не выбрасывается исключение при отсутствии файла или его недоступности на запись, то пишем throw в своём фасаде, не трогая чужой код. Также поступаем со всеми остальными исключительными случаями, а что там в этом классе происходит нас мало интересует, если функциональный тест проходит. Правда не знаю, можно ли его в таком случае ещё называть фасадом.

[@B08AH]

тоже как то сам на это набрёл.

цель была сократить количество вызываемых методов, то бишь упростить код «бизнес-логики», в частности проверка не пуст ли лист, прежде чем выбирать элементы, в т.ч. чтоб ексепшен исключить в «нормальном» режиме, плюс встроил энумератор чтоб можно было foreach делать сразу с нужным типом. и т.п.
к примеру XmlDocument так под себя затачивал.

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