Комментарии 24
Ну как то сомнительно что смысл шаблонов именно в написаном, вы их, как мне кажется, путаете со стандартами кодирования.
И как пишется в любой книжке по шаблонам проектирования. Что они (шаблоны) есть ни что иное как абстрактный уровень для решения наиболее часто встречающихся задач.
И как пишется в любой книжке по шаблонам проектирования. Что они (шаблоны) есть ни что иное как абстрактный уровень для решения наиболее часто встречающихся задач.
Проблема с этим абстрактным уровнем, что программисты (начинающие) не знают, когда нужно применять тот или иной абстрактный способ. Они смотрят на список доступных шаблонов и выбирают тот, который, как им кажется, наиболее подходит под данную задачу.
А надо как раз наоборот — сначала решить задачу, понять, как система должна работать, а уже потом оформлять решение задачи с использованием известных шаблонов.
Поэтому нельзя рассматривать шаблоны как набор образцов или примеров решения задач, а нужно — как образец оформления решения.
А надо как раз наоборот — сначала решить задачу, понять, как система должна работать, а уже потом оформлять решение задачи с использованием известных шаблонов.
Поэтому нельзя рассматривать шаблоны как набор образцов или примеров решения задач, а нужно — как образец оформления решения.
Ну то о чем вы пишите это проблемы образования этих самых программистов, а не шаблонов проектирования. Оформление кода — это стандарты кодирования. И точка…
Я бы сказал, что шаблоны проектирования это скорее типовые примеры грамотного конструирования элементов программы. Их использование, кроме прочего позволяет писать понятные другим программистам программы.
В общем случае конструирование программы должно подразумевать следующие шаги:
— Анализ задачи.
— Подготовка требований к программе
— Анализ возможных изменений программы в будущем (например, добавление новых типов интерфейсов)
— Разбиение на модули/объекты/массивы объектов
— В нужных/ключевых местах подбор подходящих паттернов. Обязательно учитывая отношение эффективности их применения к затратам, хотя бы приблизительно.
В общем случае конструирование программы должно подразумевать следующие шаги:
— Анализ задачи.
— Подготовка требований к программе
— Анализ возможных изменений программы в будущем (например, добавление новых типов интерфейсов)
— Разбиение на модули/объекты/массивы объектов
— В нужных/ключевых местах подбор подходящих паттернов. Обязательно учитывая отношение эффективности их применения к затратам, хотя бы приблизительно.
Обычно под словом «шаблон проектирования» (software design pattern) понимают способ решения той или иной задачи. Нужен объект который хочется иметь в единственном экземпляре но не хочется создавать при запуске программы — используем синглтон. Нужно раздробить интерфейс и логику на части — используем mvc. Хотим вынести из десятка классов общую логику использования — inversion of control. Ну и так далее.
Насколько я знаю, оформление кода — как что называть, где скобочки ставить, где комментарии и прочее — называют «нотацией» (hugarian notation, microsoft notation, google notation итд).
Насколько я знаю, оформление кода — как что называть, где скобочки ставить, где комментарии и прочее — называют «нотацией» (hugarian notation, microsoft notation, google notation итд).
Реквестирую статью про Паттерны. А тут вроде и правда — шаблоны.
Оформление кода, вообще-то обычно называется Programming style
А если сама структура классов является частью правил по оформлению? Вот мне кажется, что шаблоны проектирования и надо рассматривать как расширение правил оформления кода на классовый и межклассовый (как звучит!) уровень.
Все-таки хорошо бы разделять стандарт (стиль) программирования и паттерны. Нпример, чтобы не путаться. Я бы в качестве аналогии привел конструкторскую документацию:
стиль/стандарт — оформление чертежей и конструкторской документации
паттерны — типовые конструкции узлов изделий
стиль/стандарт — оформление чертежей и конструкторской документации
паттерны — типовые конструкции узлов изделий
Вопрос не в разделении паттерн и оформления, а в отделении паттерна от способа решения задачи.
Следуя примеру, типовую конструкцию узлов надо применять, но только тогда, когда эта конструкция актуальна. Не нужно делать дверь на 7-ом этаже, если в задаче написано «тут люди должны иметь возможность покинуть помещение» (хотя вроде по описанию паттерна подходит).
Следуя примеру, типовую конструкцию узлов надо применять, но только тогда, когда эта конструкция актуальна. Не нужно делать дверь на 7-ом этаже, если в задаче написано «тут люди должны иметь возможность покинуть помещение» (хотя вроде по описанию паттерна подходит).
— Согласен, но не совсем, терминология тоже важна, чтобы говорить об одном и том же и понимать друг друга.
— По двери на седьмом этаже, конечно не нужно делать дверь на седьмом этаже, т.е. к паттернам подходить здраво, как Вы и написали. Если уж нужно покидать помещение прямо с седьмого этажа, то нужно не бездумно лепить паттерн «дверь» прямо на этаже а грамотно применить два паттерна:
«дверь» + «пожарная лестница». Естественно для этого нужно понимать то, что делаешь и почему выбираешь паттерны «дверь» + «пожарная лестница», а не паттерн парашют.
— По двери на седьмом этаже, конечно не нужно делать дверь на седьмом этаже, т.е. к паттернам подходить здраво, как Вы и написали. Если уж нужно покидать помещение прямо с седьмого этажа, то нужно не бездумно лепить паттерн «дверь» прямо на этаже а грамотно применить два паттерна:
«дверь» + «пожарная лестница». Естественно для этого нужно понимать то, что делаешь и почему выбираешь паттерны «дверь» + «пожарная лестница», а не паттерн парашют.
Конечно, ничего не мешает принять в качестве внутрифирменного стандарта использование для определенных типовых задач определенных паттернов. Но деление на стандарт/стиль кодирования и паттерны уже устоялось и лучше эти вещи не путать.
Не согласен.
Правило — это то, чему нужно следовать, а паттерн — это такой inspiration, поглядев на который, можно понять, какие цели преследовал автор паттерна, зачем он их преследовал, и как добился. А поняв — сделать так же, или лучше.
У тех же GoF в книге у каждого паттерна есть раздел Abstraction, который говорит, чем обусловлено уппрощение задачи и почему оно допустимо. Не нужно кодить «паттернами», нужно писать, «как писали паттерны» — четко, в меру абстрактно, изящно.
Имхо.
Правило — это то, чему нужно следовать, а паттерн — это такой inspiration, поглядев на который, можно понять, какие цели преследовал автор паттерна, зачем он их преследовал, и как добился. А поняв — сделать так же, или лучше.
У тех же GoF в книге у каждого паттерна есть раздел Abstraction, который говорит, чем обусловлено уппрощение задачи и почему оно допустимо. Не нужно кодить «паттернами», нужно писать, «как писали паттерны» — четко, в меру абстрактно, изящно.
Имхо.
По паттернам, кстати, хотелось бы еще отметить следующую проблему. Они рождены и поисаны во многом, как решение специфических проблем, возникающих при программировании на C++ (и возможно Java), при программировании на других языках, например с динамической типизацией, таких как Python, нежелательно тупо применять паттерны из GoF. Бездумное их применение усложняет программу на питоне очень сильно. Для Python, нужны другие паттерны.
Вообще могу сказать что я, ознакомившись с книгой по шаблонам проектирования был удивлен что уже довольно давно использую шаблоном ActiveRecord и Singleton (т.ж. видоизмененные другие).
Так что вопрос применения шаблонов это не вопрос их знания, скорее — ощущения.
Так что вопрос применения шаблонов это не вопрос их знания, скорее — ощущения.
Когда люди обращаются к использованию паттернов проектирования?
Все программисты, во время кодинга, сталкиваются с проблемой именования сущностей: как назвать класс?, как назвать метод?, как назвать атрибут?, и т.п. Те, у которых опыт больше, уже успели сформировать для себя некоторый словарь (переменные цикла называют «i, j, k», одиночный объект «singleton», а метод-конструктор объектов 'somethingFactory'). Впрочем, всегда появляются незнакомые аспекты. Однако, у «начинающих», эта проблема стоит острее. Я думаю, многие, на этом этапе пытались искать спасение в книжках по паттернам. Не всегда удачно. Дело в том, что паттерны описывают не только слова, но и конкретные архитектурные решения, которые за ними стоят. Ни кто, единожды написав слово singleton, не удержится от того, чтобы закодить и всю остальную атрибутику паттерна: для данного класса, на самом деле, можно будет создать лишь единственный экземпляр в рамках всего приложения. Но если, по задумке архитектора, требуется не это (а, например, иметь единственный инстанс лишь в пределах какого-то модуля, не всего приложения)? Проблема. Собственно, причина очевидна: кодер имеет дело лишь с маленьким кусочком решения задачи, и из него совершенно не ясно, какую роль этот код будет играть в архитектуре всего приложения. Все равно, что имея описание кирпича пытаться вообразить себе будущее строение. Кодинг это не тот этап, где можно принимать архитектурные решения. И это не тот этап, где ввод паттернов проектирования будет осмысленным. Именно поэтому выбор паттернов на этом этапе часто оказывается неправильным.
Все программисты, во время кодинга, сталкиваются с проблемой именования сущностей: как назвать класс?, как назвать метод?, как назвать атрибут?, и т.п. Те, у которых опыт больше, уже успели сформировать для себя некоторый словарь (переменные цикла называют «i, j, k», одиночный объект «singleton», а метод-конструктор объектов 'somethingFactory'). Впрочем, всегда появляются незнакомые аспекты. Однако, у «начинающих», эта проблема стоит острее. Я думаю, многие, на этом этапе пытались искать спасение в книжках по паттернам. Не всегда удачно. Дело в том, что паттерны описывают не только слова, но и конкретные архитектурные решения, которые за ними стоят. Ни кто, единожды написав слово singleton, не удержится от того, чтобы закодить и всю остальную атрибутику паттерна: для данного класса, на самом деле, можно будет создать лишь единственный экземпляр в рамках всего приложения. Но если, по задумке архитектора, требуется не это (а, например, иметь единственный инстанс лишь в пределах какого-то модуля, не всего приложения)? Проблема. Собственно, причина очевидна: кодер имеет дело лишь с маленьким кусочком решения задачи, и из него совершенно не ясно, какую роль этот код будет играть в архитектуре всего приложения. Все равно, что имея описание кирпича пытаться вообразить себе будущее строение. Кодинг это не тот этап, где можно принимать архитектурные решения. И это не тот этап, где ввод паттернов проектирования будет осмысленным. Именно поэтому выбор паттернов на этом этапе часто оказывается неправильным.
② Когда люди обращаются к использованию паттернов проектирования?
На этапе анализа задачи то и дело возникает проблема идентификации сущностей и отношений между ними. Идентифицировать — значит выделить характерные особенности и придумать уникальное название. На «выходе» должен получиться этакий словарь терминов, наделенных определенным смыслом, при помощи которых, в дальнейшем, будет описываться все решение и составляться программная модель. Классно, если полученная модель будет не только описывать требуемые аспекты задачи, но и — хорошо вписываться в архитектурные решения любимой программной платформы, а так же будет понятна всем членам команды. Т.е. термины должны быть не абы-какими, а общеупотребимыми. Я думаю, что многие и на этом этапе начинают искать спасение в книжках по паттернам проектирования. Вам требуется создать приложение, которое будет взаимодействовать с пользователем? Смотрим книжку, вот и ответ: ModelViewController — всего три слова! Это элементарно и понятно даже «новичку». Значит нужно использовать паттерн MVC. Теперь сравните — MVC в Smaltalk, MVC в .Net.MVC и MVC во фреймворке symfony для php — за тремя одинаковыми словами скрываются четыре совершенно разных архитектурных решения (первое было в книжке). А что в вашей архитектуре будут означать слова ModelViewController? =)
На этапе анализа задачи то и дело возникает проблема идентификации сущностей и отношений между ними. Идентифицировать — значит выделить характерные особенности и придумать уникальное название. На «выходе» должен получиться этакий словарь терминов, наделенных определенным смыслом, при помощи которых, в дальнейшем, будет описываться все решение и составляться программная модель. Классно, если полученная модель будет не только описывать требуемые аспекты задачи, но и — хорошо вписываться в архитектурные решения любимой программной платформы, а так же будет понятна всем членам команды. Т.е. термины должны быть не абы-какими, а общеупотребимыми. Я думаю, что многие и на этом этапе начинают искать спасение в книжках по паттернам проектирования. Вам требуется создать приложение, которое будет взаимодействовать с пользователем? Смотрим книжку, вот и ответ: ModelViewController — всего три слова! Это элементарно и понятно даже «новичку». Значит нужно использовать паттерн MVC. Теперь сравните — MVC в Smaltalk, MVC в .Net.MVC и MVC во фреймворке symfony для php — за тремя одинаковыми словами скрываются четыре совершенно разных архитектурных решения (первое было в книжке). А что в вашей архитектуре будут означать слова ModelViewController? =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Об использовании паттернов