People have suggested that C# is sort of Delphi v2.0. Do you think that is a fair assessment? Is a lot of like breaking in the component model as part of the language, is a lot of that experience from having done some of the stuff with Delphi at Borland?

Well, there is no doubt that there is heritage from Delphi. Delphi has properties, Delphi has events and so forth, and if I have to go do it again, I still think they are useful concepts. So I would put into the next one too, if there was a next one. I think you learn from what you've done. You learn from your past mistakes, you know what worked and what didn't, and you keep the stuff that worked, and then you get rid of the stuff that didn't. Those are definitely things that worked and I think they are some of the things that made Delphi a great product.

___>И что же такого хорошего в этих пропетях? По моему так без них только лучше.

string networkID;
public int NetworkID
{
    get { return this.networkId; }
  set { this.networkId = value; }
}

private int id;
    
public int getId() {
    return id;
}
    
public void setId(int id) {
    this.id = id;
}

int networkID;
public int NetworkID
{
    get { return this.networkId; }
  set { this.networkId = value; }
}

public int NetworkID
{ get; set; }

___>>И что же такого хорошего в этих пропетях? По моему так без них только лучше.

int networkID;
public int NetworkID
{
    get { return this.networkId; }
    set { this.networkId = value; }
}

private int id;
public int getId() { return id; }
public void setId(int id) { this.id = id; }

someObject.SomeProp += 20;

someObject.setSomeProp(someObject.getSomeProp() + 20);

A>Если твой Рихтер сказал это тебе нежно на ушко — про такого не знаю. А если это тот, который автор книг — слышал и хочется увидеть цитаты.

Лично мне свойства не нравятся, и я был бы рад, если бы их поддержку убрали из Microsoft .NET Framework и сопутствующих языков программирования.

___>>Нда? Ну в таком случае — тебе прямая дорога в церковь. Я с этой мыслью не первый, а лишь согласен с Рихтером. Слышал про такого?

Лично мне свойства не нравятся, и я был бы рад, если бы их поддержку убрали из Microsoft .NET Framework и сопутсвующих языков программирования. Причина в том, что свойства выглядят как поля, на самом деле являясь методами. Это порождает массу заблуждений и непонимания. Столкнувшись с кодом, обращающимся к полю, разработчик предполагает наличие массы условий, которые не всегда верны, если речь идет о свойстве.
...
— метод свойства может привести к исключению, а при доступе к полям исключений не бывает;
...
— метод свойства может выполнятся довольно долго, а доступ к полям выполняется моментально. Часто свойства используют для синхронизации потоков, но это может привести к приостановке потока на неопределенное время — поэтому свойства не следует использовать для этих целей — в такой ситуации лучше задействовать метод. Кроме, того если предусмотрен удаленный доступ к классу (например, если он наследует System.MarshalByRefObject), вызов метода свойства выполнится очень медленно, поэтому предпочтение следует отдать методу. Я считаю, что в классах, производных от MarshalByRefObject, никогда не следует использовать свойства;
— при вызове несколько ряд подряд метод свойства может возвращать разные значения, а поле возвращает одно и тоже значение. В классе System.DateTime есть неизменяемое свойство Now ...
— метод свойства может создавать наблюдаемые стороние эффекты, а при доступе к полю это невозможно...
— методу свойства может требоваться дополнительная память или ссылка на объект, не являющаяся частью состояния объекта, поэтому изменение возвращаемого объекта никак не сказывается на исходном объекте; при запросе поля всегда возвращается ссылка на объект, который гарантировано относиться к состоянию исходного объекта. Свойство, возвращающее копию, — источник замешательства для разработчиков, причем это поведение часто забывают упомянуть в документации.
...

    private int m_field;

    protected abstract int GetField();

    internal void SetField(int value)
    {
        m_field = value;
    }

private int m_filed {GetMethodName, SetMethodName};

AVK>public int NetworkID
AVK>{ get; set; }
AVK>

class MyClass
{
    private int i_prop;
    public int Prop
    {
        set
        {
            if( value > 100 )
                throw new Exception("А вот хрен");
            this.i_prop = value;
        }
    }
}

class MyClass
{
    private int a;
    private int i;
    public int I
    {
        get
        {
            this.a = 666;
            return this.i;
        }
    }

    public int get_I()
    {
        this.a = 555;
        return this.i;
    }
}

...
    MyClass c = new MyClass();
    int d = c.I;   // то, что здесь меняется состояние объекта "c" уж очень неочевидно
    int e = c.get_I();
...

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

public class Provider
{
    private PropertyCollection m_properties;

    public PropertyCollection Properties
    {
        get
        {
            return m_properties;
        }
    }

    /// <summary>
    /// DBService has own db connection
    /// </summary>
    public DBService Service
    {
        get
        {
            return new DBService(m_properties.ConnectionString);
        }
    }
}

