31–40 of 216 posts
No, no, and no. There are interfaces with default impls these days, don't allow base class state.
And figure out how to make interfaces "sealed".
... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
I can't speak to Java, but in C#, the original goal was to reduce coupling. You can add behavior to getter and setter methods without breaking binary compatibility among packages. It absolutely is obfuscation, to the extent that encapsulation is just a special kind of obfuscation. Possibly more importantly, public fields give you no way to create immutable types.
public readonly int Foo;
readonly fields can only be set in the constructor, great for immutable types and with much better guarantees than protected/private/no setters.
... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
To provide flexibility in the future. When your data comes from a method you can change its source without changing the caller. This can be very useful and should be leveraged whenever possible.
To clarify, I would not consider something like this a setter:
class Monster {
int health;
void Damage(int d) {
this.health -= d;
}
}
There is definitely a time and place for plain data objects. But if you find yourself actually needing validation and preprocessing in your get/set, then you probably have a 'real' object hiding their. Stop being lazy and give it proper methods.
Yes, I refuse to call Kotlin a different programming language like Scala, because it's just syntactic sugar over good-ol-Java, while all tools, approaches, stackoverflow are the same. But it has the data classes, implemented just like the article described.
... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…
If you have a temperature class with a celsius field and change the internal representation to kelvin you have to update all client code to call a conversion method. C#s syntax sugar allows you to slot in the conversion method without a breaking change but it screws with the cost model of field accessing when used unresponsibly. Java doesn't have it so you would have to hide everything behind getters if you don't wan…
Couldn't you also refactor that by changing the constructor of your temperature class so it converts things to Kelvins, rather than converting it every time you call the getter?
AutoValue with Builders is nice: Animal dog = Animal.builder() .setName("dog") .setNumberOfLegs(4) .build(); https://github.com/google/auto/blob/master/value/userguide/b...
data class Animal(dog: String, numberOfLegs: Int)
val dog = Animal(
name = "dog",
numberOfLegs = 4
)
Earlier quoted context omitted.
If you have a temperature class with a celsius field and change the internal representation to kelvin you have to update all client code to call a conversion method. C#s syntax sugar allows you to slot in the conversion method without a breaking change but it screws with the cost model of field accessing when used unresponsibly. Java doesn't have it so you would have to hide everything behind getters if you don't wan…
I appreciate you thinking of an example, but I guess I find it a bit convoluted. Couldn't you also refactor that by changing the constructor of your temperature class so it converts things to Kelvins, rather than converting it every time you call the getter?
Temperature temp = Temperature.fromCelsius(13);
...
System.out.println(temp.celsius);
System.out.println(temp.getCelsius());
Earlier quoted context omitted.
I can't speak to Java, but in C#, the original goal was to reduce coupling. You can add behavior to getter and setter methods without breaking binary compatibility among packages. It absolutely is obfuscation, to the extent that encapsulation is just a special kind of obfuscation. Possibly more importantly, public fields give you no way to create immutable types.
> Possibly more importantly, public fields give you no way to create immutable types. public readonly int Foo; readonly fields can only be set in the constructor, great for immutable types and with much better guarantees than protected/private/no setters.
Or just install Lombok.