Как Вы предотвращаете классы, становящиеся 'магнитами зависимости' и классами Бога? [закрытый]
У меня была та же проблема, но мне удалось ее исправить :
Я сделал это на Xcode 8, используя Swift 3.
5 ответов
Постоянный рефакторинг поможет предотвратить это.
Кроме того, это то место, где принудительный статический анализ кода может быть очень полезным. Вы часто можете найти эти классы и очень легко пометить их для автоматического рефакторинга, посмотрев на метрики кода.
Мое самое большое предложение, тем не менее, состоит в том, чтобы сохранить отношение, что дизайн должен измениться, а вещи должны быть разбиты на части. По моему опыту, часто эти классы формируются из-за того, что люди не хотят рассматривать возможность изменения неработающего или неоптимального дизайна. Сохранение гибкости помогает предотвратить это.
Я думаю, что многое из этого имеет тенденцию происходить из-за последующей лени при проектировании. Философия «агрессивного рефакторинга» - очень хорошее противоядие от такого рода проблем проектирования. Проблема в том, что, хотя первоначальный дизайн классов «магнит зависимости» хорош, последующие инженеры, испытывающие нехватку времени, склонны просто присоединять другие функции к этому классу по той простой причине, что они доступны там, где они им нужны (обычно).
В основном проблема связана с тем, что дизайн, который может удовлетворить потребности зрелого программного продукта, является чрезмерным для менее зрелого программного продукта. Вся конструкция, которая в конечном итоге находится в зрелой итерации программного продукта, является огромным излишеством для более ранней итерации этого продукта; в корне, поэтому дизайн всегда нужно дорабатывать по мере продолжения разработки. И здесь необходим рефакторинг; как только новые функции и функции начнут реализовываться, проблемы дизайна покажут себя; при этом критически важно взять на себя задачу по изменению способа взаимодействия классов и рефакторингу кода, чтобы воспользоваться этим. Только так вы сможете поддерживать зрелость дизайна, которая будет в любом виде сходна со зрелостью проекта.
Фактически, есть уровень зрелости дизайна, который увеличивается вместе со сложностью проекта; массово сложный дизайн для простого проекта неуместен; точно так же, как неуместна чрезвычайно простая конструкция для сложного проекта. Но поскольку это несоответствие существует, дизайн должен развиваться вместе с проектом.
Этот:
- Многие другие классы, унаследованные от этот класс
можно преодолеть, предпочтя композицию наследованию .
По моему опыту, первый дизайн, который вы придумываете, обычно бывает неправильным, и со временем вам нужно его переосмыслить. Когда класс начинает становиться слишком большим, это обычно происходит из-за того, что он начинает нарушать SRP .
Некоторые из шаблонов рефакторинга Фаулера полезны. Рефакторинг класса Extract может помочь, так же как и Extract Subclass и Extract Superclass . Я часто меняю иерархию наследования, возможно, используя , заменяя наследование делегированием .
Безжалостный рефакторинг и для меня, особенно для небольших (т.е. не очень продуманных, водопадных) проектов, которые длятся долгое время (например, годы).
Я начинаю с малого: немного архитектура, скажем, от 2 до 5 компонентов. Я реализую функциональность, добавляя код к этим компонентам ... и когда компонент становится слишком большим (что субъективно), я делю его более чем на один компонент. [Под «компонентом» я подразумеваю «пакет» или «DLL» или что-то в этом роде.]
«Магниты зависимостей» - это немного другая проблема: для решения этой проблемы я увлекаюсь многоуровневым программным обеспечением без циклических зависимостей между уровнями и иногда с фасадом, который изолирует верхний уровень от компонентов нижнего уровня.