Чи багаторазове використання є синонімом хорошого дизайну?

Багаторазовість - особливість гарного дизайну програмного забезпечення .

Чи є повторне використання прийнятним блиском ("коротке позначення сенсу") для хорошої розробки програмного забезпечення? Чому?

Ні.

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

Повторність використання багато в чому ілюзія. Визначити "повторність використання" підрозділу неможливо, не знаючи заздалегідь, де або як він буде використовуватися. Багато розробників спробують розробити «багаторазові» компоненти і часто пізніше з’ясовують, що конкретні аспекти, які вони намагалися зробити «гнучкими», є саме тими, які не потребували.

Я б використовував інший "блиск": Заповітність.

Зараз я не є прихильником TDD, і не відчуваю потреби в тестуванні всього і всього. Але написання тестів для компонента дасть вам дуже гарне уявлення про його сполучні / згуртовані характеристики та дуже швидко. Якщо це залежить від абстракцій, то це нещільне з’єднання; вам буде легко знущатися над залежностями, і це говорить про хороший дизайн. Якщо вона має чітку мету (див. Також Принцип єдиної відповідальності ), то її поведінка буде відносно інтуїтивно зрозумілою, ви зможете легко зрозуміти, що протестувати, що, знову ж таки, пропонує хороший дизайн.

Це, звичайно, не гарантує хорошого дизайну; фактична реалізація або навіть вся архітектура може бути цілком невідповідним її заявленому призначенню. Але принаймні це говорить вам про те, що ви не працюєте зі кодом спагетті чи об'єктами Бога.

Будь ласка, не намагайтеся робити гадані здогади щодо "повторного використання" компонента, особливо не використовуйте як доказ "гарного дизайну". Це те, що ви можете встановити лише заднім числом, як тільки воно фактично повторно використовується, і до того часу дизайн може істотно змінитися.

Ні.

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

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

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

Хороший дизайн програмного забезпечення повинен бути багаторазовим, принаймні в деяких основних частинах, я думаю, що дуже мало людей фактично повторно використовує вихідний код, через те, що створити ядро ​​системи для багаторазового використання в різних контекстах надзвичайно складно. (І це я кажу з досвіду)

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

Сподіваюся, я не надто сильно псував свої пояснення

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

Дотримуючись цих основних принципів дизайну, код полегшується для тестування та легше використовувати.

Хороший дизайн == хороший дизайн, повторне використання - побічний продукт.

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

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

Існує ряд подібних атрибутів, які часто вважаються неявними дизайнерськими цілями, оскільки вони здаються очевидно хорошими:

• мінімізація витрат

• мінімізація часу розробки

• мінімізація складності

• максимізація надійності

Ці речі об'єктивно хороші, але не завжди можуть бути важливими для конкретного клієнта в конкретний час, тому важливо повністю зрозуміти, що потрібно вашому клієнту (навіть якщо цей клієнт - лише ваш начальник). Існує ряд афоризмів, які мають нагадувати нам про цей факт (наприклад, "Готово краще, ніж досконало" та "Добре, дешево, швидко: вибрати будь-яку двоє"), але все одно легко потрапити в пастку спроб зробити програмне забезпечення, яке чудово в будь-якому відношенні, коли насправді чудове в будь-якому відношенні не завжди потрібно.

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

Не обов'язково. Якщо ви зробите щось для багаторазового використання, яке явно ніколи не буде повторно використане, то це поганий дизайн.

Наприклад, якщо ви пишете файл, повний даних, унікальних для вашої компанії, і ці дані потрібно імпортувати один раз кудись інше, навіщо турбуватись про те, щоб зробити його багаторазовим?

Однак, якщо у вашій базі ще немає такої програми, код для запису у файл, можливо, потребує повторного використання. Це був би гарний дизайн.

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

Основні речі

• Шаблони веб-форм, які дозволяють легко та послідовно додавати сторінку (або для будь-якого інтерфейсу користувача)
• Створіть помічників шаблонів, як базовий клас ViewModel, який буде включений у всі мої програми MVVM

Корисні речі

• Клас електронної пошти, який надсилає SMTP-повідомлення (використовуйте його постійно)
• Клас калькулятора відстані GIS (використовується у ряді наших додатків)

Що стосується матеріалів CRUD, які займають 70-80% більшості додатків, я просто не думаю, що повторне використання є цінною метрикою.