Лучшая практика: защищенные или частные методы по умолчанию и разработка через тестирование

Question

Похожие вопросы

• Когда вы пишете закрытый метод, а не защищенный?
• Лучше всего использовать закрытые методы или защищенные методы?
• Причины использовать закрытый вместо защищенных для полей и методов

Мой вопрос

Многие люди согласны с тем, что защищенные методы должны бытьиспользуется только тогда, когда у вас есть основания использовать их.Как модель разработки, основанная на тестировании, может помочь в этом?(Особенно в отношении поддельных объектов.) У меня есть друг, который большой поклонник TDD, а теперь и BDD, и разработчик на C #, и он сказал мне, что вряд ли когда-либо использует ключевое слово private.После того, как он сказал это, я продолжал использовать его для полей, но начал использовать все мои методы по умолчанию protected.Некоторые пользователи StackOverflow также согласны с тем, что по умолчанию следует использовать protected. Может, кто-нибудь из вас задумается над этим вопросом?Какова лучшая причина для использования protected по умолчанию (поскольку в приведенных выше потоках объясняются причины этого не делать)?

Редактировать : согласно комментарию Одеда, как насчет использования protected по умолчанию ипринцип Open-Closed (класс должен быть открыт для расширения и закрыт для модификации)?

Answer 1

Вот что я считаю лучшей практикой, делайте с моими разработками и предлагайте всем своим клиентам:

1. Начните с вашего теста (или спецификации, если вы в BDD).Производственные классы и методы, которые вы извлекаете из своих тестов, должны быть public .
   • Примечание. Если вы разрабатываете в .NET, вы можете использовать ключевое слово internal (и добавить атрибут сборки InternalsVisibleTo в свою производственную сборку,так что ваш тестовый проект может использовать код) вместо этого.Тогда вы сделаете его общедоступным , только если от него зависит другая производственная сборка .
2. Любой метод, созданный вами как часть рефакторинг фаза вашего TDD должна быть сделана приватной .
3. Делайте вспомогательные методы protected только тогда, когда они нужны производному производственному классу.
4. Любой метод, созданный на этапе рефакторинга (теперь частный или защищенный), который вам нужен в другой производственный класс должен быть извлечен во вспомогательный класс и сделан общедоступным (или внутренним в .NET, а также на любом языке, поддерживающем эту концепцию).
5. Если необходим вспомогательный класс в другой сборке , то:
   • Если другая сборка уже зависит от сборки вспомогательного класса, сделайтевспомогательный класс public (если это еще не сделано).
   • Если другая сборка не зависит от сборки вспомогательного класса, извлеките вспомогательный класс в вспомогательная сборка (лучше всего подходит или новая) и сделать ее общедоступной .Обязательно укажите в исходной сборке новую вспомогательную сборку, если это еще не сделано.

Это должно в значительной степени охватить все ваши дела.
Надеюсь, что этопомогает.