When a computer language enables you to define class "properties" (with getter and setter code that you define) so that client code can "set" and "get" the properties using the same syntax as they would for setting and getting public field values on the class' instances, then you have PropertyFieldTransparency:
''Therefore: Should you, for example, want to be able to use a Class like this:
Imports Xunit ' Public Class Tests <Fact()> Sub TestClass() Dim c1 As New Class("Initial Value") Assert.Equal("Initial Value", c1.ReadOnlyProperty) c1.UpdatableProperty = "Some Input Value" Assert.Equal("Some Input Value", c1.UpdatableProperty) End Sub End ClassYou could implement it like this:
Public Class Class ' Private ReadOnly _readOnlyValue As String Private _updatableValue As String ' Public Sub New(ByVal initialValue As String) _readOnlyValue = initialValue End Sub ' Public ReadOnly Property ReadOnlyProperty() As String Get Return _readOnlyValue End Get End Property ' Public Property UpdatableProperty() As String Get Return _updatableValue End Get Set(ByVal newValue As String) _updatableValue = newValue End Set End Property ' End Classor you could implement it like this:
Public Class Class ' Public ReadOnly ReadOnlyProperty As String Public UpdatableProperty As String ' Public Sub New(ByVal initialValue As String) ReadOnlyProperty = initialValue End Sub ' End ClassAnd the client code (the XunitDotNet test above) does not know or care which implementation is used.
Now if a Property Set method (if it exists) does nothing more than store the value into a Private Field, and the Property Get method does nothing more than return the value of the Private Field, then why would you want to generate all the boilerplate Get and Set code, with Private Fields?!?!? Doing so violates YouArentGonnaNeedIt: When you implement class "Properties" as simple Public Fields, you can change them to first-class Properties later, with arbitrary code in Get and Set methods, should you ever need to. And doing so does not change the client source code.
In a language with PropertyFieldTransparency, the EncapsulateField refactoring is trivial to accomplish, even by hand, as it does not require any changes to the source code using the class. (...and therefore does not show a large number of lines changed on checkin -- something that can be a barrier to refactoring in some organizations. ;-)
And if the Property/Field needs to be read only, use language features like the ReadOnly attribute in DotNet or 'final' in the JavaLanguage.
In languages with PropertyFieldTransparency, don't clutter your code with boiler plate Property Get and Set methods: Just declare the Fields Public. Refactor to Properties later, should the code ever need non-boilerplate Get or Set method implementations.
(...admitting that one's code will generally be more ObjectOriented if you DontUseGetAndSet, so you might not want to do either. And that this applies equally to Properties.) -- JeffGrigg
See CodingHorror? article, "Properties vs. Public Variables" on this topic:
http://www.codinghorror.com/blog/archives/000654.html...which describes both
-- JeffGrigg