C# encapsulate field is a violation of YAGNI

Question

Consider these two ways to declare a field in a C# class

option A

public class AuditController
{
    public DataAccess Service;
}

option B

public class AuditController
{
    private DataAccess service;
    public DataAccess Service { get => service; set => service = value; }
}

Which one is better? My code analyzers (sonarqube, resharper, etc) unanimously say B is better. But I disagree. I can see that B encapsulates the field, so that a person can later add validation and logging, etc. However, why not wait until you need it?

This is the YAGNI principle: you can add the getter/setter now, or wait until you need it. Since there is no penalty for waiting, you should wait. Because most likely... you ain't gonna need it.

Am I missing something?

I'm not asking whether getter/setters provide any benefit of encapsulation. I'm asking whether it is best practice to proactively add getter/setters that are doing nothing other than exposing the data.

Answer 1

There are two completely different kinds of software: libraries that need a stable binary interface across multiple versions, and applications or internal software where you can just refactor.

For internal software or applications, you are right: you can wait until something is needed, then refactor and recompile your code. So using public fields is jucky but fine.

A public^[1] library doesn't have this liberty. If you change a field to a property that is a breaking change – a property is basically a method with prettier syntax. This change is source-compatible (stable API) but not binary-compatible (unstable ABI). Any dependent code that accesses this field/property has to be recompiled.

^{[1]: Here, “public” means “consumed by developers outside of your team”.}

A lot of design advice that you see (SOLID, design patterns, …) is focused on keeping your software evolvable while still keeping ABI compatibility. This isn't bad advice, it's just not always applicable. YAGNI is the complete opposite because it assumes that the design can be fixed by refactoring. Again not bad advice, just not always applicable either.

This is not a free pass for ignoring any design advice, just a pointer that design advice tends to assume a particular context.

But even ignoring the necessity of using properties, you should always use them:

• Properties are idiomatic C# code. Not using them makes your code more complicated to read.
• They are not that more code to type. Deal with it.
• Public fields in themselves are a design smell, and reek of insufficient object modeling for anything more complicated than a DTO. Properties can be publicly gettable and privately settable, which is often the better choice.
• All databinding technologies (ASP.Net MVC Model Binding, WinForms, WFP, Xamarin, Asp.Net WebAPI, …) will only databind to properties.
• Some cases need properties, so you might as well use them anywhere. The downsides – a tiny bit more typing, in rare cases a tiny performance hit – usually don't outweigh the increased consistency.

Answer 2

YAGNI isnt a principle, its an excuse for not doing stuff.

Here we can use the syntactic sugar

public DataAccess Service { get; set; }

and its cost us 10 characters worth of typing to get the benefits of a property over a field.

Maybe in the old days you could get away with fields, but so much stuff expects properties now, You are going to need it.

Get into the habit of doing stuff in full and not taking shortcuts and you just won't notice the extra effort.

Answer 3

Validation and logging are not really the main reason for using properties. How often have you actually used them for this purpose? I have very rarely. There are, however, several much more important reasons to use them:

• encapsulation: by having a getter/setter, you have just a single "entry point" for accessing your field. You know that some other piece of code can only access the field through them. You can later change the implementation and users of the class won't even notice. For example, your getter might change between returning the value of field, calculating the value on the fly from other fields, or calculating it but also caching the value for later use. Or you have your data in a list, but later decide that an array would be better for some reason. If you start off with pure field access, you don't control how other code uses that field and you can never change the implementation.
• mocking/stubbing: accessors are methods, so they can be mocked by a testing framework, which fields can not
• allowing behavior to be changed in subclasses
• since they are methods, they can be modified by code generation libraries or aspect-oriented programming; You could, for example, add performance metrics or access control to all getters which match certain criteria using a single aspect in AOP; your web framework or commons library might even be doing this for you
• it is a common convention - other programmers expect you to use this style which makes mutual understanding of code easier; sometimes consistency is more important than being optimal
• again as a convention, many frameworks can automatically perform certain operations on classes which conform to the property model - for example such classes may automatically be mapped to DTOs for storing in a database, deserialized to and from JSON, etc. Some frameworks may work this way with fields as well but others may not, both for technical and conventional reasons.

So, actually, there is a penalty for waiting. By not using properties, you lose the benefits listed above. And since it is very hard to change once the version with raw field access is out in the wild, it's better to start out with properties. The cost is minimal but there is much to lose if you happen to need any of the above points later on.

Answer 4

I just discovered in C# you can get the best of both worlds with auto property. For example,

public class AuditController
{
    public DataAccess Service { get; set; }
}

It gives you the warm feeling of encapsulation, but without the redundancy of option B.

Answer 5

By themselves, the code examples you've provided don't let you decide on this, because without context (the rest of the system, the evolution of the design of the system), it's more or less meaningless to talk about the details of how to encapsulation, except vaguely, in terms of best practices.

A good OO class will often not have many properties (there will not be a 1-to-1 mapping between the underlying representation and the public interface); instead, it will have a number of methods that perform some operation (you can ask the object to "do something"), and these methods will not expose much of what's going on inside the object.

Then there are those "objects" that are just data bags, with little to no behavior. These are often found at the boundaries of different components/subsystems. In this case, you may decide that getters and setters are a waste of time, or you may decide to have them because of practical reasons, depending on the language and the tools you are using (e.g., it could make the debugging easier).

As for YAGNI - it's a general principle, not a law of the universe. You kind of have to figure out what's its domain of applicability, and there will be some edge cases the benefits of breaking it outweigh the cost.