Частный вложенный статический класс — хорошая или плохая практика?

#c# #.net #oop #static #nested-class

#c# #.net #ооп #статический #вложенный класс

Вопрос:

Будет ли считаться плохой практикой вложение частного статического класса внутрь нестатического класса?

 public class Outer
{
    private static class Inner
    {


    }
}
  

Идея здесь в том, что все экземпляры ‘Outer’ будут совместно использовать доступ к статическому состоянию. Другим способом сделать это может быть просто позволить внутреннему классу быть нестатическим и использовать его статический экземпляр:

 public class Outer
{
    private static innerInstance = new Inner(); 

    private class Inner
    {


    }
}
  

Аналогичный эффект. Каковы плюсы / минусы или другие соображения при таком подходе?

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

Комментарии:

1. статические классы более эффективны, если вам не нужно обращаться к членам внешнего класса. Таким образом Node в Linkedlist.java является статическим. Посмотрите на эффективную java

Ответ №1:

Оба подхода полностью допустимы.

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

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

Ответ №2:

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

Ответ №3:

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

Ответ №4:

Представьте , что вам нужно создать класс , по сложности сравнимый с небольшим приложением … с классами, которые полностью являются внутренними по отношению к вашему сложному внешнему классу

Нет, не воображайте этого.

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

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

Используйте отдельные классы, каждый из которых, в идеале, несет единственную ответственность.

Это способ уменьшить сложность.

Ответ №5:

В этом вообще нет ничего плохого, да и почему должно быть?

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

Я не вижу в этом ничего, кроме хорошей практики.

Ответ №6:

Это зависит от того, что делает Inner класс. Если это просто служебный класс, статический внутренний класс — это правильный путь.

 public class Calculator
{
    private static class HexToDecUtils
    {
        // converter code here
    }
}
  

Другими словами, если Inner класс является составным с другим объектом, он не должен быть статическим классом.

 public class Car
{
    private class Engine
    {
        // your code here
    }
}