什么时候使用公共场所才有意义? [英] When does it make sense to use a public field?

问题描述

这是我现在已经问了一段时间的问题:

This is a question I have had for a while now:

什么时候像这样公开公开某个领域有意义?

When does it make sense to expose a field publicly like so?

public class SomeClass()
{
   public int backing;
}

这样做的缺点(除了激怒OOP精英)还在于，如果您需要在此数据之上添加任何逻辑，则必须对API进行重大更改.我想这就是精英主义者所要关注的.

The downside of doing this (in addition to angering OOP elitists) is that you have to introduce a breaking change to your API if you ever need to add any logic on top of this data. I suppose that is what the elitists are on about.

长期以来，Java和C#的最佳实践一直是使用getter/setter或属性来访问字段.

Best practice in Java and C# has long been to use getters/setters or properties to access fields.

public class SomeClass()
{
   private int backing;

   public int getBacking()
   {
      return backing;
   }

   public void setBacking(int v)
   {
      backing = v;
   }
}

C#将其演变为具有自动属性的非常简单的语法:

C# has evolved this to pretty simple syntax with automatic properties:

public class SomeClass()
{
   public int Backing { get; set; }
}

虽然我发现自己做了很多事情，但是我仍然觉得这很懒.更重要的是，我不确定是否知道在公共场所会更有意义.

Lazy me still feels this is too long though since it something I find myself doing a lot. More importantly, I am not sure I know where a public field would make more sense.

为什么不仅仅将公开声明的字段视为幕后的属性(或方法)?那样就不可能激怒解耦的神灵并减少打字的难度.

Why not just treat publicly declared fields as properties (or methods) behind the scenes? That way it would be impossible to anger decoupling gods and be a bit less typing to boot.

public class SomeClass()
{
   public int backing;   // The same as public int backing { get; set; }
}

对于只包裹基础字段的属性，我很确定JIT优化了方法调用，因此性能可能不是问题.有什么想法吗? (字段名称的大小写约定除外)

For a property that does nothing but wrap the underlying field, I am pretty sure the JIT optimizes the method calls away so performance is probably not the issue. Any thoughts? (other than the proper case convention for the field name)

编辑:感谢您的所有回复.我觉得也许不是每个人都在理解我的问题.什么时候将公共场所比财产是更好的选择?为什么它是一个更好的选择?如果唯一的原因是方便(减少键入和混乱)，那么每当遇到公共字段时，让编译器生成幕后"属性的缺点是什么.基本上，不可能创建一个真正的公共字段(因为它们全都是属性).那有什么问题呢?谢谢.

Thanks for all the responses. I feel like perhaps not everyone is understanding my question though. When would a public field be a better choice than a property? Why is it a better choice? If the only reason is convenience (less typing and clutter), then what would be the downside of having the compiler generate a property "under-the-hood" whenever a public field is encountered. Basically, it would be impossible to create a true public field (because they would all be properties). What would be wrong with that? Thanks.

推荐答案

在我看来，当您设计类的结构时，您应该更加注意将来的更改，并且应该始终对它们友好.如果将来的需求需要您在返回值之前做一些逻辑而不是仅返回字段的值，则必须更改类的接口，并且库的所有用户都必须更改.通常这是一场灾难.

In my opinion, when you design a structure of a class you should pay more attention to future changes and should always be friendly to them. If a future requirement need you to do some logic before returning a value instead of just returnning the value of the field, you'll have to change the interface of the class, and all users of your library will have to change. That usually become a disaster.

请记住，打开/关闭原则.

这篇关于什么时候使用公共场所才有意义?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！