в добавление к первому пункту.
я часто использую аннотации в inner-классах. Тогда вся логика в одном месте и всё понятно.
Но это не бизнес логика, это вспомогательные фичи на отображение данных
я тоже согласен!
Сейчас правлю большой проект (~ 10000 классов). и там рефлекшен. Отлаживать это — просто ад. Ходишь по коду при помощи полнотекстового поиска. и по другому никак.
добавлю свои мысли:
1. между интерфейсом и аннотациями должен быть баланс. Взаимодействие двух модулей — это обычно интерфейс. Реже аннотации в классе, чтобы не плодить не нужную иерархию интерфейсов
2. нельзя, понимаете, нельзя делать на аннотация что-то большое и сложное. Часто люди увлекаются и делают монстра с полу-динамическим кодом. Для больших проектов — это большое зло, там уследить за всем практически сложно, помогает статический анализ, а рефлекшен убивает статику.
буча читал.
класс — это тип объекта.
есть понятие инкапсюляции. мега важное, оно определяет объект, как сущность определенного единого поведения. Иногда для поведения нужны ещё и данные, но не обязательно.
Насколько я понял, в статье активно предлагаются вариант 1 и вариант 2.
Для простых систем так и надо делать, не нужно усложнять себе жизнь, тяжело поддерживать сразу несколько иерархий, особенно там, где они особо не нужны.
Применяя партены, главное не увлекаться. Если решено сделать несколько классов, вместо одного, то это должно быть сделано ради чего-то, а не для того, чтобы просто применить партен
и так задача:
имеется предметная область.
машина, марки машины, цвета, габариты, другие не важные характеристики, двигатели, мощность двигателей, разные мат. модели описывающие движение машины (физика)
Надо всё это описать, отрендерить красиво и тому подобное…
проектируем 1 вариант
заводим базовый класс машина, по матрешке нагручиваем наследование, куда кладем конкретные реализации.
Если классов мало, то вроде как так можно делать, но количество разных комбинаций растет лавинообразно. С этим нужно что-то делать!
Для машин так же может быть какая-то иерархия, которая будет мешаться нашей. Это вторая проблема.
2 вариант
вводим класс машина, а в него кидаем кучу подобъектов:
характеристики марки, физика и тому подобное
Фактически мы активно использовали делегирование
У характеристик создаем параллельные иерархии. Получаем фактически патерн стратегия.
В чем сложность такого подхода? Может так случиться, что внутренние объекты активно взаимодействуют между собой, причем они не крупные. Было бы удобно не городить кучу мелких объектов, а сделать один большой. То есть всё, зависит от задачи.
3 вариант
часть характеристик, необходимых для управления, живут в объекте машина.
часть характеристик, необходимых для реализации, живут в объекте реализация машины.
получается мост в примитиве. А если для машин сделаем свои иерархии, то получится прямо настоящий мост.
какая ответственность машины? принять управляющие воздействия, отработать бизнес-логику по обработке управляющих воздействий, изменить их и передать реализации.
то есть машина хранит в себе общий поведенческий фактор. это крупная абстракция.
какая ответственность у реализации машины? принять обработанные управляющие воздействия, отрендерить, посчитать и тому подобное.
реализация машины хранит в себе частный поведенческий фактор. это абстракция более низкого уровня.
В программе удобно обращаться к абстракциям высокого уровня, не задумываясь при этом об абстракциях низкого уровня.
Тут всё сложнее.
Не хочется применять мост, не нужно, тут в рамки никто никого не загоняет.
На применение моста есть свои ограничения.
ИХМО, это один из самых сложных партенов.
в Том же GoF прописано зачем они это делают и когда имеет смысл делать это, а когда не стоит.
Разделение моста — не является нарушением принципа ответственности.
у верней иерархии ответственность крупной абстракции
у нижней — ответственность реализации (которых может быть много)
Это не так. множественное наследование само по себе не нарушает принципа единой ответственности.
Нарушает его программист при помощи этой возможности языка.
С таким же успехом можно сказать, что добавление методов в класс нарушает принцип единственности ответственности.
Перечитал по этому кучу популярных книг GoF, Макконел, Фаулер ....(и ещё штук 20)
везде натыкался на одну мысль, доводимую разными способами.
1. чем крупнее абстракция, тем лучше (уровень «крупноты» выбирает программист на основе задачи и мироощущении — есть даже рекомендации как это сделать, читайте Макконела)
2. чем проще абстракция, тем лучше
«Мост» не костыль, а лишь средство упростить сложную абстракцию, осуществив делегирование полномочий параллельной иерархии объектов. Таким образом одну большую и сложную иерархию абстракций можно разбить как бы на две маленьких, которые если вместе скрестить, то получится одна большая (срабатывает эффект «как бы произведения абстракций» — это мой термин, чтобы было понятнее о чем я говорю)
Это позволит в разы сократить дублировании всякой логики при построении большой иерархии.
Классический пример в GoF с редактором и разными оконными системами.
Двигатель с машиной, который обсуждался раньше — пример менее удачный. правильнее было б вводить вводить абстракцию машина (стоит, движется, имеет скорость) и делегировании физики машины в конкретную модель. Зачем полезли во внутренности и прочие вещи, я так и не понял.
Своих примеров приводить не буду, их до меня было достаточно.
А теперь от теории к практике, применял мост в паре сложных проектов(с нуля и при рефакторинге), удалось значительно упростить код и сократить его раза в 3 где-то.
Автору статьи рекомендую сначала перечитать макконела совершенный код, потом SOLID принципы (о которых кстати, говорится в макконеле), а потом уже перечитывать GoF.
Такие вещи нужно проверять в логике объектов там, где это важно. К обмену данными они особого отношения не имеют.
Объекты, которые мы передаем, могут быть и бизнес объектами, или их производными (объекты, которые содержат лишь часть данных бизнес объекта, нужных для передачи).
У меня чаще всего получались производные, а у объекта бизнес логики были методы типа setSubObjectData и getSubObjectData
И ещё раз повторюсь, речь идет о том, чтобы снизить трудоемкость.
Если проект не очень большой, и не очень сложный, то быстрее будет сделать на чем-нибудь готовом. Тот же SOAP в java делается в пару аннотаций в классе для jdk6.
В том же EJB последних версиях тоже есть возможность делать контейнеры-вебсервисы в одну строчку.
Что лучше, написать кучу мапперов, роутеров урлов. и прочее… Ведь их же писать нужно. Что лучше 1 строка или 300 строк? Что будет быстрее разработать? Где будет меньше ошибок?
Если нет каких либо сложных проблем использованием SOAP, то такой путь чуть быстрее. Можно сократить время разработки-отладки.
Велосипеды нынче не в почете, а ещё они могут ломаться.
А начальство ох как этого не любит, при каждой поломке начинает ныть, мол нужно было использовать стандартную или такую-то чужую. Вот приходится взвешивать что лучше чужая или своя самописная…
Какую-нибудь прослойку, которую можно спросить что-то типа.
— вот тебе ID, дай мне объект.
— или на тебе объект, иди и сохрани его.
— или вот тебе критерии, дай мне массив объектов
— или дай мне массив всех объектов
Причем объекты мы можем написать сами или получить их из того же WADL. Там же мы получим и урлы да параметры, по которым нужно обращаться.
Для Ruby есть прикольная библиотека ActiveResource. Построена по принципу шаблона проектирования ActiveRecord. Использовать приблизительно так же.
На Java RestTemplate от Spring. Чтобы там получать и отсылать сложные объекты, нужно их маппить в XML. Маппинг приходится описывать отдельно.
я часто использую аннотации в inner-классах. Тогда вся логика в одном месте и всё понятно.
Но это не бизнес логика, это вспомогательные фичи на отображение данных
Сейчас правлю большой проект (~ 10000 классов). и там рефлекшен. Отлаживать это — просто ад. Ходишь по коду при помощи полнотекстового поиска. и по другому никак.
добавлю свои мысли:
1. между интерфейсом и аннотациями должен быть баланс. Взаимодействие двух модулей — это обычно интерфейс. Реже аннотации в классе, чтобы не плодить не нужную иерархию интерфейсов
2. нельзя, понимаете, нельзя делать на аннотация что-то большое и сложное. Часто люди увлекаются и делают монстра с полу-динамическим кодом. Для больших проектов — это большое зло, там уследить за всем практически сложно, помогает статический анализ, а рефлекшен убивает статику.
ведь в С++ нет интерфейсов, там только классы
класс — это тип объекта.
есть понятие инкапсюляции. мега важное, оно определяет объект, как сущность определенного единого поведения. Иногда для поведения нужны ещё и данные, но не обязательно.
Для простых систем так и надо делать, не нужно усложнять себе жизнь, тяжело поддерживать сразу несколько иерархий, особенно там, где они особо не нужны.
Применяя партены, главное не увлекаться. Если решено сделать несколько классов, вместо одного, то это должно быть сделано ради чего-то, а не для того, чтобы просто применить партен
имеется предметная область.
машина, марки машины, цвета, габариты, другие не важные характеристики, двигатели, мощность двигателей, разные мат. модели описывающие движение машины (физика)
Надо всё это описать, отрендерить красиво и тому подобное…
проектируем
1 вариант
заводим базовый класс машина, по матрешке нагручиваем наследование, куда кладем конкретные реализации.
Если классов мало, то вроде как так можно делать, но количество разных комбинаций растет лавинообразно. С этим нужно что-то делать!
Для машин так же может быть какая-то иерархия, которая будет мешаться нашей. Это вторая проблема.
2 вариант
вводим класс машина, а в него кидаем кучу подобъектов:
характеристики марки, физика и тому подобное
Фактически мы активно использовали делегирование
У характеристик создаем параллельные иерархии. Получаем фактически патерн стратегия.
В чем сложность такого подхода? Может так случиться, что внутренние объекты активно взаимодействуют между собой, причем они не крупные. Было бы удобно не городить кучу мелких объектов, а сделать один большой. То есть всё, зависит от задачи.
3 вариант
часть характеристик, необходимых для управления, живут в объекте машина.
часть характеристик, необходимых для реализации, живут в объекте реализация машины.
получается мост в примитиве. А если для машин сделаем свои иерархии, то получится прямо настоящий мост.
какая ответственность машины? принять управляющие воздействия, отработать бизнес-логику по обработке управляющих воздействий, изменить их и передать реализации.
то есть машина хранит в себе общий поведенческий фактор. это крупная абстракция.
какая ответственность у реализации машины? принять обработанные управляющие воздействия, отрендерить, посчитать и тому подобное.
реализация машины хранит в себе частный поведенческий фактор. это абстракция более низкого уровня.
В программе удобно обращаться к абстракциям высокого уровня, не задумываясь при этом об абстракциях низкого уровня.
вроде как ничего не упустил.
Не хочется применять мост, не нужно, тут в рамки никто никого не загоняет.
На применение моста есть свои ограничения.
ИХМО, это один из самых сложных партенов.
в Том же GoF прописано зачем они это делают и когда имеет смысл делать это, а когда не стоит.
Разделение моста — не является нарушением принципа ответственности.
у верней иерархии ответственность крупной абстракции
у нижней — ответственность реализации (которых может быть много)
Нарушает его программист при помощи этой возможности языка.
С таким же успехом можно сказать, что добавление методов в класс нарушает принцип единственности ответственности.
«Это недостаточно точно декомпозирует систему»
а что эта фраза значит, я вообще не понял… поясните.
в чем правильность?
то, предлагаете заменить тот же мост простым множественным наследованием.
или я чего не понял?
Хочу добавить от себя пару замечаний.
Перечитал по этому кучу популярных книг GoF, Макконел, Фаулер ....(и ещё штук 20)
везде натыкался на одну мысль, доводимую разными способами.
1. чем крупнее абстракция, тем лучше (уровень «крупноты» выбирает программист на основе задачи и мироощущении — есть даже рекомендации как это сделать, читайте Макконела)
2. чем проще абстракция, тем лучше
«Мост» не костыль, а лишь средство упростить сложную абстракцию, осуществив делегирование полномочий параллельной иерархии объектов. Таким образом одну большую и сложную иерархию абстракций можно разбить как бы на две маленьких, которые если вместе скрестить, то получится одна большая (срабатывает эффект «как бы произведения абстракций» — это мой термин, чтобы было понятнее о чем я говорю)
Это позволит в разы сократить дублировании всякой логики при построении большой иерархии.
Классический пример в GoF с редактором и разными оконными системами.
Двигатель с машиной, который обсуждался раньше — пример менее удачный. правильнее было б вводить вводить абстракцию машина (стоит, движется, имеет скорость) и делегировании физики машины в конкретную модель. Зачем полезли во внутренности и прочие вещи, я так и не понял.
Своих примеров приводить не буду, их до меня было достаточно.
А теперь от теории к практике, применял мост в паре сложных проектов(с нуля и при рефакторинге), удалось значительно упростить код и сократить его раза в 3 где-то.
Автору статьи рекомендую сначала перечитать макконела совершенный код, потом SOLID принципы (о которых кстати, говорится в макконеле), а потом уже перечитывать GoF.
Объекты, которые мы передаем, могут быть и бизнес объектами, или их производными (объекты, которые содержат лишь часть данных бизнес объекта, нужных для передачи).
У меня чаще всего получались производные, а у объекта бизнес логики были методы типа setSubObjectData и getSubObjectData
И ещё раз повторюсь, речь идет о том, чтобы снизить трудоемкость.
Если проект не очень большой, и не очень сложный, то быстрее будет сделать на чем-нибудь готовом. Тот же SOAP в java делается в пару аннотаций в классе для jdk6.
В том же EJB последних версиях тоже есть возможность делать контейнеры-вебсервисы в одну строчку.
Что лучше, написать кучу мапперов, роутеров урлов. и прочее… Ведь их же писать нужно. Что лучше 1 строка или 300 строк? Что будет быстрее разработать? Где будет меньше ошибок?
Если нет каких либо сложных проблем использованием SOAP, то такой путь чуть быстрее. Можно сократить время разработки-отладки.
Велосипеды нынче не в почете, а ещё они могут ломаться.
А начальство ох как этого не любит, при каждой поломке начинает ныть, мол нужно было использовать стандартную или такую-то чужую. Вот приходится взвешивать что лучше чужая или своя самописная…
Лопатить в ручную тоже придется. везде свои фишки. Везде свои недоработки.
Какую-нибудь прослойку, которую можно спросить что-то типа.
— вот тебе ID, дай мне объект.
— или на тебе объект, иди и сохрани его.
— или вот тебе критерии, дай мне массив объектов
— или дай мне массив всех объектов
Причем объекты мы можем написать сами или получить их из того же WADL. Там же мы получим и урлы да параметры, по которым нужно обращаться.
Для Ruby есть прикольная библиотека ActiveResource. Построена по принципу шаблона проектирования ActiveRecord. Использовать приблизительно так же.
На Java RestTemplate от Spring. Чтобы там получать и отсылать сложные объекты, нужно их маппить в XML. Маппинг приходится описывать отдельно.
и так далее…