Рефакторинг с выделением класса
От: Аноним  
Дата: 28.11.10 18:44
Оценка:
Вечер добрый!

Я сейчас читаю книгу Роберта Мартина "Чистый код" и не могу для себя решить задачу.
Роберт Мартин на протяжении всей книги говорит о рефакторинге, в том числе о рефакторинге через выделение класса.
В свои разработках я использую IoC контейнер Windsor и все классы у меня создаются через него.
Собственно вопрос заключается в том, что должен ли я создавать классы, получившиеся в результате рефакторинга, на месте (в методах), или же из них делать обычные зависимости и передавать в конструкторе, как я делаю со всеми зависимостями?

С одной стороны выносить в зависимости удобно, т.к. можно очень легко протестировать класс, но боюсь, что тогда у меня будет слишком много зависимостей. Или же, если много зависимостей, то стоит ещё бить класс, добиваясь следования SRP? Но с другой стороны есть там ещё какой-то принцип, что не следует слишком много вводить классов.

А если всё-таки бить на классы, то нужно ли выделять интерфейсы? Или начать выделять только когда он реально понадобится?

В общем, чем больше узнаю, тем больше вопросов.

Всем спасибо за ответы!
Re: Рефакторинг с выделением класса
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.11.10 00:08
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Я сейчас читаю книгу Роберта Мартина "Чистый код" и не могу для себя решить задачу.


Я тоже её читаю

А>Роберт Мартин на протяжении всей книги говорит о рефакторинге, в том числе о рефакторинге через выделение класса.

А>В свои разработках я использую IoC контейнер Windsor и все классы у меня создаются через него.

Классы создаются руками, а IoC создает тебе экземпляры

А>Собственно вопрос заключается в том, что должен ли я создавать классы, получившиеся в результате рефакторинга, на месте (в методах), или же из них делать обычные зависимости и передавать в конструкторе, как я делаю со всеми зависимостями?


Вроятно речь об экземплярах классов, получившихсяв резултате рфакторинга.

Зависимости у тебя есть и без IoC. Функциональные зависимость никуда не деваются. IoC это только способ управлять этой зависимостью. Вот если расчленять классы на ответственности, тогда у конкретного класса зависимостей становится меньше, зато классов больше, а вот зависимостей у модуля сколько было, столько и осталось.

Ну IoC берет на себя зависимости от кода инициализации например — это нефункциональная зависимость.

А>С одной стороны выносить в зависимости удобно, т.к. можно очень легко протестировать класс, но боюсь, что тогда у меня будет слишком много зависимостей.


Зависимости у тебя и так есть. Но может получиться слишком гибкая система. Т.е. нужно искать баланс.
Кроме того, если добиваться что бы каждый класс был тестируемым, придется раскрыть слишком много деталей.
Тестировать же не всегда обязательно класс в изолированом виде. Можно тестировать ключевые точки через которые распространяются изменения. Более подробно об этом в книге Физерса "Legacy Code"

>Или же, если много зависимостей, то стоит ещё бить класс, добиваясь следования SRP? Но с другой стороны есть там ещё какой-то принцип, что не следует слишком много вводить классов.


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

А>А если всё-таки бить на классы, то нужно ли выделять интерфейсы? Или начать выделять только когда он реально понадобится?


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