Как решить, будет ли метод закрыт, защищен, внутренним или общедоступен?
Решение 1: Вы можете добавить оба оператора обновления в процедуре / функции PLSQL и выполнить то же самое в коде Java
Решение 2: Вы можете добавить оба оператора обновления в функцию и вызывать одно и то же
8 ответов
О, пожалуйста, прочитайте гл. 06 Of Code Complete 2 от Стива Макконнелла, если у вас есть к нему доступ. Это отлично ответит на ваш вопрос.
В общем, если Метод вписывается в общую «Персону» класса, сделайте его публичным. С технической точки зрения, постарайтесь не нарушать абстракцию. Я бы привел пример, но я не знаю контекста вашей работы, и поэтому примеры могут быть неактуальными.
Если вам это не нужно, нет необходимости публиковать Метод.
За тестирование +1 Джону Сандерсу.
Но я действительно не могу объяснить вам здесь, как Стив объяснил в CC2.
Надеюсь, можно опубликовать ссылки на Книги на Satckoverflow? (Пожалуйста, прокомментируйте.)
Всегда делайте все как можно более приватным.
Для модульного тестирования я иногда делаю элемент внутренним , а затем использую атрибут InternalsVisibleTo в AssemblyInfo.cs, чтобы разрешить сборке модульного теста доступ к внутренним элементам.
В этом случае я обычно делаю их как можно более закрытыми, а затем продвигаю их доступность, когда возникает необходимость (например, код из других классов выиграл бы от возможности доступа к этим методам). напрямую). Добавить методы в API легко, а удалить их гораздо сложнее (не нарушая другой код).
Я большой поклонник обнародования только того, что вы явно хотите обнародовать. Мне нравится теплый безопасный кокон, который мне предлагает мой класс.
The only public members of a type should be a part of the public interface of the type itself. Your goal should be to minimize the interface of the type to the fewest number of members and expose little to none of the underlying implementation.
Если вам сложно тщательно протестировать класс, то класс может делать слишком много Разделение класса с помощью композиции может сделать отдельные единицы более тестируемыми. 12108 Иногда это имеет смысл, а иногда нет. Просто мысль.
Раскройте только то, что нужно для ваших предполагаемых клиентов и сценариев использования, и ничего более. Я бы не стал рассматривать модульное тестирование в качестве клиента и вносить изменения, чтобы код, не предназначенный для публичного использования с самого начала, был общедоступным только для модульного тестирования. Если вы это сделаете, вы будете загромождать свой API, уменьшать удобство использования вашего API и делать будущие изменения более сложными и не идеальными, поскольку теперь может существовать клиентский код, который использует то, что должно быть закрытым API. 1295 Я бы проверил, есть ли у вас лучшие альтернативы. Например, вы можете создать частные средства доступа в Visual Studio 2005 и 2008, которые делают непубличный API-интерфейс класса общедоступным для целей тестирования. Это может загромождать ваш код модульного теста, но для меня самое главное - ваш дизайн и API, которые вы переиздание для ваших клиентов, включая вас и вашу команду.
В другой заметке я бы также упомянул, что модульное тестирование дает вам прекрасную возможность увидеть, насколько хорош ваш дизайн и насколько легко использовать ваш API с точки зрения клиента. Вооружившись разочарованием, проблемами и т. Д. Во время разработки модульных тестов, вы вносите изменения, улучшающие ваш API и дизайн, чтобы сделать его более простым, красивым и удобным.