Является ли многократное использование синонимом хорошего дизайна?

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

Является ли многократное использование приемлемым блеском («краткое обозначение значения») для хорошего проектирования программного обеспечения? Почему?

Нет.

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

Возможность повторного использования в значительной степени иллюзия. Достоверно невозможно измерить «повторное использование» единицы, не зная заранее, где и как она будет использоваться. Многие разработчики попытаются спроектировать «повторно используемые» компоненты и позже узнают, что конкретные аспекты, которые они пытались сделать «гибкими», - это именно те, которые не должны были быть.

Я бы использовал другой «глянец»: тестируемость.

Сейчас я не сторонник TDD, и при этом я не чувствую необходимости проводить модульное тестирование всего и вся. Но написание тестов для компонента даст вам очень хорошее представление о его характеристиках сцепления / сцепления и очень быстро. Если это зависит от абстракций, то это слабая связь; вам будет легко смоделировать зависимости, и это предполагает хороший дизайн. Если у него есть четкая цель (см. Также принцип единой ответственности ), то его поведение будет относительно интуитивно понятным, вам будет легко выяснить, что тестировать, что опять-таки предполагает хороший дизайн.

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

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

Нет.

Возможность многократного использования - хорошая возможность иметь, потому что это может ускорить будущее развитие. (Хотя на практике очень немногие организации видят, что будущее развитие ускорится почти так же, как они надеялись, что это произойдет.) Однако в любом значительном фрагменте программного обеспечения есть компоненты, специфичные для этого приложения. Более того, когда люди, не имеющие опыта работы с предметной областью, пытаются написать программное обеспечение многократного использования, они обычно запутывают эту часть и снижают производительность, фактически не делая ее повторно используемой.

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

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

Хороший программный дизайн должен быть многократно используемым, по крайней мере, в некоторых основных частях, я думаю, что очень немногие люди фактически повторно используют исходный код, потому что чрезвычайно сложно спроектировать ядро ​​системы, которое можно использовать повторно во многих различных контекстах (И я говорю это из опыта)

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

Надеюсь, я не слишком испортил свои объяснения

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

Придерживаясь этих фундаментальных принципов проектирования, код становится проще для тестирования и повторного использования.

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

Повторное использование часто является неявной целью проектирования. Если вы можете создать компонент или весь дизайн таким образом, чтобы его можно было использовать позже, то , очевидно, вам следует это сделать. Что не всегда очевидно, так это то, что может потребоваться много времени и усилий (и денег), чтобы сделать что-то многоразовое, и поэтому преимущество повторного использования должно быть сопоставлено с его стоимостью.

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

Существует ряд подобных атрибутов, которые часто считаются неявными целями проектирования, потому что они кажутся явно хорошими:

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

• минимизировать время разработки

• минимизация сложности

• максимальная надежность

Все эти вещи объективно хороши, но не всегда могут быть важны для конкретного клиента в определенное время, поэтому важно полностью понять, что нужно вашему клиенту (даже если этот клиент - просто ваш начальник). Существует ряд афоризмов, которые должны напоминать нам об этом факте (например, «Готово лучше, чем идеально» и «Хорошо, дешево, быстро: выберите любые два»), но все равно легко попасть в ловушку попытки создавать программы, которые хороши во всех отношениях, хотя на самом деле они хороши не всегда.

Чтобы перейти к заглавному вопросу, то: Нет , повторное использование не является синонимом хорошего дизайна. Повторное использование может быть полезным компонентом определенного хорошего дизайна, но только тогда, когда это требуется.

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

Например, если вы пишете файл, полный данных, который является уникальным для вашей компании, и эти данные необходимо один раз импортировать в другое место, зачем беспокоиться о том, чтобы сделать его многоразовым?

Тем не менее, если у вашего фреймворка его еще нет, код для записи в файл может потребоваться многократное использование. Это было бы хорошим дизайном.

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

Основной материал

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

Сервисные вещи

• Класс электронной почты, отправляющий SMTP-сообщение (используйте его постоянно)
• Класс калькулятора ГИС (используется в ряде наших приложений)

Что касается элементов CRUD, которые занимают 70-80% большинства приложений, я просто не думаю, что повторное использование вообще является ценным показателем.