Java convention says make every field private and add getX()/setX(); Python convention says expose the attribute and reach for @property only if you later need one. Explain what language feature makes these opposite conventions both correct, and what each community pays for its rule.

## The principle being argued about Bertrand Meyer's **uniform access principle** says a client should not be able to tell whether a service is provided by stored data or by a computation. Where a language honours it, `account.balance` may be a field today and a computed member tomorrow, and no caller changes. Where it does not, the two forms are written differently at the call site, so switching is a breaking change to every caller. That single fact explains why two communities give opposite advice and both are right. ## Java: no properties, so the getter is insurance In Java, reading a field is `a.balance` and calling a method is `a.getBalance()`. Once you publish a public field you can never turn it into a computation, validate on write, add lazy loading, or fire a change event without editing every caller - and for a library, callers you cannot edit. The bean convention is a hedge against that future, plus an interoperability contract, because reflective tools historically discovered state through `getX`/`setX` names. Records give a shorter accessor form (`p.balance()`), still a method call. What Java pays: the convention that every field gets a getter and a setter mutates into the belief that this *is* encapsulation. A class with a private field and a public pair of accessors has the same public surface as a public field, with more code. Worse, the reflex produces objects that only carry data while behaviour drifts into service classes. ## Python and Ruby: the hook is always available Python's `@property` converts an attribute read into a method call transparently, so the community rule is "start public, add a property when you need one". Writing `get_total()` in Python is a recognised sign the author learned the idiom elsewhere. Ruby goes further: `obj.total` is already a message send, so every attribute read was always overridable, and `attr_reader`/`attr_accessor` merely generate the trivial methods. What they pay: uniform access cuts both ways. If the caller cannot distinguish a field read from a computation, they also cannot see that `order.total` performs a database query or mutates a cache. A property that is slow, that throws, or that has side effects is a genuine hazard, which is why the discipline is that properties stay cheap and pure. And Ruby's one-word `attr_accessor` makes an entirely open, invariant-free object the easiest thing to type. ## C#: uniform access with a compilation-model asterisk C# properties look like fields at the call site, so `p.Total` may become a computed property with no caller source change. The asterisk matters: fields and properties are different at the IL level, so the change is **binary breaking** and already-compiled assemblies must be recompiled. A property also cannot be passed to a `ref` or `out` parameter, and field-versus-property differs for reflection, serializers and data binding. Consequently the C# rule is not "add getters everywhere" but "anything public is a property from the start", with auto-properties making that cost one line. ## Kotlin, Swift, Objective-C, Go Kotlin exposes `val`/`var` as properties and compiles them to accessor methods, so declaring `val total: Int` and later giving it a custom `get()` is source-compatible and the JVM-level concern evaporates. Swift has stored and computed properties with the same syntax, plus `willSet`/`didSet` observers. Objective-C's `@property` and dot syntax made accessors the norm decades ago. Go deliberately has neither properties nor the bean convention: `p.Name` and `p.Name()` are different call sites, so Go APIs choose early and permanently, and the style guide explicitly rejects the `Get` prefix - the accessor is `Name()`, the mutator `SetName()`. ## What this actually means for design The accessor debate is a **representation-stability** question with a language-specific answer, and it is mostly independent of the design question that matters. Neither `public int total` nor `getTotal()` protects an invariant, because both expose the same information; and a `setTotal()` that assigns without checking anything is strictly worse than a public field, since it implies validation that is not there. The productive questions are: does this type own a rule that must always hold, and does the operation belong here or at the caller? A useful test for any codebase: for each accessor, ask what the caller does with the value. If the answer is "decides something the object could have decided", the accessor is enabling logic that belongs inside. If the answer is "serialises it", "renders it", or "asserts on it in a test", the accessor is legitimate boundary work. The language's property support tells you how much syntax that costs; it does not tell you which answer is right.