Voicechat: Product в Deftechсереда о 19:30
Насколько важно знать шаблоны проектирования?
Как вы считаете насколько важно для разработчика знать шаблоны программирования. Понимаю что знать нужно, но на сколько углубленно?
Facebook
Twitter
LinkedIn
Леонид Мартынюк
если програмист опытный — знание паттернов бесполезно — он и так их применяет даже не зная что это «паттерн». Для начинающих знание паттернов бесполезно потому что они не имея опыта разработки не имеют понятия куда эти паттерны приткнуть.
Самая большая польза от паттернов — для авторов книг про паттерны.
Ювженко Денис
1. Важливо, аби пройти співбесіду, на 90% питають.
2. Важливо, аби розуміти код, бо все ж, в більшості проектів в тій чи іншій формі використовуються.
3. Важливо, якщо пишеш новий функціонал, аби не вигадувати велосипедів.
4. Ну і критично важливо, якщо плануєш архітектуру, але ті, хто за таке відповідають, не задають таких запитань.
Rostislav Nikitin
Думаю надо знать углублённо. Т.к.:
1. Мозг начинает оперировать объектами более сложной структуры. Т.е. программист поднимается на более высокий уровень абстракции, видит систему с более высокого уровня, что помогает понять систему в целом, нежели детали реализации отдельных частей
2. Программист получает опыт предыдущих поколений. До него люди писали код и с годами сформировались некие типовые решения. Т.е. если с умом этим пользоваться — можно:
А. Повысить перфоменс, не изобретая каждый раз новый велосипед (опять же с умом пользоваться, не надо пытаться подогнать «не подгоняемый» код под паттерн в ущерб характеристикам системы, понимаемости кода и т.д.)
Б. Повысить читабельность кода. Другой девелопер увидит знакомый паттерн и сразу поймёт о чём речь
Vasyl Lytovchenko
Зависит от команды. Если ты попадешь в коллектив, где все, или подавляющее большинство говорит на языке паттернов — придется знать, ибо ничего не поймешь. Если нет — паттерны превращаются просто в список эффектов которых можно добиться, полезно, например для того чтобы знать что гуглить :), но не критично. Часто оказывается так что «я так всегда делал, а оказывается для этого есть умное обозначение».
Oleksandr Nenko
для початку було б корисно не називати шаблони проєктірованія шаблонами программірованія ;)
Grez
Вобщем все свелось к.
Никто не знает шаблонов (ктото чтото когдато читал, но забыл).
Никто никогда не работал в команде где все знают шаблоны.
При этом все утверждают что шаблоны не нужны, и бенефита от них никакого нет. ок.
Oleg Kariakin
Понимать паттерны важно, но гораздо важнее - использовать стандартные решения и переиспользовать существующие решения на проекте.
Дмитрий
считаю знание патернов полезным- расширяет общий язык терминов для обсуждения в команде, плюс это образцы хорошего, правильного решения некоторых задач.
Loboda Andriy
Патерни вивчають переважно джуніори, щоб швидше отримати ріст у зарплаті.
А потім ліплять їх усюди без розбору.
Sergiy Morenets
Вы хотите сказать, что миддлы и сеньоры не используют шаблоны ?
Используют) Только не знают об этом)))
Vadim Kopanev
Понимаю что знать нужно, но на сколько углубленно?для использования просто знать какие бывают и какие проблемы решают, дальше нагуглить и подпилить, самые ходовые проще выучить на память, а то задолбаешься каждый раз вникать где там что в примере
для собеседования нужно только синглтон в 95% случаев
В 95% случаев лучше как раз забыть про синглтон.
ну и не пройдешь собеседование в итоге
Ірина Музика
Сергей, эта тема активно обсуждалась на msdn — social.msdn.microsoft.com/...
Igor
Вопрос похож на:
насколько важно военному знать устав, водителю — ПДД, учителю — педагогику, электронщику — cxемотехнику..
Loboda Andriy
Швидше так: наскільки важливо водію вміти проектувати автомобільні мотори.
Утрируете, аналог водителя в айти — это юзер. А админ — механик на СТО. :)
профессиональный водитель не юзер, любитель — да
Vladislav Goreletsky
так это ж обычное дело, когда эти этого не знают
Што вы, ооп нынче ж не в моде. В моде ж фп, где нужно знать что такое тайпклас, монада, функтор, натуральная трансформация, дисюнкция, клайсли, трамполинг, и еще 100500 умных слов.
ксто свитч, чего свитч ? ПО моему мнению у тайп класу из мира ООП наиболее близкий паттерн «стратегия» (хотя всеравно немного не то). Но здесь в теме все такие умные, что без гуглежа наверняка и не знают что это такое.
Костя Третяк
— Шаблони проектування — це складові частини різних фреймворків.
— Фреймворки можна назвати аналогом культури у людей.
— Культура заточена під конкретні географічні, геополітичні, кліматичні, фізіологічні, історичні ... реалії. Вона є інструментом для збереження соціуму та його гармонізації.
Якщо в майбутньому вам не потрібно підлаштовуватись під ті умови, для яких писались шаблони проектування — вам не треба вивчати ці шаблони.
главное знать антипаттерны — сільвер буллет, лісапєд та інші
Євген Лесько
Две мысли. Первая — надо себе отдавать отчет, что те шаблоны, а также и то, что мы называем «антишаблонами», «антипаттернами», — конечно же, результат практики, причем недавней. Более того, то, что мы сейчас считаем моветоном, не всегда было таким, и наоборот: практики меняются, и возникают новые с возникновением предпосылок для них.
Вторая. Для меня сие — систематизация знаний, не более. Но и не менее. Важно также, чтобы вас понимали, в т.ч. не только коллеги, но и заказчики. Наглядный пример: там, нижее, употребляются слова фасад, декоратор, фабрика, адаптер, — и мы ± понимаем о чем это... а если не понимаем — ищем слово в википедии и понимаем заново :)
Понимаю что знать нужно, но на сколько углубленно?
Насколько требуют твои задачи. А учить, «шобы было» — неблагодарное дело, знания без практики, оно, как вода в песок.
Євген Лесько
И да, и нет ... Обучение — весчь как известно циклическая, и проходит путем накопления и закрепления в мазгах положительных и отрицательных шаблонов :) применения полученных знаний. Т.е. с одной стороны, если Вы перечитали теорию по винсокетам и ни разу не столкнулись с ними в своих задачах — да, ммм жидкость в песок :) Но как только Вы наступаете на практическую задачу, так сразу ота прочитанная 2 года взад и ни разу до сих пор не использованная Вашим мозгом статья, книга или лекция становится основой для дальнейшего поиска знаний. Т.е. голая практика в любом количестве без понимания хотя бы основ теории — это не есть гуд.
Serge Loboda
Теоретически шаблоны — хорошее подспорье. Вообще, чтение книг о шаблонах прививает правильные подходы к проектированию и позволяет избежать типичных ошибок. Нужно только не впадать в фанатизм и понимать где нужно применять Strategy, а где прописать switch и забыть. Но это с опытом. С опытом же шаблоны будут применяться неосознанно («а я не знал что это так называется»).
Насколько важно — зависит. Если у тебя работа — допиливать проект из говна и палок, то все эти знания помогут чуть более чем никак, ну или не дальше собеседования. Другое дело когда изначально делалось правильно, тогда придется соответствовать, как минимум, на среднем уровне команды.
Антон Касьянов
Коллега, даже в проекте из говна и деревяшек могут пригодиться паттерны. Например «фасад» и/или «адаптер» чтобы абстрагироваться от наиболее эпичных кусков кода. Знание АНТИ-паттернов тоже весьма помогает — заранее знаешь откуда могут проблемы прийти.
для початку було б корисно не називати шаблони проєктірованія шаблонами программірованія ;)
Дмитрий Бурмистров
Для начала было бы вам полезно изучить грамматику украинского языка. Таких слов нет ни в русском ни в украинском языках: “проєктірованія...программірованія” )
якщо вИ такий знавець українською мови, то «впєрьод», шо ш так ...
Alexandr Sova
С чего это вдруг? Давайте на примере: GOF — отправная точка в мир паттернов. Design Patterns.
Здесь говорится о паттернах проектирования и описываются простые и элегантные решения задач, возникающих в объектно-ориентированом проектировании.Идея в том что у тебя есть ишью, ты дизайнишь его решение используя паттерны, а только потом садишься писать результат своего проектирования.
Victoria Globa
Хорошо знать/понимать/уметь ООП — важнее, чем знать конкретные паттерны проектирования. А чтобы его хорошо понимать-уметь — придется прочесть какое-то количество классической литературы по OOAD. В том числе и ознакомиться с паттернами, уровня «ознакомился» уж точно хватит.
Есть и другой путь — вступить в ряды тех, кто яростно презирает ООП, тогда можно совсем не знать паттернов, поливать их грязью люди справляются и ничего не зная о них :)
Vitaly Chernooky
Если у тебя паттерны ассоциируются только с ООП то у меня для тебя есть плохая новость.
-
Почитайте в википедии соответствующую статью, посмотрите референсы на литературу, обратите весь гнев туда. Я ответила человеку в том смысле, в котором он употребил этот термин, а вы хотите перейти на личности и потешить эго — ну потешьте. Вы самый умный и умелый! Легче стало?
Sereban
с чем люди справляются не зная паттернов? баги фиксят?
знать/понимать/уметь ООП
а ничего что 1 из постулатов ООП (наследование на минуточку) уже ипать как устарел
С поливанием грязью справляются. Собственно вы вот только что доказали это. В ООП постулатов нет и быть не может, а наследование — не постулат, а часть ООП. Это подход к программированию, и подход, в котором не выделяются частично однородные классы объектов, не работает на них полиморфизм — потому что нет однородности, и т д, что там еще вы планируете выбросить, не будет называться ООП. Это будет ваш, придуманный вами, новомодный подход, но вы не сможете называть его ООП. И вы, не видя, не зная, не понимая этого, справляетесь крыть ООП матом. Вот ровно об этом я.
Alexey Romanov
Более важно знать антипаттерны и бэд практисес. А сами шаблоны — зависит от платформы/языка.
Mykola Sharhan
Коли читаєш чийсь код, можна зустріти в назвах класів: *Factory, *Command і т.п. В такому випадку зразу приблизно зрозуміло, що клас робить.
І що за переучений джуніор його писав.
Alex Bylim
когда был студент и работал над своим 3D движком на С++, время было много, все делал красиво — паттерны юзались на подсознании синглтоны, декораторы, фабрики, обсерверы так как все писалось с нуля (даже GoF книжечку прочитал). Но современный веб и мобайл дев, это набор фреймворков и либ, где уже все паттерны реализованы, и ты просто это все юзаешь, и юзаешь быстро потому, что сроки всегда горят( а когда пригорает тебе уже не заумных вещей, делаешь что бы работало). Юзаешь даже не замечая, что из этого можно выделить паттерны. Знать надо, но не фанатично зубрить. Наверное больше всего знанием шаблонов проектирования применяется девами на собеседовании или в написании систем и фреймворков с нуля, но если ты пишешь фреймворк с нуля, скорее всего ты все эти паттерны знаешь интуитивно.
Eugene Sliusarenko
На 30 сантиметров. Или в каких единицах Вам глубину погружения сказать?
Шаблоны знать нужно, если собираетесь писать софт, а не просто баги if’ами разруливать. Очень нужно, если работаешь в команде. Ну обязательно нужно, если работаешь в большой команде над большим проектом.
если програмист опытный — знание паттернов бесполезно — он и так их применяет даже не зная что это «паттерн». Для начинающих знание паттернов бесполезно потому что они не имея опыта разработки не имеют понятия куда эти паттерны приткнуть.
Самая большая польза от паттернов — для авторов книг про паттерны.
если програмист опытный — знание паттернов бесполезно
Если программист работает в команде таких же опытных, то когда все знают про паттерны, тупо легче коммуницировать между собой.
Леонид Мартынюк
никто никакими паттернами не комуницирует. В команде обычно обсуждаются технологические проблемы. В остальном каждый отвечает за свой кусок. И как правило кто то играет роль архитектора которые и определяет где чего.
Или вы серьезно думаете что происходят диалоги типа — Вася у тебя такой то кусок кода каким патерном написан? Человек берет код и смотрит что он делает. Если там паттерн ну значит паттерн не суть важно.
Еще раз — в основном паттерны полезны для учебников. Это как в институте — учишься пять лет потом устраиваешся на работу и учишься заново потому что полученые знания хоть и полезны мало помогают за конкретным рабочим местом и решении конкретной производственной задачи.
в том разница между нашим и западным образованием — у нас уча теорию (таблицу умножения например) а у них учат решать задачи и находить ответы а умножить и калькулятором можно.
Oleksij Lupandin
“Никто никакими паттернами не коммуницирует” і “Леонид Мартынюк никакими паттернами не коммуницирует” це дещо різні речі.
Или вы серьезно думаете что происходят диалоги типа — Вася у тебя такой то кусок кода каким патерном написан? Человек берет код и смотрит что он делает. Если там паттерн ну значит паттерн не суть важно.
В реальности мидл приходит к архитектору, с код ревью и говорит «я здесь захерачил регистр фасадов», и все все понимают, ненужно время архитектора терять на
берет код и смотрит что он делает.
А потом оказывается что то, что мидл понимал под регистром фасадов и то, что понимал архитектор это не одно и тоже.
Паттерны — это просто теория. Они потому и называются паттерны — то есть шаблоны. Я знаю только один паттерн, который можно более менее однозначно переложить на код — синглетон.
Поэтому на практике патернами жонглируют те кто любит надуть щеки и покидать умняки.
Серьёзно? Куча? Приведите тогда примеры какой кучей способов этот синглтон можно реализовать. В Java единственный известный мне способ реализовать синглтон — на уровне ClassLoader’а (enum не в счёт). На столько единственный что в Scala сказали «давайте мы лучше сделаем это за вас». youtu.be/grvvKURwGNg?t=3961
на уровне класс лоадера, обычный статик, лейзи инициализейшн, лейзи инициализейшн с дабл локингом, синглтон на енумах, еще чтото не помню что.
обычный статик, лейзи инициализейшн, лейзи инициализейшн с дабл локингомзабыли о сериализации/десериализации — стейт же не нужен, только поведение так что они не синглтоны.
ok. Ты ведь не упомянул о закрытии writeObject, а это не такая очевидная вешь как закрыть clone.
Но всё равно не понятно как гарантировать то что инстанс единственный если они загружаются разными ClassLoader’ами
Anastasiia Nevidomska
Не могу сказать насчет джавы, но для C# есть отлчиная статья от Джона Скита, автора книги «C# in Depth», с анализом разных вариантов синглтона (он приводит в пример 6 штук).
csharpindepth.com/...
Здесь у меня аргументов нет. Я действительно не знаю неочевидных способов получения второго инстанса в C# - может в этом аспекте он существенно от Java отличается, хотя приведённый код схож с тем что, например, на хабре.
Из очевидных — нигде не закрыт clone, но это, наверное, на столько очевидно что даже писать это в примерах кода нет смысла.
Aliaksandr Valialkin
В реальности мидл приходит к архитектору, с код ревью и говорит «я здесь захерачил регистр фасадов»
Я заворачиваю таких мидлов удалять из своего кода лишние абстракции.
у вас все мидлы всегда пишут в процедурном стиле ?
Alex Fogol
мидл приходит к архитектору, с код ревью и говорит "я здесь захерачилНе вполне понятно почему захерачил мидл когда есть архитектор и у него роль но в целом к реальности таки да оно и есть херак-херак и в продакшин.
Где-то лет 10 назад я прочитал банду четырёх, восхитился и решил, что отныне при удобном случае буду применять паттерны. За 10 лет удобный случай так и не наступил. Сейчас я уже почти всё забыл за ненадобностью. Проблем с коммуникацией никаких не было. Но я всегда был далёк от мира Java, откуда пошли эти идеи...
буду применять паттерны. За 10 лет удобный случай так и не наступил.
Вы либо программист на Пехопе. Либо просто не осознавали что те решения которые придумываете давно придуманны описани и имеют названия. Сама кор джава состоит из паттернов чуть менее чем полностью.
Но я всегда был далёк от мира Java, откуда пошли эти идеи...Точно, програмист пехопе (в этом ничего кагбы особо плохого нет конечно).
Андрій Дембіцький
Но не все же...
risovach.ru/...
яке відношення мова програмування має до використання чи не використання патернів?
если язык не ОО, то как в нем буш применять ОО паттерны ?
раньше не была, и в отличии от джавы, если захотеть, можна не писать оо вообще.
можна ще про гівно мамонта згадати, яке воно було, і яке стало... Так в контексті питання, що заважає використовувати патерни на ПХП, і не використовувати їх на джаві?
Еще раз, на джаве их тяжело не использовать; используеш "интерфейс" - а это оказываеться паттерн такой был ru.wikipedia.org/…
А в пэхопе именно что
що заважає
Совсем недавно видел код одного студента, олдскул макароны, где в одном файле пэхопэ, хтмл, джаваскрипт, скл. Все на ифах и свитчах, ога.
Совсем недавно видел код одного студентфейспалм. Добре що ти в код школяра не заглянув, думаю там взагалі біда)))
А в пэхопе именно чтоще раз фейспалм))))
що заважає
Еще раз, на джаве их тяжело не использовать; используеш "интерфейс"Ну і фінальний фейспалм) По перше - інтерфейс не патерн з ГоФ. По друге - на ПХП можна використувати інтерфейси. По третє - На джаві можна не використовувати інтерфейси (тут я можу помилятись, але наскільки памятаю працює саме так).
фейспалм. Добре що ти в код школяра не заглянув, думаю там взагалі біда)))
Ну про крутость свичей здесь в теме кто по вашему пишет ?
Ну і фінальний фейспалм) По перше - інтерфейс не патерн з ГоФ.
Тут возможно, какие из паттернов правосланые, и зачем включают в список "неправославные" - яхз.
По друге - на ПХП можна використувати інтерфейси.Вопрос использует ли ктото или нет.
На джаві можна не використовувати інтерфейси (тут я можу помилятись, але наскільки памятаю працює саме так).Это называеться "я джаву не знаю, но осуждаю".
Ну про крутость свичей здесь в теме кто по вашему пишет ?Як це відноситься до поточної гілки?
Тут возможно, какие из паттернов правосланые, и зачем включают в список "неправославные" - яхз.ти на комент відповідав конкретно про ГоФ.
Вопрос использует ли ктото или нет.статистику в студію. Чи
Это называеться "я джаву не знаю, но осуждаю".?
По останньому - я нічого не засуджую, на відміну від тебе). Я в джаві не експерт, так писав кілька аплікух на базі селеніума, і трохи рефакторив гівнокод індусів. Щодо конкретно цієї тези - я не правий?
Кстати, не надо обижать программистов на PHP, в нашем проекте код на нём самый богатый паттернами. Там даже папочки называются по именам паттернов: controllers, helpers, presenters, ... А я больше пишу на C++, Plain C, иногда таки да, bash, PHP, JavaScript, Python, MATLAB. Для себя Ada, Prolog, Haskell. В прошлом Delphi, Assembler.
Ну а так, допустим, есть задач: генерация словоформ шведского языка. Тут мои действия были примерно таковы: (1) разобраться в грамматике шведского языка, (2) понять, что средний и нейтральный род живут своей жизнью и почти не формализируются, (3) поискать базу и найти wiktionary, (4) проанализировать, что там живёт внутри XML, найти макроязык (сейчас там Lua, раньше были тысячи фигурных скобочек), (5) написать парсер макросом плюс маппинг, чтобы вытягивать словоформу, а также грамматическую информацию о ней (например, для сещуствительного это utrum/neutrum, число, определённый/неопределённый, притяжательный). Потом сохранить всё в базу плюс написать код для генерации незнакомых слов из наибольшего совпадения окончания слова. Всё писалось на PHP, и я не вижу, куда тут можно воткнуть какие-либо паттерны так, чтобы они приносили пользу.
flyman
Я знаю двух очень опытных программистов, которые учились программировать на заре компьютерной эры. Так вот, спагетти-код и год-обжекты — это далеко не самые большие их грехи, но зато они просто повсюду. Так что опытный программист — очень растяжимое понятие.
Kate Altman
Да, опытные люди за
опытный программист — очень растяжимое понятие.
Да, опытные люди заНамного старше. Компьютерная эра началась не в девяностых годах :)35-40 лет
Те кто начинал ещё раньше давно прикупили по майкрософту ораклу и привату и спокойно почивают в оффшорах на пенсии.
Sergey Sheshenya
Да ладно -в те времена у нас платили айтишникам не так как сейчас, и они не были лидерами рынка по зарплате. В
кто начинал ещё раньше давно прикупили по майкрософту ораклу и приватуВы так говорите как будто тут есть зависимость с возрастом, причем прямая пропорциональность :)
самые большие проблемы «Старых Собак» — ЧСВ, неумение общаться, негибкость мышления, они часто используют старые подходы там где они концептуально неправильны, отсюда и спагетти код. Еще часто грешат незнанием матчасти для новых технологий, и не щитают это проблемой. Применение паттернов не там где оны не нужны я больше замечал за стариками, джуниоров таких не видел.
Мне смешно ,когда людей в 35 −40 лет называют стариками))
Це приблизно те ж саме, що казати: «Якщо водій досвідчений, то знання Правил дорожнього руху марне — він і так їх виконує, не знаючи, що це „правило дорожнього руху“. Для початківців знання Правил дорожнього руху марне, бо вони, не маючи досвіду керування автомобілем, не знають, де ці правила приткнути. Найбільша користь від Правил дорожнього руху — для авторів книг про Правила дорожнього руху».
Пример неудачный. ПДД — конвенциональны
В целом да. Ньюб, который еще в педалях путается, ему главное по зеркалам не забывать сомтреть и поворотники включать. А опытный водитель дорогу чует и без знака догадывается, кого пропустить, а где притормозить.
А самая большая польза от ПДД пацанам котрые в чистом поле ставят знак 40.
А я-то думав, що насправді найбільша користь від них — для спільноти водіїв, які завдяки Правилам дорожнього руху не натикаються своїми автомобілями на інші. А а воно, виявляється, для тих пацанів зі знаком 40 призначено. Бачите, як я помилявся?
Та невже? Все 100+ страниц?
Кстати по селам ездят ваще как хотят — вопрос плотности траффика и негласного общественного договора.
Все 100+ страниц?Уточніть, будь ласка, питання.
Кстати по селам ездят ваще как хотятЦе не спростовує того, що від правил дорожнього руху найбільша користь іде учасникам дорожнього руху.
Погана аналогія псує все. Паттерни — аналог не ПДД, а правил типу «відпусти гальмо, коли загорівся червоний+жовтий» або паралельної парковки.
Victor Zinchenko
Просто поражает количество поддержавших этот комментарий.
Так тут же в основном програмисты практики а не преподаватели вузов и курсов программирования
Вы правда думаете, что паттерны — удел только авторов книг про паттерны и преподавателей?
Иногда к авторам книг и преподавателям присоединяются java-господа — cs7063.vk.me/...
Картинка не стосується патернів проектування.
Это хорошо — есть повод задуматься.
если програмист опытный — знание паттернов бесполезно — он и так их применяет даже не зная что это "паттерн"так не бывает, разве что программист — аутист, обычно или знают и применяют, если нужно, или нет, а вот этих изобретателей паттернов, не зная что такое уже есть, просто не существует
так не бывает,
Не просто «бывает», а сплошь и рядом.
а вот этих изобретателей паттернов, не зная что такое уже есть, просто не существует
А вот дать им имена — на такое уже нужно было явное усилие.
Mykyta Zhuk
в такой трактовке паттерны выглядят какой-то производной инфобизнеса.
если программист вордпресс мен, как и автор коммента — то вообще не нужно.
А вообще вопрос из разряда:
«Насколько важно уметь говорить, если я и так понимаю что говорят другие»
не знаю при чем тут вордпрес не имею о нем понятия но паттерны это абстракция. И каждый разраб имплементит их по своему(просто потому что задача у каждого своя в соответсствии с ТЗ) а значит, если код не прокоментирован сторонний разработчик все равно не поймет что тут за паттерн а если прокоментирован то какая разница паттрен там или нет.
По факту программа должна имплементить не паттерны а бизнес-логику в соответсвии с техническим заданием. Я не видел ТЗ на програмный продукт где написано — реалиуйте такой то паттерн (коме курсовых в универах).
На паттерны фапают в основном начинающие программисты которые начитавшись вумных книг думают что получили какое то сакральное знание.
Книги типа как стать милионером мало помогают стать им в реальной жизни, хотя там все правильно написано.
Denis Pakizh
Надо выучить только MVC, а потом ху*к, ху*к и в продакшен!
1. Важливо, аби пройти співбесіду, на 90% питають.
2. Важливо, аби розуміти код, бо все ж, в більшості проектів в тій чи іншій формі використовуються.
3. Важливо, якщо пишеш новий функціонал, аби не вигадувати велосипедів.
4. Ну і критично важливо, якщо плануєш архітектуру, але ті, хто за таке відповідають, не задають таких запитань.
Eugene Nuribekov
Скажем так — надо быть осведомленным на этот счет.
Пяток самых ходовых надо помнить, про остальные знать место в книжке.
Олег Бышевский
Вот например популярный паттерн Стратегия ru.wikipedia.org/...
Dmitry Pashkov
switch — большое зло. Будет у вас 3 стратегии. Нормально. Но а будут добавляться и станет их больше десятка, сотни? switch будет расти расти... Отсюда — возможные ошибки копи паста, плохая модульность, не удачный подход при тестировании, и что самое важное — нарушение Open-Closed принципа. Т.к. чтобы добавить поведение, Вам нужно будет изменять уже протестированный, работающий в проде код, что может повлечь за собой кучу ошибок в старом коде.... Так же, свичом здесь можно нарушить много других патернов... И это еще только начало.
Главное улавливать тот момент, где надо стратегию, а где хватит и switch
Если есть вероятность, что количество опций возрастет. То если, у нас будет более чем, допустим 3 разных поведения, то есть смысл задуматься о том, чтобы сделать рефакторинг сейчас, чем оставить это на тот момент, когда это будет уже сложнее. Если же Вы уверены что switch case не будет содержать никогда больше кол-во вариантов. Например, у Вас там enum с полом — мужской/женский — то если логика однострочная — switch оправдан. Иначе — можно фабричный метод, стратегию, цепочку и т.д. Зависит от предметной области. Но это будет в 10 раз проще тестировать и поддерживать. Стараюсь switch никогда не использовать. Если вижу несколько if подряд — применяю паттерны. Так как тестировать метод с 10 if -ами — очень сложно. Нужно написать кучу тестов на каждое условие. Прежде замокать предыдущие условия. Потом написать тест на то как это все в куче будет работать... А потом... А потом все равно эту ерунду всю переписать.
Котэ
Например, у Вас там enum с полом — мужской/женский — то если логика однострочная — switch оправдан.Есть уверенность, что в этом случае нужен именно свитч, а не иф-элс?
Если, конечно, в будущем не планируем учитывать "меньшинства".
Это все бла-бла-бла. Давайте контрпример. Пока есть один факт — switch сокращает и упрощает код в 10 раз по сравнению с высосанными из пальца и притянутыми за уши паттернами проектирования.
Пожалуйста. Это не совсем о паттернах, больше о нарушении OCP, но подтверждает точку зрения о том что совать switch везде — крайне плохая идея
Не хочу смотреть 1.5 часа видео, где главный впариватель SOLID и прочей чепухи ездит по ушам доверчивым зеленым джуниорам, доказывая полезность overengineering на примере сферических коней в вакууме.
Он на этой сомнительной теории всю жизнь капусту стрижет (т.к. нормально программировать не умеет), а нам потом расхлебывать говнокод, написанный с ее применением.
Попробуйте найти хоть одно видео, где Linus Torvalds или любой другой известный программист-практик рассказывает что-нибудь подобное. Не удается найти? Подумайте, почему.
совать switch везде — крайне плохая идея
С этим никто не спорит — switch, как и любой другой инструмент, нужно использовать лишь там, где это необходимо. Но, в отличие от паттернов проектирования и SOLID, у switch на порядок более широкая сфера применения в продакшн коде.
Не хочу смотреть 1.5 часа видеотак и не надо. Там ссылка с привязкой ко времени. Главный вопрос — что делать если добавляется ещё один кейс.
Попробуйте найти хоть одно видео, где Linus Torvalds или любой другой известный программист-практик рассказывает что-нибудь подобное. Не удается найти? Подумайте, почему.Может потому что Торвальдс терпеть не может ОО языки начиная с C++. Или теперь все ОО языки являются
сомнительной теорией? Каких ещё программистов-практиков поискать? Мы же о практиках ООП говорим, да? Сначала думал Фаулера привести в пример — его ведь нанимают большие компании для приведения кодбэйза в порядок, но подумал для вас он может быть не авторитетом так как написал «P of EAA». Может тогда Эванс, что занимается тем же? Так он постоянно говорит о важности своевременного применения паттернов и обязательного следования SOLID принципам.
Jorzchyk Pushysty
Может потому что Торвальдс терпеть не может ОО языки начиная с C++.
Но он же их не просто так терпеть не может.
Каких ещё программистов-практиков поискать? Мы же о практиках ООП говорим, да?
О программистах-практиках.
Bob Martin, Martin Fowler, Eric Evans — можно ссылки на их код?
Alex Koshterek
Судя по его нервным реакциям, это нечто религиозное)
Пересмотрел. Честно, не знаю что там нервного. А поповоду религии — сейчас больше использую функциональный подход в Java 8 и Scala так что тут тоже не в тему.
Я Линуса имел в виду. Истерики периодически бывают знатные
не просто такДа — они не подходят для его задач.
ссылки на их кодда, у меня их нет, но то что они не пишут открытый код не значит что они не пишут код совсем. Хотя опять таки, примеры своего кода они приводят в книгах.
Может потому что Торвальдс терпеть не может ОО языки начиная с C++.
Тем не менее ядро использует принципы ООП в 100500 местах (а вообще в Unix они использовались ещё задолго даже до Страуструпа и Буча, хотя не буду говорить, что до Simula и Smalltalk).
Так и стандартные C функции типа getchar, putchar используют инкапсуляцию и полиморфизм (о чем, кстати, тот же Боб Мартин говорил). Просто стоимость таких решений для не-ОО языков достаточно высока. Именно потому в не-ОО средах эти принципы используются не повсеместно. Используя ОО языки мы эти возможности получаем практически бесплатно.
Так и стандартные C функции типа getchar, putchar используют инкапсуляцию и полиморфизм (о чем, кстати, тот же Боб Мартин говорил).
Ну если придраться, то не очень. И struct FILE как бы не имеет private полей, и полиморфна она только в тех libc, где есть средства замыкания (это включает в себя GNU libc, все BSD, OS X и почти все другие цивилизованные, но не MS и не в стандарте).
Мартина не смотрел и не буду, у меня нет времени и настроения слушать и смотреть полтора часа пусть даже гениальной воды вместо текста.
Просто стоимость таких решений для не-ОО языков достаточно высока.
То, что есть в stdio или в ядре, не имеет высокую стоимость — ну что дорогого в foo->foo_softc->sync(foo) вместо foo->sync()?
Немного более громоздко, но и всё. Итоговый код совпадает до байта.
Может, у него мысль и правильна, но примеры неудачны — совсем её не подтверждают.
Используя ОО языки мы эти возможности получаем практически бесплатно.
Я согласен разве что в случае синтаксического сахара и контроля доступа к закрытым членам. Остальное одинаково.
Придираться нужно в другом направлении. Я говорил о том что для putchar не нужно знать — выводит она символ на экран, или на принтер. Не нужно знать какой драйвер используется на подкорке. И в одном и другом случае это будут реализации сигнатуры из одного и того же .h файла.
что дорогого в foo->foo_softc->sync(foo) вместо foo->sync()?Я в этом коде вижу только нарушение закона Диметры.
разве что в случае синтаксического сахараодно то что для инкапсуляции и полиморфизма не нужно создавать отдельную либу а потом думать что же включить тут или там, то что не нужно по-разному префиксировать функции для того чтоб они по-разному достигали того же результата и то что функции с одним и тем же именем (в разных классах) можно использовать для композиции — уже и есть уменьшением стоимости. И это уменьшение по сравнению с подходом разных либ на столько велико что мы это получили «практически бесплатно».
Но да, (почти) всего этого можно было добится и до ОО языков и из-за высокой стоимости этого добивания это было не обязательно.
Мартина не смотрел и не будуок, не заставляю. Просто пример что подвернулся под руку. Благо таких примеров хватает.
Придираться нужно в другом направлении. Я говорил о том что для putchar не нужно знать — выводит она символ на экран, или на принтер.
Вообще-то надо. Только это знание реализуется косвенно в виде выбранной дисциплины буферизации. putchar(), конечно, сама это не считает, она просто смотрит на параметры в struct FILE.
А если предположить, что буферизация одинакова, тогда конкретный вариант устройства уже за «железной стеной» в виде ядерного интерфейса.
Я ж говорю — пример неудачный. У него та же проблема, что недавно у Ништы в статье здесь — иллюстрация принципов, резко специфичных для прикладного программирования, на объектах предметной области системного программирования. Им кажется, что так будет понятнее, но в результате получается сидение не в своих санях.
Я в этом коде вижу только нарушение закона Диметры.
Это с чего вдруг? Тут в обоих случаях банальный вызов собственной виртуальной функции объекта.
одно то что для инкапсуляции и полиморфизма не нужно создавать отдельную либу а потом думать что же включить тут или там,
Эээ... #include <polymophism.h>, что ли? Или я вообще не понимаю эту мысль.
В остальном в целом где-то согласен, хотя форма изложения меня сильно смущает.
Используя ОО языки мы эти возможности получаем практически бесплатно.
Lol, нет. Вам кажется, или вы хотите верить, что получаете их бесплатно.
Линус не хочет видеть в своём проекте участников, которые не знают, не понимают или не замечают цену используемых решений.
Короткий пересказ его письма выше.
Именно поэтому они без проблем используют приёмы, обычно считающиеся ООП-шными — когда это нужно, ограниченно, и с полным контролем реализации — но сторонятся ОО языков.
где главный впариватель SOLID и прочей чепухиА можна детальніше, прикладом, де хоч один з принципів SOLID можна назвати шкідливим, або непотрібним?)
когда чего-то не знаешь лучший вариант гнать на это, так выглядишь не неучем, а нонконформистом
Например, большинство популярных open source проектов — ядро Linux, nginx, postgresql, sqlite, chrome, firefox — список можно продолжать до бесконечности — написаны не по принципам SOLID. Интересно, с чего бы это?
Хотелось бы увидеть open source проекты, написанные согласно принципам SOLID.
Хіба питання про це було? Є багато не ООП проектів (нежданчик). А яким боком не ООП може відноситись до SOLID і навпаки?
Хотелось бы увидеть open source проекты, написанные согласно принципам SOLID.думаю SharpDevelop, во всяком случае беглый взгляд по нему не заставляет морщиться, вообще не сильно интересуюсь таким, полистай крупные проекты на ооп языках, их очень много по солиду
Но а будут добавляться и станет их больше десятка, сотни?
YAGNI, не, не слышали. А это принцип из той же серии, что и SOLID.
Вы пытаетесь заранее опримизировать код под будущие изменения.
Причём не любые, а те, которые не нарушат вам структуру классов.
Preemptive optimization is the root of all evil ©
Т.к. чтобы добавить поведение, Вам нужно будет изменять уже протестированный, работающий в проде код, что может повлечь за собой кучу ошибок в старом коде...
Ум, вроде мне говорили, что это тестами обеспечивается, не?
что самое важное — нарушение Open-Closed принципа
Есть люди, для которых самым важным являеся простота/читаемость/скорость/надёжность кода.
А не произвольные принципы, сформулированные кем-то-там.
YAGNI, не, не слышали. А это принцип из той же серии, что и SOLID.а еще он не конфликтует с солидом, вообще, то что ты пытаешь под него подсунуть называется пишем говнокод, пока гром не грянет, тебе стоит его переосмыслить, ты ухватился за название, а не за смысл
а еще он не конфликтует с солидом
Wat.
вообще, то что ты пытаешь под него подсунуть называется пишем говнокод
Я не знаю инженерного смысла этого термина.
Если «говнокод» = «код, который мне не нравится», дискуссия не имеет смысла.
ты ухватился за название, а не за смысл
Суть YAGNI здесь: switch на три элемента можно расширить до четырёх, можно заменить на несколько классов (когда это будет нужно), а можно убрать. Обратная замена гораздо сложнее, потому что switch на три элемента проще читается и понимается, чем три класса. Преждевременный выбор трёх классов вместо
Я не знаю инженерного смысла этого термина.ну да и многое другое, гуглить надо наверное
Суть YAGNI здесь: switch на три элемента можно расширить до четырёх, можно заменить на несколько классов (когда это будет нужно), а можно убрать. Обратная замена гораздо сложнее, потому что switch на три элемента проще читается и понимается, чем три класса. Преждевременный выбор трёх классов вместозачем классы на свич менять? рефакторинг это не усложняет, если не писать код в блокноте; нифига не удобно как ты говоришь вместо ооп писать в императивном стиле3-х элементного switch’а усложняет рефакторинг в сторону упрощения кода — в дальнейшем такой код будет только распухать.
зачем классы на свич менять?
Действительно, зачем?
Условия задачи изменились, и вместо трёх стратегий осталась одна.
Switch выродился в тривиальное условие, это сразу видно, его убрали.
А классы остались. И вместо прямого линейного кода у вас интерфейс, одна реализация, injection этой реализации, непрямой вызов в другой файл, и необходимость давать этому всему имена.
ну да и многое другое, гуглить надо наверное
А классы остались.а чего классы-то остались?) что за бред?)
И вместо прямого линейного кода у вас интерфейс, одна реализация, injection этой реализации, непрямой вызов в другой файл,в этом нет ничего плохого, уверен что будь бы там всегда одна стратегия ее нужно было бы вынести в отдельный класс, интерфейс тоже не повредит
и необходимость давать этому всему имена.это типа сложно?
а чего классы-то остались?) что за бред?)
Изменяем условия задачи так, чтобы появилась необходимость в 3х условных ветках. В коде появляются новые классы: интерфейс и 3 стратегии. Изменяем условия задачи назад, к исходной точке. Необходимость иметь 3 стратегии исчезла. Из кода уберается 2 стратегии, но интерфейс и одна реализация (2 лишних класса) остаются.
Задача вернулась к исходному состоянию, код — нет.
в этом нет ничего плохого, уверен что будь бы там всегда одна стратегия ее нужно было бы вынести в отдельный класс, интерфейс тоже не повредит
github.com/…
это типа сложно?
Изменяем условия задачи так, чтобы появилась необходимость в 3х условных ветках. В коде появляются новые классы: интерфейс и 3 стратегии. Изменяем условия задачи назад, к исходной точке. Необходимость иметь 3 стратегии исчезла. Из кода уберается 2 стратегии, но интерфейс и одна реализация (2 лишних класса) остаются.складывается впечатление что тебе классы нужны только там где если необходимость ветвления, но тебе больше нравится свич и программа в одну функциюЗадача вернулась к исходному состоянию, код — нет.
там изначально должен был быть класс, потому что явно логика с другой ответственностью
github.com/…FizzBuzzEnterpriseEdition
duckduckgo.com/…blems in computer sciencerisovach.ru/…
это тестами обеспечиваетсятестами обеспечивается то что ты узнаешь что что-то где-то в коде что использует модифицированый код сломалось. Или... не узнаешь — зависит от теста. .даже если узнешь — это повлечёт за собой модификации в разных местах проекта. Причём иногда в местах не связанных с текущей задачей. Это т.н. «хрупкий код». Очень проблематично его поддерживать. А если код, что уже протестирован и работает расширять не изменяя — ничего не сломается.
Если стратегий станет больше десятка или сотни, то тут при любом подходе будет несладко. switch будет расти, число классов будет расти... Преимущество switch всё-таки, что весь код, относящийся к некоторой логике, находится в одном месте. А в случае стратегий он получается размазан по всему проекту: инициализация стратегий в одном месте, код каждой стратегии отделён от контекста, где он выполняется. В результате правка кода может понадобиться в нескольких различных местах. Да и требуемое место найти может быть нелегко, ещё со времен Smalltalk живет одна из фичей ООП с небольшими методами, когда требуемый код выполняется неизвестно где, но не здесь :)
Стратегия даст преимущество там, где есть несколько одинаковых switch-ей, выбор из которых делается в одной точке. Тогда да...
Я ради интереса сделал поиск по коду в одном из своих проектов, где используется switch.
for (;;) {
int index = 0;
int c = getopt_long(argc, argv, "ihsv", long_options, &index);
if (c == -1) break;
if (c != 0) {
switch (c) {
case 'h':
opt_help = 1;
break;
// Ещё три аналогичных штуки
case '?':
msg(stderr, "Invalid option.");
return 1;
default:
msg(stderr, "getopt_long returns unexpected char \\x%02X.", c);
return 1;
}
}
Во-первых, я не вижу ни одной проблемы возможной проблемы в использовании switch тут. Да, опций может быть десятки, но код обратобки каждой из них однотипен, плюс добавление каждой новой опции вряд ли может что-нить поламать.
Большой копипасты тоже делать не надо, потому как код возле каждого case вряд ли будет сложнее, чем set_int_value(&var, value).
Модульность тоже соблюдена, разбор командной строки расположен в одном месте, а не размазан по всему проекту. Все параметры командной строки также собраны в одном месте, что тоже неплохо. Решение, при котором опция определена там, где используется, мне не очень по душе как раз из-за того, что если задача связана с командной строкой, то у меня сразу область изменения ограничивается одним файлом, который несложно найти. А не всем проектом.
Тестируется всё одинаково: тестовый запуск программы с нужной опцией и проверка возвращаемых результатов. Как-то тестировать код установки одной опции глупо в виду его тривиальности.
Open-Closed... Не знаю, как я уже писал, тут, от его соблюдения, больше головной боли. Непонятно, как можно сломать существующитй функционал, плюс тесты всё быстро определяет.
Ну хорошо, попробуем, как будет тут выглядеть стратегия. Возникает проблема, как проинициализировать все возможные классы. Это дополнительный код, который тоже может содержать ошибки. Да, можно выбрать массив из 127 элементов (или std::map), и его выборочно инициализировать, типаcommand_line_option_strategy['h'] = SetCommandLineBoolOption("help", no_argument, &opt_help, 1, "Print usage and terminate.");
Ну а потом написать дополнительный код, который сформирует long_options, сформирует метод print_usage, который перечислит все опции и выведет результат с автоматическим выравниванием, написать код, который будет в цикле вызывать getopt_long... Но, как по мне, это перепроекторование. Лучшее — враг хорошего. Да, в моём варианте можно забыть добавить описание новой опции в print_usage. Но это не смертельно и быстро исправляется, легко поддерживается, причём с нуля. В отличие от кучи дополнительного кода, с которым должна идти сопроводительная документация по каждой стратегии, ...
Євген Козлов
шаблонный метод, фабрики всех типов и билдер заменяются на switch, да.
но потом и наступает состояние «запутанная лапша», которую сложно дебажить и расширять без последствий
то ли весеннее обострение нашло, то ли полгода колупания в старом коде разной степени overengineering, но спорить насчет switch’a не хочется совсем. забавно.
по крайней мере, далеко не любой if надо менять на стратегию. и не любой switch.
десь два тижні тому переписував легасі світч на стратегію. Просто тому, що цей код неможливо було читати. І кількість коду (нежданчик) вдвічі зменшилась.
Похоже на сказку. Не верю. Обычно после применения паттернов проектирования к нормальному коду, объем кода и сложность его понимания вырастает минимум в два раза. Обратные примеры видел только в книжках.
ну не вір, твоя справа)
Serge Loboda
Ну, понеслась!
Вот например популярная привычка мыть руки перед едой. Я так не делаю, и экономлю кучу денег на воде, мыле и газе для нагрева воды. ;-)
---
А если серьезно — это и есть наша работа как девелоперов определить, когда нужна «Стратегия», а когда и простого свитча хватит. И как раз знание паттернои и антипаттернов (возможно, в Вашем случае как раз и был антипаттерн с использованием Стратегии, что-то типа «пихай паттерны везде, где можно») и поможет разработкику писать нормальный легкоподдерживаемый код.
Олег Бышевский
Скажите пожалуйста, чем дописать один кейс в оператор свитч «труднее и запутанее» чем дописать новый класс у кучу связей его с уже существующими?
Советую задать себе этот же вопрос лет через
Я задавался этим вопросом более 10 лет назад. До сих пор не понимаю, зачем некоторые программисты наворачивают кучу бесполезных абстракций с паттернами проектирования вместо того, чтобы писать краткий и понятный код.
желательно, на го.
У меня для вас плохая новость. Если у вас класс стратегии требует «кучу связей с уже существующими» (причем как я понимаю, эти связи заметно сложнее «чем код в свиче»), то у вас проблемы с дизайном кода приложения (как минимум SOLID трещит по швам).
И второе — эти свичи имеют неприятную привычку расползаться по коду (2 свича поправили, про третий забыли, ага) и через пару лет в спагетти-коде уже черт ногу сломит. И в итоге случайно влезший в код джуниор ломает всё вдребезги пополам.
Аккуратненькими подпорочками :)
какой SOLID? Он же написал — он добавляет case в switch на каждое изменение
Vitalii Rastvorov
Зачем знать, нужно рвать.
Зависит от команды. Если ты попадешь в коллектив, где все, или подавляющее большинство говорит на языке паттернов — придется знать, ибо ничего не поймешь. Если нет — паттерны превращаются просто в список эффектов которых можно добиться, полезно, например для того чтобы знать что гуглить :), но не критично. Часто оказывается так что «я так всегда делал, а оказывается для этого есть умное обозначение».
Dmitry Pashkov
Знания в паттернах нужны.
А нужны они по причинам, вытекающим из самого определения паттернов.
Если в двух словах — это решения для часто возникаемых задач.
Следовательно, используя эти решения, ты стандартизуешь свой подход, и тот, кто будет работать с твоим кодом дальше, сразу сможет увидеть это решение, и понять его, даже не заглядывая в детали. Если же каждый раз делать велосипед — то, вышеприведенного бенефита вы не получите.
Также очень полезно знать их в плане того, что общаясь с коллегами и приводя названия паттернов в качестве решения определенных проблем, гораздо легче представлять, что человек имеет ввиду, чем он будет детально описывать свою точку зрения.
Я уже не говорю про SOLID, про то, что будет легче тестировать ПО и другие архитектурные преимущества.
Если же каждый раз делать велосипед — то, вышеприведенного бенефита вы не получите.
В программировании сделать совсем уж велосипед не получится, обычно попадаешь в какой-то шаблон, даже не зная его.
Также очень полезно знать их в плане того, что общаясь с коллегами и приводя названия паттернов в качестве решения определенных проблем, гораздо легче представлять, что человек имеет ввиду, чем он будет детально описывать свою точку зрения.
Это главная и почти единственная польза. :)
Некоторые шаблоны люди пишут, действительно, не зная о них. Просто выбирают оптимальное из решений, и «случайно» имплементируют определенный паттерн. Но, если есть знания об основных паттернах, то найти такое решение становится проще и быстрее. То же самое касается и его реализации. Более того, до некоторых паттернов, не зная о них, не всегда так просто дойти самому. e.g. visitor или observer.
Dmytro Lapshyn
Некоторые шаблоны люди пишут, действительно, не зная о них.
А некоторые люди лепят вместо шаблонов switch :)
Volodymyr Kuksynok
Знати треба, але не зациклюватись, бо важливо знати як їх правильно використовувати. Бо правельний патерн в неправельному місці гірше ніж його відсутність.
Олександр Федоров
ровно настолько, чтобы была возможность поговорить об этом на собеседовании
если ты их понимаешь, то ты их используешь, а значит и обсудить можешь. если ты их не понимаешь, то и учить нет смысла.
Mobile
да вообще можна забить, знаю пару человек кто писал большие системы за десятки тысяч долларов — никто никаких паттернов не пользовал. Паттерны нужны только когда у тебя в приложении пользуется ООП и начались сложные терки между классами. Типа этот какой то класс должен апдейтить состояния объектов других классов или твои классы используют наследоваение от какого то родительского класса, или у тебя есть сложная иерархия объектов. Тогда ты сам того не зная можешь применить какой то шаблон и знание шаблонов просто спасет тебя от граблей. Я сам в шаблоны пытался въехать раз 10, читал мудрые книжки и даже пробовал книжки на русском читать — думал так оно понятнее будет, в конце концов на прошлой неделе прочитал в одной книге как шаблоны реализованны на 3м питоне и понял что некоторые из них я уже давно пользую и просто не знал как они называются.
DNA Exp
На начальном этапе особо себе голову не забивать.
Перепроектированое приложение значительно сложнее сапортить чем недопроектированое.
Личное мнение (остальные могут не согласиться) — на первых порах хватает просто иметь общее представление — для этого достаточно сесть и почитать литературу. Это даёт возможность в нужной ситуации вспомнить, что возникшую проблему решает какой-либо паттерн, за деталями реализации можно уже обратиться к той же литературе. Со временем это само собой вбивается в голову, не нужно сидеть и зубрить, тут важно осознание полезности и применимости конкретного паттерна в конкретной ситуации. А в общем и целом ответ очевиден — как можно лучше, главное понимать когда и зачем они нужны.
Думаю надо знать углублённо. Т.к.:
1. Мозг начинает оперировать объектами более сложной структуры. Т.е. программист поднимается на более высокий уровень абстракции, видит систему с более высокого уровня, что помогает понять систему в целом, нежели детали реализации отдельных частей
2. Программист получает опыт предыдущих поколений. До него люди писали код и с годами сформировались некие типовые решения. Т.е. если с умом этим пользоваться — можно:
А. Повысить перфоменс, не изобретая каждый раз новый велосипед (опять же с умом пользоваться, не надо пытаться подогнать «не подгоняемый» код под паттерн в ущерб характеристикам системы, понимаемости кода и т.д.)
Б. Повысить читабельность кода. Другой девелопер увидит знакомый паттерн и сразу поймёт о чём речь
Найкращі коментарі пропустити