Неможливо зрозуміти шаблони дизайну програмування

16

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

Щоразу, коли мені потрібно щось починати самостійно, я шукаю ці два шляхи: якщо я використовую велику бібліотеку / рамку, як React.js, я схильний копіювати те, що робить громада; Якщо я перебуваю на чомусь меншому, я буду використовувати модульний шаблон. Я знаю, що як тільки я краще зрозумію цю тему, я зможу приймати кращі рішення, але поки я повністю втрачена.

Чи варто шукати на цьому вищу освіту? Чи потрібен мені наставник з цього питання? Я просто дурний? Невже це важко зрозуміти?

design-patterns javascript

— Абенсур
джерело

6

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

— Метью

3

Розмір проекту також відіграє значну роль.

— Матвій

2

@Matthew nitpick Мені не обов'язково називати Java / C # сильно набраним ...

— Jared Smith

2

@JaredSmith правда, я часто забуваю про відмінність між сильно набраним і статично набраним.

— Метью

6

Якщо ви намагаєтеся undertsand моделей в загальному , стоп! Там нічого немає! Візерунок є популярним рішенням поширеної проблеми, і хтось дав йому назву. Це все, що там є. Можливо, вам буде важко зрозуміти якусь конкретну закономірність - я сам боюся з пригадуванням того, як ефективно використовувати шаблон "відвідувача", щоб імітувати подвійну диспетчеризацію на Java - Але якщо ви шукаєте секретний соус, який посилає на "відвідувача" до, скажімо, "об'єкта передачі даних", ви його не знайдете. Вони просто два популярних рішення двох поширених проблем, хтось дав їм імена, а імена застрягли.

— Соломон повільно

34

Шаблони розробки програмного забезпечення - це добре відомі рішення відомих проблем. Те, як ви їх розумієте, - вивчаючи шаблони, розуміючи, як вони працюють, і знаючи, коли доцільно застосувати кожен до вашої розробки програмного забезпечення.

Те, як ви вивчаєте шаблони розробки програмного забезпечення, - вивчаючи їх по одному. Це безперервний навчальний процес. Якщо ви хочете зменшити слід навчання, вивчіть ті зразки, які безпосередньо стосуються технологій, якими ви зараз користуєтесь.

Деякі важливі речі, які потрібно знати про моделі дизайну:

Деякі зразки дизайну мають архітектурний характер. MVC та MVVM - приклади таких моделей. Ви використовуєте такі зразки, коли потрібні організаційні та структурні переваги, які вони надають.
Деякі зразки дизайну є вирішенням недоліків у мовах програмування. Ці схеми вам не знадобляться, якщо ви використовуєте більш виразну мову програмування, але часто вам не вдасться зробити цей вибір. Більшість моделей Міністерства фінансів належать до цієї категорії .
Використовуйте програмний зразок лише тоді, коли ви намагаєтеся вирішити проблему, яку спеціально розроблено для вирішення. Якщо ви пишете заявку, зшиваючи зразки програмного забезпечення, ви робите це неправильно.
Існує не програмний зразок для кожної існуючої комп'ютерної проблеми. Якби це було так, програмування буде просто вправою узгодження зразком.
Деякі зразки насправді є анти-зразками. Додаткова складність, яку ці схеми впроваджують, переважує переваги, які вони надають. Вам доведеться самостійно вирішувати, який із цих шаблонів уникнути.

— Роберт Харві
джерело

Хороша відповідь, хоча я не погоджуюся з твердженням, що більшість моделей 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 часто неадекватна заданим завданням. Ви ніколи не відчуваєте, що хочете вміти поєднувати чи трансформувати потоки подій? Або ці серії подій самі по собі були цінностями першокласного? Вам потрібні шаблони посередника та / або спостерігача. Потрібно двостороння прив'язка даних? Та сама історія.

Крихка ієрархія прототипу зникла? На допомогу фабричні моделі Mixin / Trait / Subclass

— Джаред Сміт
джерело

4

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

— Сервіс

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

— Джаред Сміт

1

Моделі дизайну можуть отримати дуже широкі. Часто більш широкі шаблони дизайну настільки очевидні, що ми навіть не вважаємо їх шаблонами дизайну (особливо, коли вони мають спеціальну мовну підтримку). Петля - це шаблон дизайну. Функції - це модель дизайну. Об'єкти - модель дизайну.

— Сервіс

@ Сервіз, якщо так ви використовуєте цей термін, то я не погоджуюся, але у мене склалося враження, що ОП спеціально означало шаблони GOFish.

— Джаред Сміт

1

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

— Полігном

1

Знайдіть наставника, когось із дуже добрим досвідом, з якого слід вчитися. Попросіть його запитати дивитися його код, надіслати деякий огляд коду та спробувати співпрацювати з ним. Це найкращий спосіб активізувати свої навички кодування.

додатково:

Співпрацюйте з простим проектом OSS, який вам подобається
Коли є два способи вирішення однієї проблеми, завжди вибирайте простіший
Створіть додатковий досвід з побічними проектами, де ви можете робити всі дивні помилки, і ви навчитеся схемі дизайну "важким шляхом" (тм)

— Мотокарота
джерело