Вложенные классы не нужны здесь, для тех, кто имея трудности с пониманием, следующий вложенный класс подход:
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 */ }
}
С выше, может использовать С # инициализатора синтаксис:
var car = new Car
{
Door = new Door()
};
car.Door.Open();
Если схватывание это с постоянно нуждаясь набирать «новый 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();
Наконец, вы могли бы рассмотреть композицию или структуру DI, а не выпекать новые() операторов в код реализации. В любом случае наиболее подходящий подход заключается в использовании свойств и построении законной объектной модели, которая выражает ваши намерения. Вложенные типы не дают синтаксиса, который вы ищете, если не используются статические члены, и принятие такого подхода очень редко является хорошей идеей, я видел это только для упрощенных реализаций singleton, конечно же, никогда не для определения API/Framework/Model.
Спасибо за ваш ответ! Я просто подумал, что не должен использовать вложенные классы, потому что в этом [ответе] (http: // stackoverflow.com/a/8849079/1147455) сказано: _2) НЕ использовать общедоступные вложенные типы в качестве логической группы construct_ Но, учитывая снова вложенные классы: я должен использовать частные вложенные классы и создавать публичный объект каждый, что содержит функции? – DIF
@user: Да, [Руководство по дизайну рамок] (http://msdn.microsoft.com/en-us/library/ms229027.aspx) сообщают вам, что то, что вы пытаетесь сделать, - это, как правило, плохая идея. Они правы. Но если вы хотите сделать это в любом случае (и это всего лишь рекомендации, они не являются правилом), тогда вы это делаете. Если имеет смысл, что классы являются частными (т. Е. Что внешний код не должен создавать объекты такого типа), тогда сделайте их приватными, да. –
Еще раз спасибо! Если подобные функции группировки считаются плохой идеей - как бы выглядел рекомендованный способ организации более или менее разных функций? – DIF