Проблема в том, что на второй картинке тоже плохая фотография.
что используют профи предметной съемки, чтобы делать такие красивые фотографии? Они используют различные варианты лайтбоксов
Это не так. Лайтбокс — это решение для ленивых людей, которые не хотят выставлять свет под каждый предмет отдельно. Когда хотят получить красивую фотографию — берут и строят нормальное освещение.
Во-первых, можно ссылку на документацию по интерфейсу IComponent и что там еще. IComponent IContainer
Во-вторых, пример, очень даже показывает как именно клиент единообразно трактует разные вещи (вызывая value()).
Само по себе это не является свойством Composite, это свойство любого интерфейса.
Основное определяющее свойство Composite — возможность работать с группой объектов так же, как с одним объектом. То есть, если я могу сказать graph.Paint(), то я могу сказать и graphComposite.Paint() (вместо foreach(graph in graphComposite) graph.Paint;). По сути, подмена коллекции композитом. И все.
Отсюда никак не вытекает, что у graph должны быть методы graphComposite.
Да причем здесь выгода?
Да при том, что любое архитектурное решение — всегда баланс плюсов и минусов. Для того, чтобы успешно их применять, надо понимать, что ты приобретаешь, а что теряешь.
Я просто слишком часто вынужден объяснять разработчикам, почему нельзя бездумно копировать то, что написано в Великой Библии Четырех.
Да, я верю, что может быть кто-то придумает (да скорее всего уже придумал) более рациональный механизм работы с древовидной структурой, но об этом знает только он и может быть небольшая группа разработчиков.
Угу. Windows.Forms — черезвычайно малоизвестная реализация. И очень маленькая группа разработчиков.
Спорим мы о том, что ваш пример нифига не показывает, что такое паттерн Composite, зачем его применять, и в чем его выгода.
Все потому, что клиент (класс Main) правильно работает со структурой.
И он же прекрасно показывает, что терминальным узлам структуры методы удаления и добавления не нужны. Прекрасно бы обошлось Expression {Number value}, при этом полностью сохранив логику.
Но виноват в этом — клиент (по отношению к паттерну).
Вот в этом и состоит фундаментальное различие между нашими подходами. Я считаю хорошей архитектурой ту, где минимизирована возможность ошибки.
Все потому, что клиент (класс Main) правильно работает со структурой.
Да почти все современные фраемверки отрисковки интерфейса построены на данном паттерне. Более того, явный пример про Swing (JComponent) я Вам привел.
Вы путаете. Я просил пример, где это нужно, а не где это реализовано. Желательно, с объяснением, зачем.
Потому как прекрасно существует Windows Forms, в котором есть IComponent и IContainer.
То-есть по Вашему, в правильной архитектуре нет места обработке исключений?
Ровно наоборот. В правильной архитектуре максимум исключительных ситуаций должен быть обработан. Но это не значит, что штатные операции должны порождать исключительные ситуации.
Понимаете, в чем проблема — «ожидаемый exception» приводит к тому, что обработка исключений усложняется. Мы не можем просто перехватить все исключения и обработать их единообразно, даже если это позволяет сценарий, мы вынуждены делать частный случай для того исключения, которое «кидается штатно», и проверять в нем набор дополнительных условий. Это просто неудобно. Это порождает лишний нечитаемый код.
У меня right now есть внешняя система, единственный способ проверить наличие элемента с заданным ключом в которой — это обратиться по этому ключу и получить exception, если элемента нет. Никаких Contains или TryGet.
Реальных сценариев я думаю предостаточно в GoF они обозначены.
Можете привести хотя бы один?
Я согласен с тем, что обработка исключений достаточно дорогостоящая операция, но не на столько чтобы жертвовать ради этого прозрачной архитектурой системы.
Пойнт ровно в обратном. В правильной архитектуре не должно быть обработки эксепшна в штатной ситуации — эксепшн на то и эксепшн, что ситуация нештатная. Архитектура, в которой мы ждем, что нам кинут эксепшн, и в зависимости от этого предпринимаем действия — непрозрачная и неудобная.
Чтобы получать «реальные цвета» и «реальную экспозицию», кубика мало. Для цветов нужна калибровочная плашка (бывший макбет, теперь x-rite), и по нему строить профиль (который прекрасно понимается LR, кстати), для экспозиции — серая шкала плюс экспонометр.
Чтобы получать «красивую картинку», кубик просто нафиг не нужен.
«я тоже за то, чтобы например используемое в госсайтах шифрование использовало OpenSource технологии»
А вы уже видели сертифицированную реализацию шифрования по ГОСТ, кажется, 34-10?
«Там каждый знает что делает и кто за что отвечает на всех уровнях. „
Именно поэтому в некоторых больших компаниях так модно делать не больше своей формальной работы, при любом удобном случае сваливать задачу в чужую компетенцию и так далее.
что используют профи предметной съемки, чтобы делать такие красивые фотографии? Они используют различные варианты лайтбоксов
Это не так. Лайтбокс — это решение для ленивых людей, которые не хотят выставлять свет под каждый предмет отдельно. Когда хотят получить красивую фотографию — берут и строят нормальное освещение.
Отсюда и вывод — голову надо применять.
IComponent
IContainer
Во-вторых, пример, очень даже показывает как именно клиент единообразно трактует разные вещи (вызывая value()).
Само по себе это не является свойством Composite, это свойство любого интерфейса.
Основное определяющее свойство Composite — возможность работать с группой объектов так же, как с одним объектом. То есть, если я могу сказать graph.Paint(), то я могу сказать и graphComposite.Paint() (вместо foreach(graph in graphComposite) graph.Paint;). По сути, подмена коллекции композитом. И все.
Отсюда никак не вытекает, что у graph должны быть методы graphComposite.
Да причем здесь выгода?
Да при том, что любое архитектурное решение — всегда баланс плюсов и минусов. Для того, чтобы успешно их применять, надо понимать, что ты приобретаешь, а что теряешь.
Я просто слишком часто вынужден объяснять разработчикам, почему нельзя бездумно копировать то, что написано в Великой Библии Четырех.
Угу. Windows.Forms — черезвычайно малоизвестная реализация. И очень маленькая группа разработчиков.
Спорим мы о том, что ваш пример нифига не показывает, что такое паттерн Composite, зачем его применять, и в чем его выгода.
И он же прекрасно показывает, что терминальным узлам структуры методы удаления и добавления не нужны. Прекрасно бы обошлось Expression {Number value}, при этом полностью сохранив логику.
Вот в этом и состоит фундаментальное различие между нашими подходами. Я считаю хорошей архитектурой ту, где минимизирована возможность ошибки.
Все потому, что клиент (класс Main) правильно работает со структурой.
Вы путаете. Я просил пример, где это нужно, а не где это реализовано. Желательно, с объяснением, зачем.
Потому как прекрасно существует Windows Forms, в котором есть IComponent и IContainer.
То-есть по Вашему, в правильной архитектуре нет места обработке исключений?
Ровно наоборот. В правильной архитектуре максимум исключительных ситуаций должен быть обработан. Но это не значит, что штатные операции должны порождать исключительные ситуации.
Понимаете, в чем проблема — «ожидаемый exception» приводит к тому, что обработка исключений усложняется. Мы не можем просто перехватить все исключения и обработать их единообразно, даже если это позволяет сценарий, мы вынуждены делать частный случай для того исключения, которое «кидается штатно», и проверять в нем набор дополнительных условий. Это просто неудобно. Это порождает лишний нечитаемый код.
У меня right now есть внешняя система, единственный способ проверить наличие элемента с заданным ключом в которой — это обратиться по этому ключу и получить exception, если элемента нет. Никаких Contains или TryGet.
Можете привести хотя бы один?
Я согласен с тем, что обработка исключений достаточно дорогостоящая операция, но не на столько чтобы жертвовать ради этого прозрачной архитектурой системы.
Пойнт ровно в обратном. В правильной архитектуре не должно быть обработки эксепшна в штатной ситуации — эксепшн на то и эксепшн, что ситуация нештатная. Архитектура, в которой мы ждем, что нам кинут эксепшн, и в зависимости от этого предпринимаем действия — непрозрачная и неудобная.
Не говоря уже о том, что придумайте мне реальный сценарий, где надо, чтобы у leaf-nodes обязательно был тот же интерфейс?
Опыт показывает, что чем обрабатывать эксепшны, намного дешевле делать несколько интерфейсов и проверять, чем именно является узел.
А вообще, конечно, Composite лучше всего подходит для иерархий, где просто нет заведомо терминальных узлов.
Чтобы получать «красивую картинку», кубик просто нафиг не нужен.
www.google.com/support/a/bin/static.py?page=contacting_support.html
Казалось бы, все сразу написано. Страница доступна в два, что ли, клика со страницы Support в Domain management.
Если быть педантичным, то «dots per inch».
И это, учитывая, что мы были обязаны использовать этот ГОСТ в системе, наводит меня на мысли, что сертифицированных-то открытых реализаций и нет.
А вы уже видели сертифицированную реализацию шифрования по ГОСТ, кажется, 34-10?
Именно поэтому в некоторых больших компаниях так модно делать не больше своей формальной работы, при любом удобном случае сваливать задачу в чужую компетенцию и так далее.