2

In Java, I'm wondering why the "length" attribute of the String class isn't private? Isn't it a bad practice according to encapsulation principle? Why is there no method like "getLength()" for instance?

PS: Sorry for my English, I'm still improving it.

Carl Manaster
  • 39,912
  • 17
  • 102
  • 155
lost3den
  • 815
  • 1
  • 6
  • 6

4 Answers4

9

In fact, it really is private. Maybe your confusing with the length() method?

bruno conde
  • 47,767
  • 15
  • 98
  • 117
  • It's quite reasonable to have a `String` implementation without a `length` or `length`-like field. Arguably a better implementation of `String` (particularly now that `StringBuffer` is less used and has changed implementation) is to use a `char[]` of exactly the right length - no `length` or `offset` fields necessary. – Tom Hawtin - tackline Mar 12 '10 at 17:39
4

There is no public attribute called "length" in java.lang.String. There is a public method "length()", but you can't use it to set the length of the String. It is arguable that they should have called the length() method getLength(), but that was just a choice they made.

DJClayworth
  • 26,349
  • 9
  • 53
  • 79
0

Warning: Tangential topic

Public attributes are not inherently evil. The problem with Java is that it doesn't have properties, which allow you to have exposed internal variables at the beginning. When your requirements for encapsulation grow stronger you can change the internals of the class without affecting its signature/API. With properties, you can have your cake and eat it too, you can access a property as a variable, but being unable to set/assign to it outside the class.

Java programmers get around this by creating from the start getters and setters for every public facing attribute, whether it has any kind of processing or not, just in case. I've seen Java programmers starting on other languages that do have properties doing the same sin of using getters and settersthing . Please, if you ever go to another language, don't bring all the misconceptions from Java born out of implementation details of the JVM.

Encapsulation != getters && setters.

</rant>

Esteban Küber
  • 36,388
  • 15
  • 79
  • 97
  • String is an immutable class, and exposing it's length for modification would be a major sin. – DJClayworth Mar 12 '10 at 15:21
  • 1
    voyager isn't suggesting that it be exposed for modification. more, it's seems to be "I wish Java were more like C#/Scala/other-languages-with-properties". Of course, it's still a completely off-topic response. – Carl Mar 12 '10 at 15:44
  • 1
    @voyager Java classes most certainly have properties. The JavaBeans specification formalizes what it means to be a Property in Java. It just so happens that the language implies their public manifestation as a set of accessors and mutators conforming to a certain naming convention. Public attributes are indeed not inherently evil, and you don't need to step out of Java to see that: classses can have public, read-only Properties. Public modifiable *fields* are inherently evil. They expose object state in an uncontrolled manner. – Noel Ang Mar 12 '10 at 17:55
  • @Noel: *Some object-oriented languages, such as Java, don't support properties, and require the programmer to define a pair of accessor and mutator methods instead. Other languages designed for the Java Virtual Machine, such as Groovy, do natively support properties.* - Wikipedia. Properties allow you to expose a simplification of the object state in a controlled manner. – Esteban Küber Mar 12 '10 at 18:30
0

I think you mean the array objects, right?

Personally I think it's all-right to have (preferably final) fields on classes that are just glorified structs. E.g., I would rather do

public Person {
  final String name;
  final String surname;

  public Person(String name, String surname) {
    this.name = name;
    this.surname = surname;
  }
}

than the same thing with getters and setters.

lindelof
  • 34,556
  • 31
  • 99
  • 140
  • Public fields are never a good idea! If you want public constants, use enums. Public fields preclude the possibility of adding functionality in a subsequent refactoring. You might think your object is so simple and perfect it will never change but that's not a wise decision when the alternative, g/setters, is such a simple solution (and automatic with today's IDEs). Besides, it's so common to expect g/setters these days, if anyone were going to use your "glorified struct", they'd probably consider it unusual. – nicerobot Mar 12 '10 at 16:21
  • Exactly right, which is why I only ever do this on small classes with package-private fields. Anything that shows signs of sprouting legs, I immediately revert to using getters. – lindelof Mar 16 '10 at 15:27
  • @nicerobot "Public fields are never a good idea!". Java thought it was a good idea when they created made the property .length in arrays. Arrays don't change just like Strings dont. – Philip Rego Feb 13 '18 at 18:55
  • @PhilipRego you got me. I should have been more precise and said “almost never”. For fully immutable instances, certain fields can also be immutable. But it doesn’t invalidate the point that it will always work to implement them as methods. Especially since many java devs didn’t then and still don’t embrace immutability. – nicerobot Feb 14 '18 at 00:24