Вложенные классы здесь не нужны, для тех, у кого есть проблемы с пониманием, следующий подход - это вложенный класс:
public class Car
{
public static Car Instance { get; private set; }
static Car() { Car.Instance = new Car(); }
private Car() { }
public static class Door
{
public static void Close()
{
/* do something with Car.Instance */
}
}
}
Использование статических классов дает следующий синтаксис:
Car.Door.Close();
C # позволяет вкладывать определения классов, которые не имеют формального понятия «внутренние типы» или «внутренние классы», как это делают другие языки.
Это отличный пример плохого моделирования / проектирования компонентов.
Рассмотрим следующее, которое является более приемлемым и более изящным решением:
public interface ICar
{
IDoor Door { get; set; }
}
public class Car : ICar
{
public IDoor Door { get; set; }
}
public interface IDoor
{
void Open();
void Close();
}
public class Door : IDoor
{
public override void Open() { /* do something */ }
public override void Close() { /* do something */ }
}
С учетом вышесказанного можно использовать синтаксис инициализатора C #:
var car = new Car
{
Door = new Door()
};
car.Door.Open();
Если ваш захватс постоянно нуждающимся в наборе "new XYZ" вы также можете запечь инициализацию в конструкторе.Правильно выполненный с шаблоном DI «бедняк», он должен выглядеть следующим образом:
public class Car : ICar
{
public IDoor Door { get; set; }
public Car()
: this(new Door())
{
}
public Car(IDoor door)
{
this.Door = door;
}
}
Это избавляет от необходимости выполнять инициализацию как часть создания и позволяет вводить новые / разные типы дверей в стек.
var common = new Car();
var lambo = new Car(new LamboDoor());
В любом случае вызывающий код выглядит одинаково:
common.Door.Open();
lambo.Door.Open();
Наконец, вы можете рассмотреть структуру Composition или DI, а не вставлять операторы new () в код своей реализации.,В любом случае, наиболее подходящий подход заключается в использовании свойств и построении законной объектной модели, которая выражает ваше намерение.Вложенные типы не дают искомого синтаксиса, если не используются статические члены, и такой подход очень редко бывает хорошей идеей, я видел его только для упрощенных одноэлементных реализаций, конечно же, никогда для определения API / Framework / Model.