Классы-посредники

Читая Дейтла, дошел до теемы классы-посредники, назначение которых скрыть не только реализацию, но и интерфейс класса (в том смысле, как я понял, чтобы пользователь класса просто не видел физически заголовочный файл класса).
Так ли уж ценна эта идея, искусственно накручивания скрытия всего и вся?

0

Сообщение от BRcr убираем кнопку непрерывного сверления(мешает иногда и не нужна никогда) и прикручиваем к ней миниатюрный уровень, чтоб сверлить ровно, у нас с головой все, надеюсь, в порядке?

Уровень не жалко? Уровни бояццо ударов и сотрясений. Вибрация от дрели могут повредить уровень.
К тому же, если примотать к дрельке уровень, то она от этого перфоратором не станет.

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

А почему вы этого не делаете? Да потому что вам нужно делать работу - нужно дырки сверлить, а не издеваться над несчастной дрелью.

За издевательства над инструментами вам никто не заплатит.
Платят за решение конкретных задач.

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

0

Bers, Это конечно все прекрасно. Но мир не столь совершенен. И даже библиотеки хорошие во всех смыслах приходится допиливать под конкретные нужды. Не приходилось?

0

Сообщение от ForEveR Bers, Это конечно все прекрасно. Но мир не столь совершенен. И даже библиотеки хорошие во всех смыслах приходится допиливать под конкретные нужды. Не приходилось?

Нет. Не приходилось.
Приходилось перепиливать собственные библиотечные коды. Но не чужие.
Мне бы в голову не пришло, залазить вовнутрь чужой библиотеки, и перепиливать её под собственные нужды.

Если инструмент не отвечает требованиям к задаче, проще заменить сам инструмент, чем лезть в его внутренности, и потрошить тамошний код.

Хотя я ничего не имею против усовершенствования собственного библиотечного кода, если вдруг вызывающей стороне потребовались какие то дополнительные услуги. Но в данном случае, как разработчик библиотеки, я имею все основания полагать, что справлюсь с этим усовершенствованием корректно.

0

Bers, Ну тогда еще придется. Вот есть библиотека. По всем критериям она подходит. Но жрет непомерно много памяти, а все потому что внутри используется дек, хотя с тем же успехом может использоваться список. И вот при том коде приложение жрет 3 гига памяти и падает, а заменив внутри библиотеки деку на лист - оно жрет 1 гиг памяти и отрабатывает корректно. Неплохой профит, м?
А если еще и распределение памяти поменять, прикрутив свой аллокатор так вообще шикарно будет.

Ты живешь в каком-то слишком идеальном мире на мой взгляд, если считаешь, что допиливание чужой либы - это некорректно.

0

Сообщение от ForEveR Bers, Ну тогда еще придется. Вот есть библиотека. По всем критериям она подходит. Но жрет непомерно много памяти, а все потому что внутри используется дек, хотя с тем же успехом может использоваться список. И вот при том коде приложение жрет 3 гига памяти и падает, а заменив внутри библиотеки деку на лист - оно жрет 1 гиг памяти и отрабатывает корректно. Неплохой профит, м?

Если она жрёт непомерно много памяти, а память - один из критериев, значит уже не подходит.
Если подходит - значит заказчика не парит, сколько памяти она скушает в его проекте.

Можно конечно запилить инструмент под собственные требования. И потерять на этом кучу времени. А можно сразу выбрать подходящий инструмент. Обычно так и поступают люди.

Я понимаю, что мир несовершенен, а мои выкладки слишком идеалистичны, но вот я расскажу про пример из реальной жизни:


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

Однако, мне показалось намного удобнее, не использовать услуги Короны напрямую, а сделать класс-обертку для неё. Что бы мой проект работал с короной только через эту обёртку.
Я дал методам обёртки более понятные имена, да и работать с объектом класса в ОО-архитектуре мне тогда казалось, более удобно, чем через си-style интерфейс.

Я ещё тогда по неопытности не знал, что оказал себе грандиозную услугу.

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

Сама по себе Корона такую услугу уже не предоставляла.

Что делать?

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

Это что получается, я хотел использовать библиотеку, что бы не тратить время на загрузки/сохраниловки. А теперь, вместо этого, мне придётся изучать код чужой библиотеки, и что-то там допиливать?????!!!!!

Так если б я знал, что так будит, я бы вообще бы отказался от Короны.

И вот тут я понял всю глубину таких вещей, как например, идима pImpl

Мой проект ничего не знал ни о какой Короне. Он работал только с классом-обёрткой.
Значит я в любой момент мог заменить Корону на другой инструмент, заменив лишь реализацию класса-обёртки. Мой проект даже не заметил бы подмены!

Что я и сделал. Вместо короны пересел на DevIL, который лучше отвечал требованиям к моим задачам. И не знал никаких проблем.

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

Конечно, это пример довольно оторванный от "реального несовершенного мира".

А в реальном несовершенном мире, в конторах стараются делать быстро, и экономят на архитектуре проектов.

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

0

Bers, Интересный пример. Но все-таки моя точка зрения остается прежней. При необходимости - не грех допилить сторонние библиотеки.

0

Сообщение от ForEveR Bers, Интересный пример. Но все-таки моя точка зрения остается прежней. При необходимости - не грех допилить сторонние библиотеки.

Смысл не в том, грех это, или не грех.

А в том, нужно это или нет? Потому что изучение чужого кода, внесение поправок, и тестирование - это очень много времени. Времени, которое тратится на решение ЧУЖОЙ задачи.

В то время, как заказчик платит за решение ЕГО задачи.

0

Bers, Не согласен про время. Иногда это нужно. Я же не говорю переписывать все либы под свои нужды. Но иногда нужно и переписать.

0