Можно ли использовать новое ключевое слово C# для расширения свойств в интерфейсе?
Я думаю, потому что эти две машины обычно должны были бы быть оптимизированы по-разному. Кроме этого я понятия не имею, мы запускаем все наши приложения с базой данных сервера по той же машине - допустил, что мы не общедоступны - но у нас не было проблем.
я не могу предположить, что слишком много людей заботятся об одной машине, поставленной под угрозу по обоим, так как веб-приложение будет обычно иметь почти неограниченный доступ к по крайней мере данным если не схема в базе данных.
Интересующийся тем, что могли бы сказать другие.
5 ответов
Это неплохая идея. Вы должны знать, что разработчик может (если он неявно реализует интерфейс, тогда одно свойство чтения / записи может удовлетворить оба интерфейса) предоставить две различные реализации:
class Test : ICanReadAndWrite {
public string Id {
get { return "100"; }
set { }
}
string IReadOnly.Id {
get { return "10"; }
}
}
Test t = new Test();
Console.WriteLine(t.Id); // prints 100
Console.WriteLine(((IReadOnly)t).Id); // prints 10
Между прочим, в общем, new модификатор наследования ничего не делает, кроме как сказать компилятору, чтобы он заткнулся и не выдает предупреждение «вы скрываете этот член». Его пропуск не повлияет на скомпилированный код.
Вы не должны реализовывать ICanReadWrite на основе IReadOnly, а вместо этого разделяйте их.
т.е. вроде этого:
public interface IReadOnly
{
string Id
{
get;
}
}
public interface ICanReadAndWrite
{
string Id
{
get;
set;
}
}
Вот класс, использующий их:
public class SomeObject : IReadOnly, ICanReadWrite
{
public string Id
{
get;
set;
}
}
Обратите внимание, что одно и то же свойство в классе может поддерживать оба интерфейса.
Обратите внимание, что согласно комментарию, единственный способ получить надежное решение - это также иметь объект-оболочку.
Другими словами, это нехорошо:
public class SomeObject : IReadOnly, ICanReadWrite
{
public string Id
{
get;
set;
}
public IReadOnly AsReadOnly()
{
return this;
}
}
поскольку вызывающий может просто сделать это:
ICanReadWrite rw = obj.AsReadOnly() as ICanReadWrite;
rw.Id = "123";
Чтобы получить надежное решение, вам понадобится объект-оболочка, например:
public class SomeObject : IReadOnly, ICanReadWrite
{
public string Id
{
get;
set;
}
public IReadOnly AsReadOnly()
{
return new ReadOnly(this);
}
}
public class ReadOnly : IReadOnly
{
private IReadOnly _WrappedObject;
public ReadOnly(IReadOnly wrappedObject)
{
_WrappedObject = wrappedObject;
}
public string Id
{
get { return _WrappedObject.Id; }
}
}
Это будет работать и быть устойчивым вплоть до момента, когда вызывающий объект использует отражение.
Это совершенно законно, и последствия для вашего класса, реализующего интерфейс ICanReadAndWrite, просто заключаются в том, что, когда он рассматривается как IReadOnly, он может только читать, но когда он рассматривается как ICanReadAndWrite, он может сделать и то, и другое.
Я не уверен, компилируется это или нет, но следовать этому шаблону не рекомендуется. Имея возможность делать явную реализацию интерфейса, вы теоретически можете предоставить две совершенно разные реализации для IReadOnly и ICanReadAndWrite с версиями свойства Id . Рассмотрите возможность изменения интерфейса ICanReadAndWrite путем добавления метода установки для свойства, а не замены свойства.
Вы можете это сделать, но я не уверен, чего вы надеетесь достичь, делая это.
public IReadOnly SomeMethod() {
// return an instance of ICanReadAndWrite
}
Этот метод вернет ссылку на IReadOnly , что означает, что не имеет значения, что вы вернули ICanReadAndWrite . Разве этот подход не был бы лучше?
public interface IReadOnly
{
String GetId();
}
public interface ICanReadAndWrite : IReadOnly
{
String SetId();
}