Проблемы с модификатором класса в C # с частными классами

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

Для классов типа «Помощник», которые не будут использоваться вне текущей сборки, Internal - это путь, который будет использоваться, если методы будут использоваться несколькими классами.

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

Я могу определить MyClass как частичный класс, имеющий один файл для MyClass, другой для MyClassConditions и другой для MyClassProcessExecution.

Возможно, это мой опыт работы с C ++, но это мой стандартный подход, хотя я объединяю небольшие вспомогательные классы в один файл.

Таким образом, в одном из моих текущих проектов класс Product разделен между Product.cs и ProductPrivate.cs.

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

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

class LargeClass
{
public void DoProcess()
{
  if (DoProcess1())
  {
    if (DoProcess2())
    {
      DoProcess3();
    }
  }
}

protected bool DoProcess1()
{
...
}

protected bool DoProcess2()
{
...
}

protected bool DoProcess3()
{
...
}

}

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

public class AbstractStep
{
    public AbstractStep NextStep { get; set; }

    public virtual bool ExecuteStep
    {
       if (NextStep != null)
       {
         return NextStep.ExecuteStep();
       }
    }  
}

public class ConcreteStep1 : AbstractStep
{
    public bool ExecuteStep
    {
       // execute DoProcess1 stuff
       // call base
       return base.ExecuteStep();
    }
}

...

public class ConcreteStep3 : AbstractStep
{
     public bool ExecuteStep
     { 
        // Execute DoProcess3 stuff
        // call base
        return true; // or false?
      }
}

Чтобы настроить это, вы должны в некоторой части кода сделать следующее:

var stepOne = new ConcreteStep1();
var stepTwo = new ConcreteStep2();
var stepThree = new ConcreteStep3();
stepOne.NextStep = stepTwo;
stepTwo.NextStep = stepThree;

bool success = stepOne.ExecuteStep();

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

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

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