class Program
{
    static void Main(string[] args)
    {
        Provider provider = new Provider();

        //correct
        provider.Properties.Name = "provider";
        provider.Properties.ConnectionString = "bla bla";

        //correct, but not optimal (two connection)
        provider.Service.GetTable1Content();
        provider.Service.GetTable2Content();

        //good practice (one connection)
        DBService service = provider.Service;
        service.GetTable1Content();
        service.GetTable2Content();
    }
}

...
4. Не используйте публичные поля, вместо них следует использовать свойства.
5. Используйте свойства, вместо Get/Set методов.
6. Используйте методы, если выполняемая операция является преобразованием, обладает побочными эффектами, долго выполняется или если важен порядок выполнения операций.
7. Свойство не должно менять своего значение от вызова к вызову, если состояние объекта не изменяется. Если результат при новом вызове может быть другим при том же состоянии объекта, используйте метод.
8. Не используйте свойства «только для записи». Потребность в таком свойстве может быть признаком плохого проектирования.
....

//correct, but not optimal (two connection)
provider.Service.GetTable1Content();
provider.Service.GetTable2Content();

Свойство не должно менять своего значение от вызова к вызову, если состояние объекта не изменяется.

ZEN>А если нужно перегрузить Get()/Set() в потомках?

int networkID;
public virtual int NetworkID
{
  get { return this.networkId; }
  set { this.networkId = value; }
}

IB>>Свойство не должно менять своего значение от вызова к вызову, если состояние объекта не изменяется.

ZEN>Это прерогатива поля.

public void doSomfin(byte[] is) /*nofin here*/
    try
    {
        fileinputstream.read(is);
    }
    catch (Exception e)
    {
        throw new RuntimeException(e);
    }

public class MyClass
{
    public static readonly MyClass SpecialCase1 = new MyClass(...);
    public readonly ValueType Param1;
    private readonly ImmutableInterfaceImplementor param2;
    public readonly ReferenceType Param3;

  // Может быть и private, тогда предполагается создание объекта через
  // статический метод-конструктор
    public MyClass(ValueType param1, IReadOnlyInterface param2, ReferenceType param3)
    {
        this.Param1 = param1;
        // Обязательно делаем локальную иммутабельную копию!
        // ImmutableInterfaceImplementor тоже должен иметь value-type семантику.
        this.param2 = new ImmutableInterfaceImplementor(param2);
        this.Param3 = param3;
    }
    
    public static MyClass SpecialConstructor(...)
    {
        // ...
    }
    
    public IReadOnlyInterface Param2
    {
        get
        {
            return param2;
        }
    }
    
    public static bool operator ==(MyClass a, MyClass b)
    {
        if (object.ReferenceEquals(a, b))
            return true;
        return
            a.Param1 == b.Param1 &&
            a.param2 == b.param2 &&
            a.Param3 == b.Param3;
    }
    
    public static bool operator !=(MyClass a, MyClass b)
    {
        return !(a == b);
    }
    
    public override int GetHashCode()
    {
        // Возможна ленивая реализация для больших объектов. При этом заводятся мутабельны поля
        // hash = 0 и needHash = true.
        //
        return
            (a.Param1.GetHashCode() << 2) ^
            (a.param2.GetHashCode() << 1) ^
            a.Param3.GetHashCode();
    }
    
    public override bool Equals(object obj)
    {
        if (!(obj is MyClass))
            return false;
        return this == ((MyClass)obj);
    }
}

The signature of a method specifically does not include the return type, parameter names, or
type parameter names, nor does it include the params modifier that can be specified for the right-most
parameter.

Although out and ref parameter modifiers are considered part of a signature, members declared in a single
type cannot differ in signature solely by ref and out.

У типа System.Object есть виртуальный метод Equals, который возвращает true для двух "равных" объектов. Вот реализация метода Equals для Object:

public class Object {
    public virtual Boolean Equals(Object obj) {
        if (this == obj) return true;

        return false;
    }
}

... Иначе говоря, оказывается, что стандартная реализация метода метода Equals типа Object реализует проверку на тождество, а не на равенство.
Как видите, оказалось, что приведнная выше стандартная реализация не годится: нужно переопределить Equals и написать его собственную реализацию.
Вот как нужно это делать:
1. Если аргумент obj равен null, вернуть false.
2. Если obj и this ссылаются на объекты разного типа — вернуть false.
3. Сравнить все определнные в типе экземплярные поля объектов obj и this. Если хотя бы одна пара полей не совпадает — вернуть false.
4. Вызвать метод Equals базового класса, чтобы сравнить определнные в нем поля. Если метод базового класса вернул false, тоже вернуть false, иначе вернуть true.

Поэтому Microsoft должна была реализовать метод Equals типа Object так:

public class Object {
    public virtual Boolean Equals(Object obj) {
        if( obj == null ) return false;

        if( this.GetType() != obj.GetType() ) return false;

        // Т.к. в System.Object не определены поля, следует считать, что поля равны
        return true;
    }
}

...