Когда следует делать частные методы?

Есть много раз, когда я не уверен, должен ли какой-то конкретный метод быть закрытым или нет. Например, сейчас я строю класс, который отвечает за создание отчета. Этот класс имеет метод buildReport и несколько методов, которые собирают необходимые данные для buildReport.

// single public method
// uses a set of helper methods
public buildReport()

// helper methods
private avgSurveyTime()
private fetchVendors()
private fetchSendCounts()
private ...

Я обсуждаю, следует ли публиковать эти вспомогательные методы. Единственный метод, который я действительно планирую вызывать на данный момент, - buildReport(). Однако было бы полезно получить список поставщиков с fetchVendors() и т.д.

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

Есть ли хорошее правило для решения, когда методы должны быть общедоступными/частными?

Ответ 1

Единственное правило, которое я придерживаюсь, - сделать как можно меньше публичным.

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

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

Ответ 2

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

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

Ответ 3

Вы должны раскрывать внешнему миру только то, что действительно нужно внешнему миру. Часто лучше всего добавлять функциональность для пользователей класса , когда это необходимо, а не сначала. В наши дни мудрость заключается в том, чтобы избежать предварительной инженерии. (см. YAGNI)
Конечно, допустимо иметь общедоступные методы, которые также используются другими функциями внутри класса. Однако это следует рассматривать как minor плохой запах. Это может быть признаком того, что ваш класс пытается сделать слишком много вещей.

Мое предположение - оставить свои классы такими, какие они есть. Затем, когда эти другие, более мелкие методы необходимы внешнему миру, подумайте, следует ли вам отделять свои классы. Если цель каждого из этих классов дать один отчет, вы не должны выставлять эти методы из этого объекта. Вместо этого ставьте "меньшие" методы в общий вспомогательный класс. Таким образом, они доступны для внешнего мира без принципиального изменения характера ваших существующих классов отчетов. Короче говоря:

Не просто делайте это, потому что считаете, что это может быть полезно позже. Если/Когда необходимы дополнительные функции, передумайте свой общий дизайн для соответствия новым требованиям.

Ответ 4

Общественные и частные методы - это совсем другие звери. Будьте осторожны, прежде чем публиковать метод.

Публичные методы должны проверять все их параметры.
Они должны быть надлежащим образом задокументированы, включая любые исключения, которые они могут бросить.
Все краевые случаи должны анализироваться и делиться (в коде или в документации).
Любые требования, связанные с порядком, в котором вызываются публичные методы, должны быть документированы или, предпочтительно, удалены.
Требования к состоянию объекта также должны быть документированы и проверены.
Публичные методы не должны изменять свою подпись или поведение любым способом, который может разорвать приложение при переходе с одной версии на другую.
Общественные методы, возможно, должны быть разработаны с учетом требований к сортировке. (Такие как .Net CLS ограничения.)

Частные методы не имеют ни одного из этих ограничений.

Ответ 5

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

Если у вас есть сомнения - сделайте это частным.

Ответ 6

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

Мое единственное предостережение было бы, если это то, что вы "публикуете", где другие, у которых нет прямой линии для внесения изменений, будут использовать его. Затем вам нужно тщательно продумывать полный API.

Но если это не так, просто напишите код, который вам нужен. Не записывайте функции, которые, как вы думаете, когда-нибудь сможете использовать.

Ответ 7

Как правило, вы должны раскрывать как можно меньше и сделать все возможное частным.

Если вы совершаете ошибку и скрываете что-то, что вам следует подвергать, не проблема, просто сделайте ее общедоступной. Однако, если вы сделаете что-то публичное, а потом решите, что оно должно быть частным, тогда у вас могут быть проблемы, потому что теперь общедоступный метод может использоваться многими другими классами.

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

Ответ 8

Я всегда следую этому: " Дизайн для завтра, код на сегодня."

Если сегодня вам нужен только один общедоступный метод, сохраните только один общедоступный метод.

Ответ 9

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

Ответ 10

Все, что не включено в интерфейс класса, должно (должно, действительно) быть закрытым. Если вы не знаете, что такое интерфейс класса (т.е. Вы не http://www.artima.com/lejava/articles/designprinciples.html > программирование на интерфейсы или эти интерфейсы еще не полностью определены, запустите со всем частным и сделать вещи общедоступными, защищенными, приватными пакетами и т.д. по мере необходимости.

Но подумайте внимательно! Когда-то что-то доступно для другого кода, существует зависимость между этим кодом и этим классом и рефакторингом. Правило большого пальца: выставлять только те методы, которые определяют абстракцию, а не как они реализованы.

Ответ 11

простые правила:

Если вы не хотите его раскрывать вне класса, который использует это сделать ЧАСТНЫМ.
Если вы хотите разоблачить его внутри одной сборки с другой классов, но не вне сборки, сделайте его ВНУТРЕННИМ (С#) / Друг (VB.NET).
Если вы хотите разоблачить функциональность вне сборки для всех, сделайте это PUBLIC

Ответ 12

Я работаю над системой, состоящей в основном из двух вещей: импорт данных из разных источников и создание отчетов. Проблема в том, что все это было разработано кем-то, у кого нет базовых навыков проектирования OO. В том же "классе" у них были бы методы 'private' для чтения данных из базы данных, вызывающие методы 'private' для проверки указанных данных, которые также вызывается другой функцией 'private' 500-строка, дублированной более или менее в всего приложения, которое просто форматирует указанные данные.

Вам следует отойти от частного avgSurveyTime() private fetchVendors() private fetchSendCounts() из фактического класса, который обрабатывает макет страницы.