Как решить, будет ли метод закрытым, защищенным, внутренним или общедоступным? - PullRequest
5 голосов
/ 25 апреля 2009

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

Публикация их имеет следующие преимущества:

  1. Тестирование модуля без необходимости использования аксессуаров.
  2. Гибкость.

Уделение их частной собственности имеет следующие преимущества:

  1. Упрощение публичной документации.
  2. Некоторые неизвестные ошибки не обнаружены.

Каковы общие правила в этом случае?

Ответы [ 8 ]

13 голосов
/ 25 апреля 2009

Всегда делайте все как можно более приватным.

Для модульного тестирования я иногда делаю элемент внутренний , затем использую атрибут InternalsVisibleTo в AssemblyInfo.cs, чтобы разрешить сборке модульного теста доступ к внутренним элементам.

5 голосов
/ 25 апреля 2009

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

4 голосов
/ 25 апреля 2009

О, пожалуйста, прочитайте гл. 06 Of Code Complete 2 от Стива Макконнелла, если у вас есть к нему доступ. Это отлично ответит на ваш вопрос.

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

Если вам это не нужно, нет необходимости публиковать Метод.

За тестирование +1 Джону Сандерсу.

Но я действительно не могу объяснить вам здесь, как Стив объяснил в CC2.

Надеюсь, можно опубликовать ссылки на книги на Satckoverflow? (Пожалуйста, прокомментируйте.)

4 голосов
/ 25 апреля 2009

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

3 голосов
/ 25 апреля 2009

Единственные открытые члены типа должны быть частью открытого интерфейса самого типа. Ваша цель должна заключаться в том, чтобы минимизировать интерфейс типа с наименьшим числом членов и практически ничего не раскрывать в базовой реализации.

2 голосов
/ 25 апреля 2009

Если вам трудно тщательно протестировать класс, значит, класс делает слишком много. Разделение класса с помощью композиции может сделать отдельные единицы более тестируемыми.

Иногда это имеет смысл, а иногда нет. Просто мысль.

1 голос
/ 25 апреля 2009

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

Я бы проверил, есть ли у вас лучшие альтернативы. Например, вы можете создать частные средства доступа в Visual Studio 2005 и 2008, которые делают непубличный API-интерфейс класса общедоступным для целей тестирования. Это может загромождать ваш код модульного тестирования, но для меня самое главное - ваш дизайн и API, которые вы предоставляете своим клиентам, включая вас и вашу команду.

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

1 голос
/ 25 апреля 2009

Я бы НИКОГДА не обнародовал свои рядовые! Период.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...