Comments 36
Хорошая статья по хорошему вопросу.
Оставлю это здесь. Это, имхо, одна из лучших теоретических статей про инкапсуляцию. Хорошо отражает то, что вы пишете про теоретиков.
Оставлю это здесь. Это, имхо, одна из лучших теоретических статей про инкапсуляцию. Хорошо отражает то, что вы пишете про теоретиков.
Мне кажется что вы придумали то, что называется «adapter» паттерном программирования ООП.
Шаблон адаптера, не ново, приходит на ум даже не читая умных книжек, черный ящик запакованный в белый (серый) ящик :) Если «оборачиваемая» библиотека обловляется, может вставть проблема синхронизации (хотя она встанет и без обертки).
Каким образом приведенный пример решают описанную вначале проблему? Он может послужить иллюстрацией к паттернам Фасад и Адаптер но не более
Это хорошо, если у вас нормальный класс… А если просто кусок «потока сознания», задействующий глобальные переменные, инклудящий другие такие же куски и т. п…
UFO just landed and posted this here
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."
Вольно по-русски: все проблемы программирования можно решить, добавляя ещё одну обвертку… но только не проблему слишком большого количества обверток!
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."
Вольно по-русски: все проблемы программирования можно решить, добавляя ещё одну обвертку… но только не проблему слишком большого количества обверток!
UFO just landed and posted this here
www.youtube.com/watch?feature=player_detailpage&v=VKQMWZHiQVQ#t=120s — иллюстрирует проблему в целой куче аспектов :)
Проблема недоверия к чужим черным ящикам решается двумя путями:
1. Документирование
2. Привлечение комьюнити
Поэтому проектам, выложенным на гитхабе, с хорошей документацией и многочисленным комьюнити, обычно доверяют. Если же нет возможности выложить код в опенсорс и потратить время на полноценное документирование, то можно хотя бы прокомментировать код и сделать маленькое описание рядом в текстовом файле, а потом дать коллегам посмотреть. Это не занимает много времени, зато ваш последователь 2 раза подумает, прежде чем выкинуть ваш ящик с тем, чтобы заменить его своим.
1. Документирование
2. Привлечение комьюнити
Поэтому проектам, выложенным на гитхабе, с хорошей документацией и многочисленным комьюнити, обычно доверяют. Если же нет возможности выложить код в опенсорс и потратить время на полноценное документирование, то можно хотя бы прокомментировать код и сделать маленькое описание рядом в текстовом файле, а потом дать коллегам посмотреть. Это не занимает много времени, зато ваш последователь 2 раза подумает, прежде чем выкинуть ваш ящик с тем, чтобы заменить его своим.
В чем свзяь паттерна адаптер и тех проблем с черными ящиками, которые вы обозначили?
Адаптер, Adapter или Wrapper/Обёртка — структурный шаблон проектирования, предназначенный для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс
В данном случае «недоступный» в смысле — неохота разбираться с ним. Но выше мы уже выяснили что больше подходит определение паттерна «фасад».
В данном случае «недоступный» в смысле — неохота разбираться с ним. Но выше мы уже выяснили что больше подходит определение паттерна «фасад».
Уфф, смешелись в кучу кони, люди.
Инкапсуляция сама по себе не есть проблема, — это директива на уменьшение связанности фрагментов кода и локализации деталей, связанных с конкретной реализацией.
Вы, применив паттерн фасада увеличили степень инкапсуляции, так как бОльшее количество деталей реализации оказалось скрытыми и уменьшалась связанность. В итоге было продемонстрировано как инкапсуляция решает проблему, а не создает.
Инкапсуляция сама по себе не есть проблема, — это директива на уменьшение связанности фрагментов кода и локализации деталей, связанных с конкретной реализацией.
Вы, применив паттерн фасада увеличили степень инкапсуляции, так как бОльшее количество деталей реализации оказалось скрытыми и уменьшалась связанность. В итоге было продемонстрировано как инкапсуляция решает проблему, а не создает.
в начале статьи «инкапсуляция это ууу плохо», и в конце — «инкапсуляция» как метод борьбы с инкапсуляцией. Вы правда не видите подвоха? Проблема с вашим кодом вовсе не в инкапсуляции
Если тут про юнит тесты имеется ввиду, то странно писать тесты для полученного класса при отсутствии тестов для класса, с которым он взаимодействует… Тот большой класс наверняка можно протестировать, а потом отрефакторить. Если есть код и есть возможность его менять, то нужно это делать, когда возникает необходимость. А так да, про фасад уже сказали.
В общем, тут в кучу смешались шаблоны проектирования и тестирование кода, поэтому возник такой комментарий. На самом деле нельзя написать тесты к тому, что получилось, потому что нет тестов к тому большому классу, а соответственно, неизвестно его поведение в различных ситуациях.
В общем, тут в кучу смешались шаблоны проектирования и тестирование кода, поэтому возник такой комментарий. На самом деле нельзя написать тесты к тому, что получилось, потому что нет тестов к тому большому классу, а соответственно, неизвестно его поведение в различных ситуациях.
А в различных и не надо, надо в нужных для приложения. И тесты будут не юнит, а интеграционные или функциональные, пускай и с помощью того же инструментария, что и юнит. Если нужные тесты не проходят, например не выбрасывается исключение при отсутствии файла или его недоступности на запись, то пишем throw в своём фасаде, не трогая чужой код. Также поступаем со всеми остальными исключительными случаями, а что там в этом классе происходит нас мало интересует, если функциональный тест проходит. Правда не знаю, можно ли его в таком случае ещё называть фасадом.
тоже как то сам на это набрёл.
цель была сократить количество вызываемых методов, то бишь упростить код «бизнес-логики», в частности проверка не пуст ли лист, прежде чем выбирать элементы, в т.ч. чтоб ексепшен исключить в «нормальном» режиме, плюс встроил энумератор чтоб можно было foreach делать сразу с нужным типом. и т.п.
к примеру XmlDocument так под себя затачивал.
вобщем то мне кажется оно так и должно быть — исходные классы могут быть сколь угодно сложны и намудрены, и опять же каждый класс имеет свой вид «общения» с тем, кто его пользует.
а тот, кто задумал пользовать эти классы, причем они могут быть все от разных разработчиков, с разными интерфейсами, просто пишет для них обертки в нужном ему виде, униформирует интерфейс, упрощает и т.п.
цель была сократить количество вызываемых методов, то бишь упростить код «бизнес-логики», в частности проверка не пуст ли лист, прежде чем выбирать элементы, в т.ч. чтоб ексепшен исключить в «нормальном» режиме, плюс встроил энумератор чтоб можно было foreach делать сразу с нужным типом. и т.п.
к примеру XmlDocument так под себя затачивал.
вобщем то мне кажется оно так и должно быть — исходные классы могут быть сколь угодно сложны и намудрены, и опять же каждый класс имеет свой вид «общения» с тем, кто его пользует.
а тот, кто задумал пользовать эти классы, причем они могут быть все от разных разработчиков, с разными интерфейсами, просто пишет для них обертки в нужном ему виде, униформирует интерфейс, упрощает и т.п.
UFO just landed and posted this here
Sign up to leave a comment.
Проблемы инкапсуляции