Фаулер классный мужик. Была возможность пообщаться. Но и он не смог устоять от того, что бы не переобозвать известный GoF шаблон по своему. Ну пиар блин… :-)
PS: Что особенно грустно, так это то, что люди не очень то и обсуждают столь фундаментальные вещи, от которых тотально зависит успех практически любого проекта. И не важно, образцы это или подходы. Важно то, что эти вещи важны, но их важности мало кто понимает. :-)
Разница в том, что есть образцы, а есть принципы и подходы. Если человек обзывает подходы образцами, то он путает других людей и формирует у них чувство. что это и есть те самые образцы, которые в действительности есть подходы. :-)
Как итог — человек не видит разницы и полагает, что он знает то, что в действительности — не знает. Такая вот беда.
Для человека который понимает всё, это конечно же без разницы. Он и сам в состоянии расставить акценты и использовать термины правильно.
Как видите, там везде фигурирует слово Principles. И речь идёт не о Design Patterns, а об общих подходах к проектированию, что англоговорящие также обзывают словом паттернс, но Softaware patterns. То есть подходы и правила. Но не образцы! Не нужно их мешать в кучу.
… не надо мешать шаблоны проектирования, структурные шаблоны, поведенческие шаблоны и пр…
— Именно что и надо мешать. Ибо структурные шаблоны и поведенческие шаблоны являются частью шаблонов проектирования. Не надо мешать шаблоны и принципы.
PS: Книга Лармана называется «Applying UML and Paterns». Перевели это как «Применение UML и шаблонов проектирования». Что и есть радикально неправильно. Шаблоны Проектирования это давно устоявшийся термин (Design Patterns), и это технический термин, связанный с набором приёмов организации кода, а не общих принципов ООП. К сожалению, в силу невысокой квалификации переводчиков, получился заментый смаз, когда одно смешалось с другим и возникла путаница. На месте Лармана я бы не использовал термин Patterns.
Это Ларман путает. И переводчики путают. GRASP это не набор шаблонов, это набор рекомендаций и принципов которыми желательно руководствоваться при принятии того или иного проектного решения, которые кто-то сдуру обозвал шаблонами. Они рекомендуют из чего исходить и что принимать во внимание, что бы ничего не упустить. В этом и есть ошибка Лармана. Он обозвал рекомендации шаблонами и на этом построил книгу. Эту книгу тщательно перевели на русский (и продолжают переводить новые издания). Как итог, неудачный учебник с перепутанной терминологией, который является стартовым для молодых разработчиков. Ну и следствие — люди не знают что такое Фабрика, но пространно рассуждают о низком связывании и Криейторах по Ларману.
ПС: Это удобно при собеседовании на работу. Сразу видно, что чел не читал Гофа, но прочёл куски Лармана. Смысла не понимают. Умные слова — знают. :-)
Видимо я сильно рискну и категорически выбьюсь из дружного хора поклонников Крега Лармана, но таки скажу – крайне неудачная книга.
Шаблоны проектирования давно стали стандартом для квалифицированного разработчика. По своей сути, шаблон это некий образец того, как должны между собой соотноситься (быть организованы) объекты/классы для того что бы максимально удобно и безопасно решить ту или иную задачу. В своё время, Бригада (“банда”) Четырёх (GoF) подвела отличную мощную черту тщательным образом задокументировав самые ходовые приёмы организации объектов и, дав им те названия, которые эмпирически сложились лет за 10. На основании этой книги вы можете сказать, что вот тут у вас Синглетон, тут Фабрика, а тут Мост. И квалифицированный разработчик вас поймёт.
Что сделал Ларман? Для начала он перепутал шаблоны с принципами. А затем – дал известным вещам собственные названия, тем самым кардинально запутав людей. Особенно тех, кто не читал GoF, и начал изучение шаблонов по Ларману. Низкая связанность – это не шаблон, это принцип проектирования. А шаблон, это пример организации объектов, что бы этой низкой связанности достичь. Если приводить пример из жизни, то, упрощённо говоря, можно постулировать принцип – угловое соединение деревянных досок в кухонных столах должно быть прочным. А можно привести шаблон – как и куда правильно вкрутить болты, что бы угловое соединение досок было действительно прочным. Семантически это несколько разные вещи: образец использования предмета и некий принцип, которому нужно следовать.
Вот Ларман это постоянно путает, обзывает многие вещи по своему, да и вообще часто постулирует неправильные принципы. Оттого книга и читается крайне тяжело, поскольку очень сложно понять, что же хотел сказать автор, ибо это выглядит или очень общё или непонятно. Явных глупостей он там не говорит, в целом всё вроде верно, но запутал он всех своими новыми терминами довольно таки основательно.
В итоге мы и имеем некую забавную ситуацию, когда название шаблона выглядит как название принципа и при этом противоречит другому названию. Низкая связанность, высокое зацепление… И это всё при том, что в канонической книге Гофа всё это постулировано очень точно и правильно. Хотите иметь хорошую развязку — применяёте такой-то шаблон и будет вам счастьё и вот почему… Хотите иметь сильную связь, которая нужна в таких и таких-то случаях, берите вот такой для этого и такой для этого. Никаких противоречий и туманных описаний.
Учитывая, что ГоФ книга серьёзная, точная и популизмом не балуется, со своей стороны порекомендую крайне замечательно написанную книгу — Head First Design Patterns:
Книга написана очень доступно, увлекательно и с хорошим юмором, использует правильную терминологию и содержит много удачных визуальных примеров из окружающей бытовой действительности, которые отражают суть того или иного паттерна. К сожалению, на русский язык книга вроде как не переводилась.
Дело не в том, что кеширование плохо, а в том, что вначале вы драматически понизили производительность работы вашей БД за счёт «принципа супергибкости». А теперь пытаетесь это хоть как-то скомпенсировать кешированием. Забывая про то, что при многопользовательском транзакционном доступе к данным, кеширование есть непростая задача. То есть вам придётся довольно изощрённо управляться с вашим кешем. Что для многих случаев (в силу необходимости вручную актуализировать кеш) ещё больше понизит производительность вашей системы и скорее всего будет чревато большим количеством ошибок.
Если у вашего заказчика такой же бюджет как и у разработчиков процессоров, то и вы сделайте.
Хотя, у меня есть сильное чувство что это несколько разные кеши. Хотя бы потому, что процессор только сам доступается к своему кешу. А если ему нужно позволить туда доступаться другим контроллерам, то для этого разрабатывается специальная технология. И часто довольно не простая.
Во-первых — вы не упоминали ваш сервер БД.
Во-вторых — в том или ином виде это есть у всех серверов. А как вы думаете каким образом сервер будет получать информацию о своих объектах что бы строить запросы?
Угу. А ещё есть проблема изолированности транзакций. Ибо синхронизация кеша с реальными данными должна делаться с учётом этого. Просто ребята не прочли как устроен сервер баз данных и начали писать свой. Похоже у них не бедный заказчик. :-)
Когда вы создаёте базу данных под некоторым реляционным сервером БД, то в этой базе данных автоматически создаётся набор таблиц описывающий структуру ваших данных. То есть и ваши сущности и связи между ними. Называется этот набор — Dictionary. По сути — создать базу данных это и есть создать такой описательный набор таблиц (мета-словарь). К нему всегда можно доступиться.
Таким образом, если не изобретать велосипед, а прочесть учебник и сакцентироваться на грамотном проектировании таблиц хранящих непосредственно экземпляры сущностей, то вы, во-первых, избавитесь от низкопроизводительных многоэтажных запрсов, во-вторых, почувствуете на себе всю мощь кеширования правильно настроенного SQL сервера, в третьих — cэкономите время на разработке и отладке собственных доморощенных решений, и, в четвёртых, заметно сэкономите деньги и время того, кто платит за проект. :-)
Я просто давно читаю разные книги и хорошо помню, что эта притча всегда была про физиков. И лет ей достаточно много. А то, что она выродилась в анекдот про автомехаников, так это по человечески понятно — ведь не все же знают кто такой был этот Пётр Капица.
Эх, забавно читать от пОдростков (зачёркнуто) молодых и очень умных людей, что они это слышали про Эдисона, Форда и некоего телемастера. Что недвусмысленно говорит об их источниках информации или местечковой фантазии. Притчи этой много лет. И там всегда был Пётр Капица! Только сумма менялась (видимо инфляция). 1000 или 10 000… или больше… :)
От бы кто объявил конкурс на то, как из существующих телефонов сделать телефон мечты. С каким бы удовольствием (что бы не сказать острервенением) я бы замалякал все эти мляцкие камеры и мп3 проигрыватели. И поставил толщину 3 миллиметра с жирным восклицательным знаком. И размер сантиметров в 7 длины и 3 ширины. От жаж маркетинговое дурачьё, сорвершенно не понимает нужд потребителя. :-)
Как итог — человек не видит разницы и полагает, что он знает то, что в действительности — не знает. Такая вот беда.
Для человека который понимает всё, это конечно же без разницы. Он и сам в состоянии расставить акценты и использовать термины правильно.
«GRASP stands for General Responsibility Assignment Software Patterns (or sometimes Principles).»
Дабы не ошибиться, и не брать всё на свой авторитет, который безразличен Хабра людям, взял прямо из англоязычной вики.
en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)
Как видите, там везде фигурирует слово Principles. И речь идёт не о Design Patterns, а об общих подходах к проектированию, что англоговорящие также обзывают словом паттернс, но Softaware patterns. То есть подходы и правила. Но не образцы! Не нужно их мешать в кучу.
— Именно что и надо мешать. Ибо структурные шаблоны и поведенческие шаблоны являются частью шаблонов проектирования. Не надо мешать шаблоны и принципы.
ПС: Это удобно при собеседовании на работу. Сразу видно, что чел не читал Гофа, но прочёл куски Лармана. Смысла не понимают. Умные слова — знают. :-)
Шаблоны проектирования давно стали стандартом для квалифицированного разработчика. По своей сути, шаблон это некий образец того, как должны между собой соотноситься (быть организованы) объекты/классы для того что бы максимально удобно и безопасно решить ту или иную задачу. В своё время, Бригада (“банда”) Четырёх (GoF) подвела отличную мощную черту тщательным образом задокументировав самые ходовые приёмы организации объектов и, дав им те названия, которые эмпирически сложились лет за 10. На основании этой книги вы можете сказать, что вот тут у вас Синглетон, тут Фабрика, а тут Мост. И квалифицированный разработчик вас поймёт.
Что сделал Ларман? Для начала он перепутал шаблоны с принципами. А затем – дал известным вещам собственные названия, тем самым кардинально запутав людей. Особенно тех, кто не читал GoF, и начал изучение шаблонов по Ларману. Низкая связанность – это не шаблон, это принцип проектирования. А шаблон, это пример организации объектов, что бы этой низкой связанности достичь. Если приводить пример из жизни, то, упрощённо говоря, можно постулировать принцип – угловое соединение деревянных досок в кухонных столах должно быть прочным. А можно привести шаблон – как и куда правильно вкрутить болты, что бы угловое соединение досок было действительно прочным. Семантически это несколько разные вещи: образец использования предмета и некий принцип, которому нужно следовать.
Вот Ларман это постоянно путает, обзывает многие вещи по своему, да и вообще часто постулирует неправильные принципы. Оттого книга и читается крайне тяжело, поскольку очень сложно понять, что же хотел сказать автор, ибо это выглядит или очень общё или непонятно. Явных глупостей он там не говорит, в целом всё вроде верно, но запутал он всех своими новыми терминами довольно таки основательно.
В итоге мы и имеем некую забавную ситуацию, когда название шаблона выглядит как название принципа и при этом противоречит другому названию. Низкая связанность, высокое зацепление… И это всё при том, что в канонической книге Гофа всё это постулировано очень точно и правильно. Хотите иметь хорошую развязку — применяёте такой-то шаблон и будет вам счастьё и вот почему… Хотите иметь сильную связь, которая нужна в таких и таких-то случаях, берите вот такой для этого и такой для этого. Никаких противоречий и туманных описаний.
Учитывая, что ГоФ книга серьёзная, точная и популизмом не балуется, со своей стороны порекомендую крайне замечательно написанную книгу — Head First Design Patterns:
oreilly.com/catalog/9780596007126/
Книга написана очень доступно, увлекательно и с хорошим юмором, использует правильную терминологию и содержит много удачных визуальных примеров из окружающей бытовой действительности, которые отражают суть того или иного паттерна. К сожалению, на русский язык книга вроде как не переводилась.
Хотя, у меня есть сильное чувство что это несколько разные кеши. Хотя бы потому, что процессор только сам доступается к своему кешу. А если ему нужно позволить туда доступаться другим контроллерам, то для этого разрабатывается специальная технология. И часто довольно не простая.
Во-вторых — в том или ином виде это есть у всех серверов. А как вы думаете каким образом сервер будет получать информацию о своих объектах что бы строить запросы?
www.quest-pipelines.com/newsletter-v6/0905_A.htm
Видите, вы начали проектировать не разобравшись как устроены сервера баз данных. Это опасная практика. :-)
Таким образом, если не изобретать велосипед, а прочесть учебник и сакцентироваться на грамотном проектировании таблиц хранящих непосредственно экземпляры сущностей, то вы, во-первых, избавитесь от низкопроизводительных многоэтажных запрсов, во-вторых, почувствуете на себе всю мощь кеширования правильно настроенного SQL сервера, в третьих — cэкономите время на разработке и отладке собственных доморощенных решений, и, в четвёртых, заметно сэкономите деньги и время того, кто платит за проект. :-)
Вот тут их побольше собрано. И записаны покороче:
edu.blog.ru/9939523.html
Здорово, что rapida вспомнил эту притчу!
PS: Кнопки чёткие и внятные!!!