Що робити, якщо я не буду використовувати шаблони дизайну програмного забезпечення? [зачинено]

З якими проблемами я можу зіткнутися, якщо не буду використовувати шаблони дизайну програмного забезпечення? Чи можете ви розповісти про проблеми підходу до проектування за допомогою стандартних об'єктно-орієнтованих прийомів?

Ви пропускаєте суть.

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

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

Тож два ключових моменти я намагаюся зробити:

1. Ви не можете НЕ використовувати шаблони проектування.
2. Не знаючи назви речей, які ви використовуєте, вам буде важко працювати в команді.

Ті, хто не може згадати минуле, засуджуються повторити його.

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

Все, що сьогодні розробляється, багато в чому базується на попередніх знаннях, не було б сенсу ігнорувати це. Уявіть, як сьогодні будувати хмарочос, не знаючи проблем, з якими стикаються люди, які будували собори кілька сотень років тому.

З якими проблемами я можу зіткнутися, якщо не буду використовувати шаблони дизайну програмного забезпечення?

У вас виникне проблема не в змозі написати жодне програмне забезпечення.

Змінні - це модель дизайну.

Методи - модель дизайну.

Оператори - додавання, віднімання тощо - це модель дизайну.

Заяви - модель дизайну.

Цінності - модель дизайну.

Посилання - це модель дизайну.

Вирази - модель дизайну.

Заняття - це модель дизайну.

...

Все, чим ви займаєтесь програмуванням, - це модель дизайну . Більшу частину часу візерунок настільки вбудований у ваше мислення, що ви перестали думати про нього як про "шаблон дизайну". Те, що вам доведеться вивчити, як "однотонний візерунок" і так далі, - це просто шаблони, які ще (ще) не були викладені будь-якою мовою, якою ви користуєтесь.

Чи можете ви розповісти про проблеми підходу до проектування за допомогою стандартних об'єктно-орієнтованих прийомів?

Ні. Я поняття не маю, що означає це питання. Шаблони дизайну - це "стандартні об'єктно-орієнтовані методики" - саме це і робить їх моделями дизайну . Шаблон дизайну - це стандартна методика вирішення певної проблеми, особливо (хоча і не обов'язково ) об'єктно-орієнтованою мовою.

Розуміння точки схеми дизайну важливіше, ніж використання його на письмі. Деякі зразки є, IMO, дурними, принаймні в мовних парадигмах, до яких я звик. IMO, програміст, який просто наочно використовує шаблони дизайну і, не розуміючи їх, насправді гірший програміст, ніж той, хто хотів би продумати речі самі. Але хтось, хто ознайомлюється з ідеями, а потім вирішує для себе, чи варто їх, швидше за все, буде набагато сильнішим програмістом, ніж будь-який.

Це сказало, що я не маю! @ # $ Ing уявлення про те, в чому полягає вага легкої ваги, і мені не соромно це визнати. (дивіться коментарі до іншої статті у Вікіпедії, яка дуже допомогла)

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

Це ідеї, а не креслення. У деяких мовах вони зовсім не дуже хороші ідеї. В інших їх справедливо сприймають як хитрощі для подолання мовних слабкостей у дизайні, які можна краще компенсувати за рахунок меншої складності. Незважаючи на це, не завадить вивчити їх і спробувати зрозуміти проблеми, які вони мають вирішити, перш ніж приймати рішення щодо власних бажаних рішень.

З якими проблемами ви зіткнетесь? Ви можете пропустити можливості і витратити більше часу на проблеми, ніж вам потрібно, якщо ви не геній програмування, який вже все це з'ясував. Важливо стежити за критикою популярних ідей програмування, але ніколи не зашкодить зрозуміти, що люди думають, що вони вирішують, оскільки це надасть більшої чіткості вашим бажаним рішенням / підходам.

Основна проблема, з якою ви зіткнетеся, полягає в тому, що ви будете винаходити колесо . Їх називають візерунками, оскільки вони з’являються часто і передбачувано.

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

Ви весь час використовуєте шаблони дизайну, не усвідомлюючи цього. Багато стандартних бібліотек популярними мовами розроблені з урахуванням дизайнерських зразків. Прикладом може бути FileReaderбібліотека Java, створена за схемою дизайну декоратора . Тепер, кажучи про власний код, ви не змушені використовувати шаблони дизайну (у більшості випадків). Шаблон дизайну - це "багаторазове рішення часто зустрічається проблеми" , це означає, що він допоможе вам написати більш чистий код для отримання більш чистих кодів, тому від вас залежить, наскільки ви хочете уникнути закінчення коду спагетті.