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:
* This provides a more convenient syntax for client programs to get and set property values.
'''''And more importantly...'''''
* It shields the client code from knowing how the "property" they're manipulating is implemented --
** by by a local field,
** with remote data,
** by computing and changing derived data or another data format,
** or any other approach.

In languages that have PropertyFieldTransparency, you can use public fields in all the places where you would use boilerplate 'private field, and getter and setter methods', with confidence that should you have the need to introduce non-boilerplate getter or setter code in the future, you can make the public field private, and introduce a "property" definition with the needed getter and setter code.

'''''Therefore:'''
Should you, for example, want to be able to use a Class like this:
    Imports Xunit
    '
    Public Class Tests
        <Fact()> Sub T''''''estClass()
            Dim c1 As New Class("Initial Value")
            Assert.Equal("Initial Value", c1.R''''''eadOnlyProperty)
            c1.U''''''pdatableProperty = "Some Input Value"
            Assert.Equal("Some Input Value", c1.U''''''pdatableProperty)
        End Sub
    End Class
You could implement it like this:
    Public Class Class
        '
        Private R''''''eadOnly _readOnlyValue As String
        Private _updatableValue As String
        '
        Public Sub New(ByVal initialValue As String)
            _readOnlyValue = initialValue
        End Sub
        '
        Public R''''''eadOnly Property R''''''eadOnlyProperty() As String
            Get
                Return _readOnlyValue
            End Get
        End Property
        '
        Public Property U''''''pdatableProperty() As String
            Get
                Return _updatableValue
            End Get
            Set(ByVal newValue As String)
                _updatableValue = newValue
            End Set
        End Property
        '
    End Class
or you could implement it like this:
    Public Class Class
        '
        Public R''''''eadOnly R''''''eadOnlyProperty As String
        Public U''''''pdatableProperty As String
        '
        Public Sub New(ByVal initialValue As String)
            R''''''eadOnlyProperty = initialValue
        End Sub
        '
    End Class
And 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 '''R''''''eadOnly''' 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''
* the YouArentGonnaNeedIt case above
* and the cases where you '''might''' need to use Properties instead of Public Fields.  ''(IE: when you're defining a public API for client code)''
See also http://jeffgrigg.wordpress.com/2009/02/06/property-field-transparency/

-- JeffGrigg