Комментарии 54
Всему свое время. Глупо заставлять ребенка учить сопромат, когда перед ним из задач только куличики в песочнице. Когда (если) он захочет переходить к крупным формам, тогда и надо рассказать о других стойматериалах и технологиях.
Вот он и хочет.
В большинстве случаев — закрепляется как опыт, «я уже так делал и так работает». Поэтому сначала — развить мышление, а потом сразу обучить паттернам и прочим фишкам.
Не соглашусь с аналогией.
Кирпич — это материал, как, например использовать метод sort() какого либо писка(массива), а не реализовывать его самому.
Паттерн в строительстве скорее больше похо на «дымоход должен выходить вверх» или «крыша должна быть покатой» или «окна должны быть прямоугольными и в определенном месте»
Кирпич — это материал, как, например использовать метод sort() какого либо писка(массива), а не реализовывать его самому.
Паттерн в строительстве скорее больше похо на «дымоход должен выходить вверх» или «крыша должна быть покатой» или «окна должны быть прямоугольными и в определенном месте»
Трудность заключается в том, что когда учишься сам, ты сам доходишь, до правильных (или не правильных) решений своим опытом. Появляются новые знания и, что главное, ты получаешь свой личный опыт. Но вот я, например, изучаю программирование самостоятельно (в институте ничему путевому не учат, а только как раз-таки куличики печь), и собственно, я не знаю ни о каких паттернах, ни где о них узнать. Если возникает какая-то трудная задача, то благодаря поиску в интернете находится решение.
Вот скажите, как необразованному, где можно набраться знаний для использования этих самых паттернов?
Библиотеки использую, но я так понял это немножко не то.
Как показывает практика, опыт приходит именно на своих ошибках, а чужие только вносят новые непонятности.
Вот скажите, как необразованному, где можно набраться знаний для использования этих самых паттернов?
Библиотеки использую, но я так понял это немножко не то.
Как показывает практика, опыт приходит именно на своих ошибках, а чужие только вносят новые непонятности.
Та же проблема. Говорят, надо книжки разные читать, но честно говоря по мне в книгах всё какое-то обычно кажется далёким от того, что нужно, например, мне. ИМХО.
Вот доступная книжка по паттернам. Мне весьма помогло разобраться в них то, что в ней живой, а не формализованный язык
Благодарю, ознакомлюсь.
Не успел изменить прошлый комментарий.
Я правильно понимаю, что паттерны это общие принципы проектирования, не зависящие от языка программирования, или же все таки это набор некоторых примитивных решения, которые разнятся от разных языков?
Я правильно понимаю, что паттерны это общие принципы проектирования, не зависящие от языка программирования, или же все таки это набор некоторых примитивных решения, которые разнятся от разных языков?
Ну не общие принципы, а типичные шаблоны, не зависящие от языка. От языка зависит реализация.
Это общие принципы проектирования, не зависящие от языков программирования. Но могут встречаться нюансы реализации в зависимости от языка. Плюс к этому — на привычном языке — проще понять суть.
Т.е. если я правильно понял, например, мы делаем сайт, то типичным принципом его проектирования будет: вверху авторизация, по центру контент, слева/справа баннеры/меню, ну и в подвале копирайты итд.?
Это касается не только интерфейса, но и определенных функций в программировании?
Это касается не только интерфейса, но и определенных функций в программировании?
Есть шаблоны проектирования интерфейса, в данном случае вёрстки (вы их описали), есть шаблоны вычислений (так называемые «алгоритмы»), а есть шаблоны проектирования ПО (примеры в метафорах). Разные вещи, но смысл один.
Книжка то конечно хорошая, но я после её прочтения так и не могу увидеть в задаче шаблоны :( Вроде на примере с, к примеру, кофейней все понятно, но когда я пишу, что-то для себя, хоть убей не могу разбить задачу на шаблоны. Плакаю.
Опыт командной работы не приходит от самостоятельной работы. Ответ на Ваш вопрос есть в этом посте, см. раздел «А как без шаблонов?»
И есть такая проблема: если Nдцать лет успешно программировал не зная о паттернах, то «когда припрёт», учиться уже не хочется.
И есть такая проблема: если Nдцать лет успешно программировал не зная о паттернах, то «когда припрёт», учиться уже не хочется.
И есть такая проблема: если Nдцать лет успешно программировал не зная о паттернах, то «когда припрёт», учиться уже не хочется.
Ну через такой промежуток времени, конечно не захочется. Ты уже делаешь все на автоматизме. Хотя я думаю в наше время так не получится.
Опыт командной работы не приходит от самостоятельной работы.
Ну и в этом конечно Вы правы.
Была такая же проблема. Решилась при переходе в компанию, где был ментор и ревью кода.
Паттерн — это скорее бетонная плита, применяемая при постройке домов. Нужно окно — хоп, вот тебе стена с окноп. Нужна дверь — вот стена с дверью. Это крупноблочное строительство. К сожалению, не все видят за паттернами сути, поэтому построить дом с круглым окном не могут — паттерна подходящего нету, а из кирпичей и бетона сами сконструировать не могут. Если архитектура приложения хороша, но подходящего паттерна нету — то не надо пытаться поломать архитектуру, чтобы вкорячить туда что нибудь, надо писать своё. Вот тут сильно нужен опыт, который и позволит оценить, на сколько архитектура хороша.
Я не могу сказать, на сколько сильно нужно читать про паттерны — я про них узнал уже изрядно попрограммировав, и ничего особо нового для себя не открыл. Идеи то на поверхности, тем более что почти всё из практической области, к ним просто придумали названия :) Всё же изучать стоит, но изначально понимать и принимать, что не в любом произвольном месте произвольной программы получится эти знания применить.
Я не могу сказать, на сколько сильно нужно читать про паттерны — я про них узнал уже изрядно попрограммировав, и ничего особо нового для себя не открыл. Идеи то на поверхности, тем более что почти всё из практической области, к ним просто придумали названия :) Всё же изучать стоит, но изначально понимать и принимать, что не в любом произвольном месте произвольной программы получится эти знания применить.
А вы поставьте вопрос по-другому: «как можно обойтись без паттернов в ООП?»
*(плюсы лучше всего понимать/осознавать начиная с минусов)
*(плюсы лучше всего понимать/осознавать начиная с минусов)
Так можно же обойтись.
Вот вы и ответили на свой вопрос. Лучше не обманывайте детей :-D
Паттерны — не панацея — это высшая абстракция и понять ее можно только прочувствовав, а для этого нужно предложить им запрограммировать несколько идей (но стараясь делать это красиво). И после этого ученик начнет видеть в реализациях разных вещей общие черты, и в какой то момент… Оо, все стало ясно, мир обрел новый смысл, вот о чем твердил сэнсэй.
Но нельзя дав одну задачку переходить сразу к паттернам.
Паттерны — не панацея — это высшая абстракция и понять ее можно только прочувствовав, а для этого нужно предложить им запрограммировать несколько идей (но стараясь делать это красиво). И после этого ученик начнет видеть в реализациях разных вещей общие черты, и в какой то момент… Оо, все стало ясно, мир обрел новый смысл, вот о чем твердил сэнсэй.
Но нельзя дав одну задачку переходить сразу к паттернам.
Патрены, в любом слчае мы ими польземся, либо делая это на собственно опыте, либо почитав умные книги. По аналогии это не кирпичи и не плиты, а скорее понятия что дверь должна быть в стене а не потолке, и что подземная стоянка освободит места вокруг дома для детской площадки. К строительным материам я бы отнес конструкции языка, фреймворки и библиотеки. А паттерты может к общему понимаю, хотя я больше склоняюсь что они в базовом понимании нужны больше для общения, чтобы другому разработчику объяснить что ты хочешь сделать.
Поддерживаю, паттерны как таковы, скорее нужны для объяснения своей идеи другому разработчику. Паттерн — это не кирпич, и не бетонная плита, вы не построете приложение из паттернов, как дом из кирпичей. это скорее «best practices», это советы и рекомендации. Это как набор типичных дебютов в шахматах — знать полезно, но целиком игру на одном лишь знании дебютов не выиграть, да и иногда для победы бывает полезно использовать какой-нибудь нетипичный дебют.
Рано или поздно, проектируя сложную систему, вы так или иначе придёте к паттернам, но, зная лишь паттерны и не имея опыта, вряд ли у вас получится действительно красивая система.
P.S. ИМХО, олимпиаднику сложно объяснить значение паттернов :-) В спортивном программировании практически не требуется умение проектирования систем.
Рано или поздно, проектируя сложную систему, вы так или иначе придёте к паттернам, но, зная лишь паттерны и не имея опыта, вряд ли у вас получится действительно красивая система.
P.S. ИМХО, олимпиаднику сложно объяснить значение паттернов :-) В спортивном программировании практически не требуется умение проектирования систем.
Сколько раз убеждаюсь, что практически нет аналогий из реальной жизни для разработки ПО. Вроде бы похожая параллель, да не то. Вот и кирпич — это материал, что-то осязаемое. А паттерн — это архитектурное решение и реализация его может быть различной для разных систем, стандартным кирпичом здесь не обойтись.
Бог ты мой, даже меня это определение запутало.
Паттерн это не что-то внешнее, а то что создатся, вырабатывается по ходу строительства и при постройке следующего замка мы знаем какие вещи нам нужно повторять, чтобы замок выжил.
Допустим, при строительстве замка из песка мы используем воду, чтобы замок не сыпался — это паттерн. Мы насыпаем песок в ведро, а не таскаем в ладошках — это паттерн. Эти паттерны облегчают разработку.
П программировании, обработка ситуации деления на ноль — это паттерн, обход массива через for или while next — это два паттерна, которые поддерживаются на уровне синтаксиса.
В ООП паттерн фабрика не является готовым кирпичём, а лишь проект как сделать кирпич, ведь его реализация всё ещё остаётся на разработчике.
Паттерн это не что-то внешнее, а то что создатся, вырабатывается по ходу строительства и при постройке следующего замка мы знаем какие вещи нам нужно повторять, чтобы замок выжил.
Допустим, при строительстве замка из песка мы используем воду, чтобы замок не сыпался — это паттерн. Мы насыпаем песок в ведро, а не таскаем в ладошках — это паттерн. Эти паттерны облегчают разработку.
П программировании, обработка ситуации деления на ноль — это паттерн, обход массива через for или while next — это два паттерна, которые поддерживаются на уровне синтаксиса.
В ООП паттерн фабрика не является готовым кирпичём, а лишь проект как сделать кирпич, ведь его реализация всё ещё остаётся на разработчике.
Изучив паттерны лично я потерял интерес к программированию как к творческому процессу. Паттерны — это навязанное ощущение красоты программирования.
Многие знания рождают многие печали ©. Сравните свое высказывание с такими: «изучив (абстрактную) алгебру, я потерял интерес к математике, повсюду одни группы, кольца, поля, алгебры и модули», «изучив категории, я потерял интерес (и) к алгебре».
А конструктивно — можно почитать про создание паттернов, например книжку Влиссидеса «Применение шаблонов проектирования» (хотя слово «применение» в названии несколько дезориентирует).
А конструктивно — можно почитать про создание паттернов, например книжку Влиссидеса «Применение шаблонов проектирования» (хотя слово «применение» в названии несколько дезориентирует).
Если уж говорить именно о школьном уровне, то в свое время я, будучи школьником, с большим интересом прочитал книжку А. Кушниренко «Программирование для математиков». Собственно я ее купил и прочитал в 1988 году, это был мой 9-й (предпоследний) класс. Книжка МГУ-шная, но для подготовленного школьника вполне доступная (ее сейчас можно легко скачать, скан мой). Паттернов как таковых там нет, но идея объекта («исполнителя» в терминах Кушниренко) продемонстрирована на очень интересных примерах, гораздо более близких (по крайней мере в первых главах) к олимпиадной практике, чем это принято обычно. Ну и я в целом согласен с высказанным выше мнением, что паттерны ближе к бетонным блокам, чем к кирпичам.
То, что «паттернов, как таковых, там нет» — это очень мягко сказано. Мы учились по этой книжке. Сейчас курс на мехмате читают, в целом, по этой же книжке (хоть и на другом языке реализации проектов). Так вот, когда я пытаюсь понять, кто такие паттерны, я не вижу вообще ничего общего с тем, что мы учили. Они из каких-то других слоёв реальности, с уровней абстракции, лежащих далеко за пределами курса, который читали (и читают) студентам мехмата :(
Ну, не так чтобы совсем уж другой слой реальности. Там очень подробно описана объектная декомпозиция, причем с содержательными примерами, в отличие от многих других книг. Мне кажется, что на начальном этапе изучения именно этот слой реальности представляет наибольший интерес и с этой точки зрения книжка кажется мне просто блестящей. Использование «исполнителей» напрямую подводит к идее абстрактных интерфейсов, хотя, насколько я помню, само понятие интерфейса там не вводится.
Следующий слой — интерфейсы и их реализация — уже находится на пределе возможностей школьника, ИМХО. Ну а сами паттерны, как типовые сценарии практического использования интерфейсов (а в большинстве случаев по сути это именно так) уже в значительной степени зависят от прикладной области и относятся к совсем уж специальным знаниям.
Следующий слой — интерфейсы и их реализация — уже находится на пределе возможностей школьника, ИМХО. Ну а сами паттерны, как типовые сценарии практического использования интерфейсов (а в большинстве случаев по сути это именно так) уже в значительной степени зависят от прикладной области и относятся к совсем уж специальным знаниям.
Там используется термин «система предписаний». И типичная задача звучит — «дана система предписаний, реализовать её». Выглядит, как интерфейс. Хотя понятия «абстрактного интерфейса» уже нет, в тогдашних реализациях систему предписаний можно было отделить от исполнителя только на бумаге.
Да, я именно это и имел в виду, но формально, там вроде бы не разрешается использовать разные реализации исполнителя с одними и теми же системами предписаний. Кстати, а в современный вариант этого языка такая возможность добавилась?
А есть ли современный вариант? Обучение на Е-практикуме шло не более 5 лет. Последние 20 лет студенты учатся на C и C++. Не знаю, насколько успел развииться Кумир, но думаю, что тоже не очень сильно.
А «разные реализации» кто же запретит использовать? Главное, чтобы не в одной программе. А так — реализуйте, сколько хотите :)
А «разные реализации» кто же запретит использовать? Главное, чтобы не в одной программе. А так — реализуйте, сколько хотите :)
Ясно, спасибо. А то мне казалось, что я что-то слышал о современных версиях, в которых остался кириллический синтаксис, но появилась настоящая объектность в стиле Оберона.
Я имел в виду именно несколько реализаций одного интерфейса-исполнителя с данной СП в рамках одной программы.
А «разные реализации» кто же запретит использовать? Главное, чтобы не в одной программе.
Я имел в виду именно несколько реализаций одного интерфейса-исполнителя с данной СП в рамках одной программы.
Действительно, какая-то разработка идёт. Вот их сайт: www.niisi.ru/kumir/index.htm Судя по форуму, он ещё живой.
Мда, я, похоже, выше не совсем ясно высказался.
Мне хотелось бы более четко сказать, что между «дворцами из песка» и «паттернами проектирования» лежит еще целые страны функциональной декомпозиции, классического объектного дизайна и объектной декомпозиции, в которых живут программы, не содержащие (иногда) ни одного паттерна проектирования, но, тем не менее, совершенно непохожие на «машинку на скотче». А паттерны решают уже задачи более высокого порядка, причем часто сильно связанные с обслуживанием жизненного цикла программ, что уже скорее относится к технологии промышленного программирования.
Мне хотелось бы более четко сказать, что между «дворцами из песка» и «паттернами проектирования» лежит еще целые страны функциональной декомпозиции, классического объектного дизайна и объектной декомпозиции, в которых живут программы, не содержащие (иногда) ни одного паттерна проектирования, но, тем не менее, совершенно непохожие на «машинку на скотче». А паттерны решают уже задачи более высокого порядка, причем часто сильно связанные с обслуживанием жизненного цикла программ, что уже скорее относится к технологии промышленного программирования.
Все намного проще. Если ваш код делает приложение лучше — значит это патерн, если хуже — значит антипатерн. Стоит ли их выносить как догму — думаю врядли. Программирование это поиск лучшего решения, в некотором роде искусство. Вы ведь не будете художнику говорить как правельно держать кисть, как делать мазки и прочее.
Вот возьмите Java как хороший пример того куда заводит гонитьба за патернами. Куча ненужного кода который только мешает и делает приложение в разы сложнее. А это в свою очередь нарушает принцип KISS.
Вот возьмите Java как хороший пример того куда заводит гонитьба за патернами. Куча ненужного кода который только мешает и делает приложение в разы сложнее. А это в свою очередь нарушает принцип KISS.
Если ваш код делает приложение лучше — значит это патернНу это мы с вами знаем. А в школе нас учили антипаттернам, масштабируемым до бочки макарон. Как привить иммунитет?
К сожалению знания != ум. А поэтому куда выгоднее развивать ум нежели знания(особенно в школе). Так же любое правило должно быть понятно человеку, ибо если оно непонятно то принимается на веру, а это в корне не правильно. А как обьяснить человеку что либо если он с этим не работает. Нельзя просто так взять и за пару лекций научить строить высокопроизводительные кластеризуемые приложения, к этому нужно дойти. Иначе бы гениев сейчас было по 20 штук на каждом углу.
Когда я учился на мех-мате у меня была толпа преподов которые давали материал из серии возьмите и заучите. И только некоторые учили понимать и анализировать суть что бы приходить к решению. А когда ты понимаешь течения решать задачи основанные на них становится чисто механическим действием.
Посему лучше забить на патерны и прочее, а просто учить детей думать и анализировать, а правельный ответ они найдут уже сами(если захотят)
Когда я учился на мех-мате у меня была толпа преподов которые давали материал из серии возьмите и заучите. И только некоторые учили понимать и анализировать суть что бы приходить к решению. А когда ты понимаешь течения решать задачи основанные на них становится чисто механическим действием.
Посему лучше забить на патерны и прочее, а просто учить детей думать и анализировать, а правельный ответ они найдут уже сами(если захотят)
А насчет патернов у меня есть хороший пример.
Есть у меня модуль для авторизации в социальных сетях. Прикол в том что требования на разных сетках разные, настолько что как то логически структурировать модуль нельзя. Можно конечно заюзать патерны и разнести все, но в реальности это ухудшит сопровождение ибо инфа будет размазана тонким слоем по приложению. И вот в таком случае все патерны являются антипатернами, а лучший патерн это инлайн кодинг.
Так что все очень сильно зависит от ситуации и серебренных пуль не будет никогда.
Есть у меня модуль для авторизации в социальных сетях. Прикол в том что требования на разных сетках разные, настолько что как то логически структурировать модуль нельзя. Можно конечно заюзать патерны и разнести все, но в реальности это ухудшит сопровождение ибо инфа будет размазана тонким слоем по приложению. И вот в таком случае все патерны являются антипатернами, а лучший патерн это инлайн кодинг.
Так что все очень сильно зависит от ситуации и серебренных пуль не будет никогда.
en.wikipedia.org/wiki/Design_Patterns
И там есть книжка «Design Patterns: Elements of Reusable Object-Oriented Software». Пусть читает и делает реферат.
Учитель — не тот, кто даёт рыбу, а тот, кто даёт удочку.
И там есть книжка «Design Patterns: Elements of Reusable Object-Oriented Software». Пусть читает и делает реферат.
Учитель — не тот, кто даёт рыбу, а тот, кто даёт удочку.
надо изучать анти-паттерны в первую очередь.
паттерны, в основном-довольно очевидные решения. но прочитав умную книжку про паттерны и болея ооп головного мозга начинаешь лепить сложные паттерны не к месту. сам такой был.
паттерны, в основном-довольно очевидные решения. но прочитав умную книжку про паттерны и болея ооп головного мозга начинаешь лепить сложные паттерны не к месту. сам такой был.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем нужны паттерны ООП?