Блог

У меня есть вопрос ООП о том, как потенциально разделить большой класс на классы меньшего размера.

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

• MyBusinessObjectGroupOne
• MyBusinessObjectGroupTwo
• MyBusinessObjectGroupThree

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

 public class MyBusinessObject{

    private object memberOne;
    private object memberTwo;
    private object memberThree;

    //METHOD GROUP ONE
    public MyBusinessObject Method1(){ }
    public MyBusinessObject Method2(){ }
    public MyBusinessObject Method3(){ }
    public MyBusinessObject Method4(){ }

    //METHOD GROUP TWO
    public MyBusinessObject Method5(){ }
    public MyBusinessObject Method6(){ }
    public MyBusinessObject Method7(){ }
    public MyBusinessObject Method8(){ }

    //METHOD GROUP THREE
    public MyBusinessObject Method9(){ }
    public MyBusinessObject Method10(){ }
    public MyBusinessObject Method11(){ }
    public MyBusinessObject Method12(){ }

    //METHOD GROUP FOUR
    private void Method13(){ }
    private void Method14(){ }
    private void Method15(){ }
    private void Method16(){ }
}
  

Есть три аспекта этого класса, которые вызывают у меня трудности с выяснением, можно ли разделить этот класс:

1. Вышеупомянутая цепочка методов
2. Хотя методы в каждой общедоступной группе не вызывают методы в других общедоступных группах, методы в закрытой группе могут быть вызваны любым общедоступным методом в любой группе.
3. Аналогично, доступ к членам класса и их изменение осуществляются методами во всех четырех группах.

Поэтому я не уверен, возможно ли разделить этот класс на отдельные классы по некоторым или всем этим причинам.

Я рассмотрел возможность переноса методов из частной группы в новый класс (например, MyUtils ); а также перемещения членов класса в другой новый класс (например, MyData ), экземпляр которого можно было бы передать MyUtils через ref .

Таким образом, я мог бы переместить каждую из групп методов в их собственный класс, передать в MyData by ref , и каждый из них тоже мог бы использовать MyUtils .

Является ли это правильным подходом для пунктов 2 и 3 выше? Я не уверен в последствиях для цепочки методов переноса этих методов в новые классы.

РЕДАКТИРОВАТЬ Это ответ на соответствующий комментарий ниже. Я изучаю это, чтобы просто уменьшить размер класса. Я не стремлюсь добавить какую-либо дополнительную архитектурную гибкость или функциональность путем разделения класса. Это в основном для структуры и организации кода. Я также знаю, что код в большом классе с методами в разных отдельных логических группах может нарушать принцип единой ответственности.

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

 public class MyBusinessObject {

    // You might need to move these to one of the derived classes .......
    private object memberOne;
    private object memberTwo;
    private object memberThree;

    //METHOD GROUP FOUR
    protected void Method13(){ }
    protected void Method14(){ }
    protected void Method15(){ }
    protected void Method16(){ }
}

public class Group1 : MyBusinessObject 
{
    //METHOD GROUP ONE
    public Group1 Method1(){ }
    public Group1 Method2(){ }
    public Group1 Method3(){ }
    public Group1 Method4(){ }
}

public class Group2 : MyBusinessObject 
{
    //METHOD GROUP TWO
    public Group2 Method5(){ }
    public Group2 Method6(){ }
    public Group2 Method7(){ }
    public Group2 Method8(){ }
}

public class Group3 : MyBusinessObject 
{
    //METHOD GROUP THREE
    public Group3 Method9(){ }
    public Group3 Method10(){ }
    public Group3 Method11(){ }
    public Group3 Method12(){ }
}
  

Редактировать:

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

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

Попробуйте сделать это с помощью расширений (псевдокод)

 static class ExtensionGroup1
{
    public static MyBusinessObject Method1_1(){ this MyBusinessObject onj, ... }
    public static  MyBusinessObject Method1_2(){  this MyBusinessObject onj, ...  }
    public static MyBusinessObject Method1_3(){  this MyBusinessObject onj, ...  }
    public static MyBusinessObject Method1_4(){  this MyBusinessObject onj, ...  }
}


static class ExtensionGroup2
{
    public static MyBusinessObject Method2_1(){ this MyBusinessObject onj, ... }
    . . . .  .. 
}

  

Затем в вашем основном классе вы можете сделать…

 
class Context
{
     int Var1 {get;set}
     int Var2 {get;set}
}

private int _var1;
private bool _var2; 

void SomeMethod(MyBusinessObject someObject)
{
    var ctx = new Context(){ Var1 = _var1, Var2 = _var2 }

    this.Method1_1(ctx).Method2_1(ctx)...

}
  

Обратите внимание на это — вы сможете смешивать методы для одной и той же или разных групп. И, особенно обратите внимание, что вашим расширениям необходимо будет использовать ваш текущий основной класс в качестве класса контекста, следовательно Method1_1(this)