c# - Readonly field vs abstract getter-only property -


what advantages , disadvantages of having readonly field compared having inheritors implement abstract getter-only property (using c# example here, guess doesn't matter much).

here both ways this:

  1. readonly field; inheritors have inject value in constructor

    interface iface {   public int field { get; } }  abstract class base : iface {   private readonly int field;    protected base(int field) {     this.field = field;   }    public int field { { return this.field; } } }  class impl {   public impl() : base(1) {   } } 
  2. abstract getter-only property; inheriters have implement property

    interface iface {   public int field { get; } }  abstract class base : iface {   // default constructor can used    public abstract int field { get; } }  class impl {   public override int field { { return 1; } } } 

both implementations expose public int field getter-only property not change.

however, can see following differences:

  1. the value of field bound each instance , there's nothing preventing inheritors allowing receive value in constructors (public impl(int field) : base(field)).

    being bound instance, memory field required each single instance. might not big deal, it's keep in mind.

    the conveyed intent is: value can set in constructor , cannot change later on (leaving aside reflection).

  2. the (returned) value of field bound each type, there's nothing preventing inheritors generating/calculating value each time getter called, potentially returning different value each time. public overried int field { { return datetime.utcnow.second; } }

    memory required "in il", since value (usually) not stored anywhere, computed before being returned (resulting in load instruction , nothing more).

    the conveyed intent should be: value bound type (and shouldn't change between calls, there's no way force that, right?). rather intent comes across as: need provide property, don't care how implement , value returns.

are there crucial differences i'm missing? 1 preferred on other, or required decide on case-by-case basis?

i guess i'm looking construct/pattern/language feature binds readonly (constant) values type, expose value @ instance level. know can use static fields in each inheriting type, there's no way enforce common base (or interface). furthermore, static fields cannot called when having reference instance of type. thoughts? i'm happy receive answers in different programming languages

there 1 crucial difference between pattern 1 , pattern 2 have given.

pattern 1 not allow return different value once class constructed because base class takes field in constructor.

pattern 2 allows child classes return different values @ different times. - there nothing enforced base class if child class decides override.

thus - depends want achieve , domain logic.

regarding intent trying achieve - in opinion - 1 of ways tackle implement intention declare virtual method (something getreadonlyfield() in base) rather read-only property. - child classes free override virtual method - if not override - base implementation still enforced.

there cannot 1 right answer question. there multiple ways resolve this. depends on requirements.


Popular posts from this blog

c# - ODP.NET Oracle.ManagedDataAccess causes ORA-12537 network session end of file -

matlab - Compression and Decompression of ECG Signal using HUFFMAN ALGORITHM -

utf 8 - split utf-8 string into bytes in python -