Не могу понять шаблоны программирования

16

Я работаю с Javascript в течение последних 4 лет. Я очень уверен в своих навыках решения проблем и вижу, что качество моего кода улучшается. Я стараюсь быть в курсе событий сообщества, и в настоящее время я работаю с ES2015 и React.js. Однако я чувствую, что вообще не могу понять шаблоны проектирования программ. Я знаю, где найти ресурсы об этом, и я уже читал книги об этом. Я полагаюсь на своих старших сотрудников, которые принимают решения о структуре проекта, но у меня нет проблем с этим.

Всякий раз, когда мне нужно что-то запустить самостоятельно, я ищу следующие два пути: если я использую большую библиотеку / фреймворк, такой как React.js, я склонен копировать то, что делает сообщество; Если я нахожусь на чем-то меньшем, я буду использовать шаблон модуля. Я знаю, что как только у меня появится лучшее понимание по этому вопросу, я смогу принимать более правильные решения, но сейчас я полностью потерян.

Должен ли я искать высшее образование по этому вопросу? Нужен ли мне наставник на эту тему? Я просто тупой? Это действительно так сложно понять?

design-patterns javascript

— Abensur
источник

6

По моему мнению, некоторые языки более «прощающие», чем другие, когда речь идет о необходимости использования шаблонов проектирования. Плохо типизированные скомпилированные языки (такие как Java и C #) более подвержены плохому дизайну, чем слабо типизированные языки сценариев, такие как JavaScript и PHP. Конечно, нельзя сказать, что шаблоны проектирования бесполезны для обоих.

— Матфея

3

Размер проекта также играет значительную роль.

— Матфея

2

@ Мэтью придурок Я бы не стал называть Java / C # строго типизированным ...

— Джаред Смит

2

@JaredSmith true, я часто забываю различие между строго типизированным и статически типизированным.

— Мэтью

6

Если вы пытаетесь понять паттерны undertsand в целом , остановитесь! Там ничего нет! Шаблон - это популярное решение часто встречающейся проблемы, и кто-то дал ему имя. Это все, что нужно сделать. Вам может быть трудно понять какой-то конкретный шаблон - я сам пытаюсь вспомнить, как эффективно использовать шаблон «посетитель» для имитации двойной диспетчеризации в Java - но если вы ищете секретный соус, который связывает «посетитель» скажем, «объект передачи данных», вы не найдете его. Это всего лишь два популярных решения двух распространенных проблем: кто-то дал им имена, а имена застряли.

— Соломон Медленный

34

Шаблоны разработки программного обеспечения - это хорошо известные решения известных проблем. Вы понимаете их, изучая шаблоны, понимая, как они работают, и зная, когда уместно применять каждый из них к дизайну вашего программного обеспечения.

Вы изучаете шаблоны проектирования программного обеспечения, изучая их по одному. Это непрерывный образовательный процесс. Если вы хотите уменьшить объем обучения, изучите те шаблоны, которые непосредственно связаны с технологиями, которые вы используете в настоящее время.

Некоторые важные вещи, которые нужно знать о шаблонах проектирования:

Некоторые шаблоны дизайна носят архитектурный характер. MVC и MVVM являются примерами таких шаблонов. Вы используете такие шаблоны, когда вам нужны организационные и структурные преимущества, которые они предоставляют.
Некоторые шаблоны проектирования - это обходные пути для недостатков в языках программирования. Вам не понадобятся эти шаблоны, если вы используете более выразительный язык программирования, но часто вы не можете сделать этот выбор. Большинство паттернов GoF находятся в этой категории .
Используйте программный шаблон только тогда, когда вы пытаетесь решить проблему, для которой этот шаблон специально предназначен. Если вы пишете приложение, соединяя программные шаблоны, вы делаете это неправильно.
Не существует существующего программного шаблона для каждой существующей вычислительной проблемы. В этом случае программирование было бы просто упражнением по сопоставлению с образцом.
Некоторые модели на самом деле являются анти-шаблонами. Дополнительная сложность, которую представляют эти шаблоны, перевешивает преимущества, которые они предоставляют. Вы должны будете решить для себя, по шаблону, какой из этих шаблонов вы будете избегать.

— Роберт Харви
источник

Хороший ответ, хотя я бы не согласился с утверждением о том, что большинство шаблонов GoF обходят недостатки в языках программирования. Часто некоторые шаблоны лучше подходят для определенных языков, да, потому что языки, как правило, разрабатываются с учетом определенных проблем и решений.

— Полигном

1

Образцам Gof 20 лет. Большинство из них были созданы для устранения проблем с C ++, проблем, которые Java унаследовала, потому что Java основана на C ++.

— Роберт Харви

Парадокс в этом ответе - часть «хорошо известной проблемы». Трудно понять эти "известные проблемы", если вы никогда не сталкивались с ними.

— Фурманатор

2

Java не основана на C ++. Javas синтаксис это вдохновило на C ++, но его , конечно , не на его основе. оба языка работают довольно по-разному. Из того , что Java абстрактном оборудования, управляет памятью сама по себе, не имея над шаблонами , а скорее дженериков и т.д.

— Polygnome

4

Подход к обучению у всех немного другой, и я понятия не имею, каков ваш общий подход, но я верю, что вы оказываете себе медвежью услугу, называя себя «глупым».

Лично из моих наблюдений за тем, что многие называют «успешными» разработчиками программного обеспечения, дизайнерами и т. Д., У всех есть общая тема для их обучения: «опыт». Я полагаю, что это ваше «высшее образование», и вы научитесь быстрее, чем покупать тонны книг у Амазонки и читать их (моя плохая привычка).

Так, например, возьмите шаблон GOF, такой как шаблон команды, и реализуйте его на выбранном вами языке. Понять, какие преимущества это дает вам и недостатки. Различные книги по шаблонам дизайна объяснят вам это, но я чувствую, что лучше применять эти знания на практике и учиться на них. Не стоит сбрасывать со счетов материалы для чтения, у них есть цель, но мир информационных технологий вряд ли является учебником. Тем не менее, это мое мнение и взгляд на мир информационных технологий и, отчасти, представляет собой собственную борьбу, когда я начинал свою карьеру в разработке программного обеспечения. Кроме того, основной проблемой, которую я вижу, даже с очень опытными разработчиками программного обеспечения, является нетерпение и забвение наслаждаться тем, что они делают. Поэтому не торопитесь с тем, что изучаете, и помните, что вам действительно нравится то, что вы делаете, иначе зачем тратить время на это?

Кроме того, используйте практический опыт других людей. Существует множество решений с открытым исходным кодом, как плохих, так и хороших, и вы можете поучиться у них. Посмотрите, как они применили шаблоны, и подумайте, как бы вы справились с этим по-другому.

Итак, мой общий совет: если вы чувствуете, что ваш подход неверен, измените его. Посмотрите на окружающих вас людей, которые, по вашему мнению, изучают материал, который, как вы чувствуете, вы не понимаете, посмотрите на то, что они делают, или даже спросите их.

— Пустынная планета
источник

1

Я действительно думаю, что программирование похоже на шахматную игру. Возможно, у вас есть какой-то нативный талант, вы можете играть в нее весь день, но если вы не читаете некоторые книги о шахматах, вы не сможете добиться прогресса и, что более важно, вы не сможете оценить красоту игры.

— Адриан Ифтоде

@AdrianIftode - согласился. Как уже упоминалось, я не стал бы сбрасывать со счетов книги, блоги или любые материалы для чтения, но это общая проблема, с которой я столкнулся, когда люди стремятся к мастерству в языке программирования / платформе / фреймворке и т. Д. И, похоже, они мало занимались программированием и / или практикой. усилия, но прочитал каждую книгу, в которой вы можете встряхнуть палкой.

— Пустынная планета

@AdrianIftode Ну, не совсем так. Играя в шахматы без чтения книг, вы все равно можете многое узнать об игре. Разница лишь в том, что вы не учитесь так быстро, как могли бы, опираясь на опыт и мысли некоторых шахматистов. С другой стороны, размышляя над определенными вещами, вы можете наткнуться на решение или два, которые полностью игнорируются людьми, которые учатся только у шахматистов, и которые вы могли бы использовать в своих интересах. В конце концов, я считаю, что сочетание обоих видов обучения дает наилучшую пользу. В шахматах, а также в программировании.

— cmaster - восстановить монику

1

Краткий ответ: они вам не нужны . Вы можете написать код без них. Как сказал Мэтью в комментариях, это особенно верно в JavaScript, где язык довольно гибкий, а проекты, как правило, меньше. Но если вы программируете в течение 4 лет, мне трудно поверить, что вы не сталкивались с вещами, которые кажутся повторяющимися или неловкими. Это те области, которые вы либо заново открываете, либо пропускаете шаблоны проектирования.

Пример: система событий JavaScript часто не соответствует поставленной задаче. Неужели вы никогда не хотели комбинировать или преобразовывать потоки событий? Или эта серия событий сама по себе была первоклассной ценностью? Вам нужны шаблоны Mediator и / или Observer. Нужна двухсторонняя привязка данных? Та же история.

Хрупкий прототип иерархии попал? Mixin / Trait / Subclass Фабричные шаблоны на помощь.

— Джаред Смит
источник

4

Практически невозможно написать какую-либо нетривиальную программу без использования каких-либо шаблонов проектирования, обычно вы также будете использовать множество общих шаблонов. Вам не нужно распознавать шаблоны, которые вы используете по имени. Вы можете написать рабочий код, даже если вы не можете назвать все шаблоны проектирования, которые вы используете в коде.

— Обслуживание

Шаблоны @Servy Design - это абстракции, абстракции не обязательны. Вы всегда можете выписать одноразовую реализацию основного поведения ... снова, снова и снова. Например, в примере, который я привел о событиях, можно вручную подключить все заинтересованные стороны и затем изменять их все каждый раз, когда меняются требования, это просто отстой по сравнению с использованием pub / sub. Для подклассов возможно (если расточительно) вручную кодировать каждую возможность с кучей одноразовых классов, это просто не так хорошо.

— Джаред Смит

1

Шаблоны проектирования могут стать очень широкими. Часто более широкие шаблоны проектирования настолько очевидны, что мы даже не думаем о них как о шаблонах проектирования (особенно когда они имеют специальную языковую поддержку). Цикл - это шаблон дизайна. Функции - это шаблон дизайна. Объекты - это шаблон дизайна.

— Servy

@ Служу, если ты так используешь этот термин, тогда я не согласен, но у меня сложилось впечатление, что ОП специально подразумевал паттерны GOFish.

— Джаред Смит

1

@JaredSmith Шаблоны проектирования не являются абстракциями. Даже если вы будете применять их снова и снова и снова для решения конкретной проблемы, они все равно будут шаблонами . Вам не нужно писать общий класс Observer и использовать его для использования шаблона Observer . Написание конкретных наблюдателей и конкретных методов для регистрации и уведомления их все еще использует шаблон. сложная вещь - это распознать шаблон. Иногда вы используете шаблон, даже не зная его имени,

— Polygnome

1

Найдите наставника, кого-то с очень хорошим опытом, чтобы учиться. Задайте ему вопрос, посмотрите его код, отправьте обзор кода и попытайтесь сотрудничать с ним. Это лучший способ улучшить свои навыки кодирования.

дополнительно:

Сотрудничайте с каким-нибудь простым проектом OSS, который вам нравится
Когда есть два способа решения одной и той же проблемы, всегда выбирайте более простой
Создайте дополнительный опыт работы с побочными проектами, где вы можете делать любые странные ошибки, и вы изучите шаблон проектирования «трудным путем» (tm)

— Motocarota
источник