Свойство должно иметь то же имя как свой тип?
Сервис не должен иметь GUI, так как он должен работать без любой необходимости в любом вмешательстве от пользователя, и существуют все виды проблем, связанных с нахождением и связью с корректным пользовательским рабочим столом.
С тех пор, по-видимому, причина выяснения это должно быть в состоянии удаленно контролировать приложение, способ сделать это состоял бы в том, чтобы иметь два приложения. Сервисная сторона (записанный в основном как консольное приложение) и сторона GUI клиента/контроля. Сервис использовал бы некоторую удаленную возможность соединения (когда я сделал это, я использовал Именованные каналы) связываться с клиентом/приложением мониторинга. Любой должен быть в состоянии работать без другого, и конечно услуга должна быть в состоянии работать с клиентом.
8 ответов
Ничего страшного. Канонический пример здесь:
public Background {
public Color Color { get; set; }
}
Здесь возникают редкие проблемы (угловые случаи), но их недостаточно, чтобы избежать этого устройства. Честно говоря, я считаю это устройство весьма полезным. Мне бы не понравилось, что я не смогу сделать следующее:
class Ticker { ... }
public StockQuote {
public Ticker Ticker { get; set; }
}
Я не хочу говорить Ticker StockTicker или Ticker ThisTicker и т. Д.
Я могу вспомнить только один недостаток. Если вы хотите сделать что-то вроде этого:
public class B1
{
public static void MyFunc(){ ; }
}
public class B2
{
private B1 b1;
public B1 B1
{
get { return b1; }
set { b1 = value; }
}
public void Foo(){
B1.MyFunc();
}
}
Вместо этого вам придется использовать:
MyNamespace.B1.MyFunc();
Хорошим примером этого является обычное использование в программировании Winforms, где класс System.Windows.Forms.Cursor перекрывается с классом System .Windows.Forms.Form.Cursor, поэтому события вашей формы должны получать доступ к статическим членам, используя полное пространство имен.
Буквально сегодня Эрик написал в блоге о проблеме «Цвет Цвет».
http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx
Лично я бы по возможности избегал этого.
С этим нет особых технических проблем. Это может повредить или улучшить читаемость. Фактически, некоторые библиотеки Microsoft имеют такие свойства (в частности, свойства enum , это обычно имеет смысл).
Очевидно, что это может немного сбивать с толку, когда имя свойства и его тип совпадают, но в остальном это не проблема.
Если имя имеет смысл, оно обычно лучше, чтобы имя и тип совпадали. Если вы можете придумать лучшее имя, вы, конечно, должны использовать его, но вам не следует пытаться придумать имя любой ценой, чтобы избежать этой ситуации.
Я давать вещам то же имя, что и их тип, за исключением case: мои методы и свойства - "lowerCase"; и поэтому у меня не было бы проблемы, которая есть у MiffTheFox.
public class B1
{
public static void myFunc(){ ; }
}
public class B2
{
private B1 m_b1;
public B1 b1
{
get { return m_b1; }
set { m_b1 = value; }
}
public void Foo()
{
B1.myFunc(); //this is Ok, no need to use namespace
}
}
Итак, для меня m_b1 - это данные члена, b1 - это свойство (или локальная переменная или параметр), и B1 - это имя класса.
Еще одна проблема связана с внутренними типами.
Я постоянно сталкиваюсь с этим:
public class Car {
public enum Make {
Chevy,
Ford
};
// No good, need to pull Make out of the class or create
// a name that isn't exactly what you want
public Make Make {
get; set;
}
}
Этот общий шаблон - одна из причин, почему я всегда использую this при обращении к члену экземпляра в классе. например, всегда
this.SomeMethod(this.SomeProperty);
и никогда
SomeMethod(SomeProperty);
В большинстве случаев реальной двусмысленности нет, но я считаю, что это помогает прояснить ситуацию. Кроме того, теперь вы знаете, где определено свойство / метод.