CODEWITHSUNDEEP
c#
LxL
LxL

Reputation: 1948

Should I use a private field of a public property inside a class where I declare that property?

Let say I have a class like this:

public class A
{
    private BaseSettings fieldA;
    public ISettings PropertyA
    {
         get {return fieldA;}
         set {fieldA= value as BaseSettings;}
    }
}

where BaseSettings implements ISettings. Inside class A, if I want to access BaseSettings' property called PropertyB, which of this is a good practice: 

fieldA.PropertyB;

or

((BaseSettings)PropertyA).PropertyB;

One may say the first approach may hide the hint to when a property changed. For example, a code may listen to PropertyChangedEvent and then the value for property changed without raising the event.

Another one may say the second approach may expose a risk that when a person who is not familiar with current code modify it, he may cast the PropertyA to different type that implements ISettings.

Both approaches have its downside. In a good programming practice, which one should be more preferable?

EDIT: Added based on the comments belows:

I agree that setting the backing-field as ISettings makes absolute sense. But what should I do to make sure that the PropertyA is always type of BaseSettings. That will raise a question: "Then why don't you set both property and backing-field to BaseSettings?".

The reason behind why property and its backing field are different is that class A also implement an interface like this

public interface IControlWithSettings
{
     ISettings OwnerSettings
     {
         get;
         set;
     }
     ISettings Settings
     {
         get;
         set;
     }
}

So the actual classA would look like this

public class BaseForm: Form, IControlWithSettings
{
    private BaseFormSettings settings;
    public ISettings Settings
    {
         get {return settings;}
         set {settings= value as BaseFormSettings;}
    }
}

And I have another class B would also implement IControlWithSettings

public class BaseUserControl: UserControl, IControlWithSettings
{
    private BaseUserControlSettings settings;
    public ISettings Settings
    {
         get {return settings;}
         set {settings= value as BaseUserControlSettings ;}
    }
}

Both BaseFormSettings : ISettings and BaseUserControlSettings : ISettings . This is actual ISettings interface

public interface ISettings
{
    Dictionary<string, ISettings> Children { get; set; }
}

the 'as' casting is a side effect I put into the setter so that it will ignore and return null if the setting is set to wrong one. I read somewhere saying I shouldn't throw exception in a setter. So making it null is my way to inform there is something wrong has been done.

So what is the better approach. Did I design it wrong?

Upvotes: 0

Views: 518

Answers (1)

Thomas Weller
Thomas Weller

Reputation: 11717

As you stated, both approaches have their downsides, and it also depends on whether the property setter may contain some additional logic (e.g. validation), and you may use or circumvent this additional logic from inside the class.
If there's nothing that speaks against it, I'll use direct access to the field. It's neater and it avoids all this typecasting stuff.

But generally: Why would you back your property with the derived type, while the property itself has the interface type? This doesn't make much sense. Why not just:

public class A
{
    public ISettings PropertyA { get; set; }
}

This would be much cleaner, and your question wouldn't even arise.

Edit (based on the answer's edit)
In case of the 'double use' of the backing field the typecasting makes sense. But I don't think (and never heard that before) that it's a bad thing to throw an exception from a property setter. On the contrary: Validating a value and throwing an exception if it doesn't pass is a very common pattern.
So, in your concrete case, I would validate the value for the correct type, throw if it's not correct, and use the backing field internally to bypass this type check.

Upvotes: 1

Related Questions