Заблокирован
|
|
1 | |
Классы-посредники24.11.2011, 00:05. Показов 2457. Ответов 27
Метки нет (Все метки)
Читая Дейтла, дошел до теемы классы-посредники, назначение которых скрыть не только реализацию, но и интерфейс класса (в том смысле, как я понял, чтобы пользователь класса просто не видел физически заголовочный файл класса).
Так ли уж ценна эта идея, искусственно накручивания скрытия всего и вся?
0
|
24.11.2011, 00:05 | |
Ответы с готовыми решениями:
27
Непонятна тема (Классы содержащие другие классы, как данные члены ) Программа по классам, которая использует классы точек и прямых на плоскости, а, возможно, и другие классы Как struct Queue и его операции превратить в классы, то есть нужно сделать тоже самое, но через классы Наследование, базовые классы и производные классы |
Заблокирован
|
|
24.11.2011, 13:40 | 21 |
Уровень не жалко? Уровни бояццо ударов и сотрясений. Вибрация от дрели могут повредить уровень.
К тому же, если примотать к дрельке уровень, то она от этого перфоратором не станет. Приматывая уровень к дрельке, вы делаете композицию. То бишь, получаете новый инструмент, за счет добавления к нему уровня. Но вы же при этом не разбираете существующую дрельку. Не залазиете в её внутренности. Ничего там не меняете, что бы она у вас как то по другому сверлить начала. А почему вы этого не делаете? Да потому что вам нужно делать работу - нужно дырки сверлить, а не издеваться над несчастной дрелью. За издевательства над инструментами вам никто не заплатит. Платят за решение конкретных задач. А если очень нужно гарантировать точной наклон сверла при сверлении, то можно воспользоваться специализированным инструментом, а не изобретать заново велосипед.
0
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
24.11.2011, 13:42 | 22 |
Bers, Это конечно все прекрасно. Но мир не столь совершенен. И даже библиотеки хорошие во всех смыслах приходится допиливать под конкретные нужды. Не приходилось?
0
|
Заблокирован
|
|
24.11.2011, 13:48 | 23 |
Нет. Не приходилось.
Приходилось перепиливать собственные библиотечные коды. Но не чужие. Мне бы в голову не пришло, залазить вовнутрь чужой библиотеки, и перепиливать её под собственные нужды. Если инструмент не отвечает требованиям к задаче, проще заменить сам инструмент, чем лезть в его внутренности, и потрошить тамошний код. Хотя я ничего не имею против усовершенствования собственного библиотечного кода, если вдруг вызывающей стороне потребовались какие то дополнительные услуги. Но в данном случае, как разработчик библиотеки, я имею все основания полагать, что справлюсь с этим усовершенствованием корректно.
0
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
24.11.2011, 13:54 | 24 |
Bers, Ну тогда еще придется. Вот есть библиотека. По всем критериям она подходит. Но жрет непомерно много памяти, а все потому что внутри используется дек, хотя с тем же успехом может использоваться список. И вот при том коде приложение жрет 3 гига памяти и падает, а заменив внутри библиотеки деку на лист - оно жрет 1 гиг памяти и отрабатывает корректно. Неплохой профит, м?
А если еще и распределение памяти поменять, прикрутив свой аллокатор так вообще шикарно будет. Ты живешь в каком-то слишком идеальном мире на мой взгляд, если считаешь, что допиливание чужой либы - это некорректно.
0
|
Заблокирован
|
|
24.11.2011, 14:30 | 25 |
Если она жрёт непомерно много памяти, а память - один из критериев, значит уже не подходит.
Если подходит - значит заказчика не парит, сколько памяти она скушает в его проекте. Можно конечно запилить инструмент под собственные требования. И потерять на этом кучу времени. А можно сразу выбрать подходящий инструмент. Обычно так и поступают люди. Я понимаю, что мир несовершенен, а мои выкладки слишком идеалистичны, но вот я расскажу про пример из реальной жизни: Мне на домашнем небольшом проектике нужна была либа, с помощью которой можно было бы грузить/сохранять картинки разных форматов. Причем, я специально хотел задействовать либу, что бы самому не изучать форматы графических файлов, и не тратить времени на создание очередного враппера картинок. Выбор остановил на Короне. Простая в использовании, и легковесная, она по началу полностью отвечала моим требованиям. Однако, мне показалось намного удобнее, не использовать услуги Короны напрямую, а сделать класс-обертку для неё. Что бы мой проект работал с короной только через эту обёртку. Я дал методам обёртки более понятные имена, да и работать с объектом класса в ОО-архитектуре мне тогда казалось, более удобно, чем через си-style интерфейс. Я ещё тогда по неопытности не знал, что оказал себе грандиозную услугу. В последствии, мне потребовались от библиотеки дополнительные услуги. Например - возможность сохранить графический уже запакованный файл не на ндд, а в память, для последующей обработки уже ужатых данных. Сама по себе Корона такую услугу уже не предоставляла. Что делать? Я задал этот вопрос старшим товарищам. Их ответ: Корона же с открытым исходным кодом. Поковыряй её сорцы, и прицепи к ней дополнительную фичу. Будит у тебя более продвинутая версия Короны. Это что получается, я хотел использовать библиотеку, что бы не тратить время на загрузки/сохраниловки. А теперь, вместо этого, мне придётся изучать код чужой библиотеки, и что-то там допиливать?????!!!!! Так если б я знал, что так будит, я бы вообще бы отказался от Короны. И вот тут я понял всю глубину таких вещей, как например, идима pImpl Мой проект ничего не знал ни о какой Короне. Он работал только с классом-обёрткой. Значит я в любой момент мог заменить Корону на другой инструмент, заменив лишь реализацию класса-обёртки. Мой проект даже не заметил бы подмены! Что я и сделал. Вместо короны пересел на DevIL, который лучше отвечал требованиям к моим задачам. И не знал никаких проблем. Вот если бы я внешнею библиотеку бы хардкорно использовал везде, где были нужны её услуги, то везде мне пришлось бы править код при попытке перейти на другой инструмент. Конечно, это пример довольно оторванный от "реального несовершенного мира". А в реальном несовершенном мире, в конторах стараются делать быстро, и экономят на архитектуре проектов. А потом оказывается, что целевой проект настолько сильно завязан на внешних библиотеках, что проще и быстрее допилить сами эти библиотеки, чем пытаться перевести проект на использование других, более адекватных инструментов.
0
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
24.11.2011, 14:43 | 26 |
Bers, Интересный пример. Но все-таки моя точка зрения остается прежней. При необходимости - не грех допилить сторонние библиотеки.
0
|
Заблокирован
|
|
24.11.2011, 14:45 | 27 |
Смысл не в том, грех это, или не грех.
А в том, нужно это или нет? Потому что изучение чужого кода, внесение поправок, и тестирование - это очень много времени. Времени, которое тратится на решение ЧУЖОЙ задачи. В то время, как заказчик платит за решение ЕГО задачи.
0
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
24.11.2011, 14:52 | 28 |
Bers, Не согласен про время. Иногда это нужно. Я же не говорю переписывать все либы под свои нужды. Но иногда нужно и переписать.
0
|
24.11.2011, 14:52 | |
24.11.2011, 14:52 | |
Помогаю со студенческими работами здесь
28
Классы и наследование (Создать класс 3D фигура, и производные классы шар, конус, цилиндр и куб. Создать функцию вычисления объёма.) Классы возможностей(Mixin классы) классы/дочерние классы/методы Классы, включающие другие классы Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |