141–150 of 216 posts
AutoValue with Builders is nice: Animal dog = Animal.builder() .setName("dog") .setNumberOfLegs(4) .build(); https://github.com/google/auto/blob/master/value/userguide/b...
Not that nice compared to kotlin: data class Animal(dog: String, numberOfLegs: Int) val dog = Animal( name = "dog", numberOfLegs = 4 ) The amount of boilerplate for AutoValue builders is so ridiculous that most people use IDE plugins to generate it.
Earlier quoted context omitted.
Celcius is definitely a getter. The name absolutely implies that it's retrieving a value because it's name is not a verb or action. Properties in C#, for example, really just remove the ambiguity in this exact situation. Is it object.Celcius or object.Celcius()? A good C# programmer would use the former. A method would be object.RaiseTemp().
It looks like I have a really different definition of "getter" than some people here. I would only call something a getter if it explicitly makes reference and effectively exposes an internal field. Just giving a method a noun name is not enough to make it a getter, in my mind. It's the "get" prefix that says 'hey there is definitely a field in here called Foo that we think we're encapsulating but we're really not'.
A getter can then by definition not simply refer to only a field anymore as that field is gone. It might have done so in the first version of the class where Fahrenhet() simply returned your fahrenheit field(a getter) but now we've removed that field and replaced it with a celcius field. That means Fahrenheit() doesn't just return a plain field anymore, there is some transformation going on. It's still considered a getter.
Earlier quoted context omitted.
But by definition getters and setters lack lexibility. They expose the internal representation of an object. They stop really being "objects" - high level opaque things you send messages to - and they turn into big porous bags of fields. To clarify, I would not consider something like this a setter: class Monster { int health; void Damage(int d) { this.health -= d; } } True, it is a method that just sets a variable.…
`Technically` The current representation of `objects` in java is a abomination to the original idea behind object's. Hell even the use of class, members and fields fly in the face of what real objects are.
Whose original idea behind objects? Alan Kay and Dan Ingalls? As recently as September 2017 Gosling publicly stated [1] that Java's object model is entirely based on Simula. Object-orientation didn't start with Smalltalk, and its biggest contribution of the concept of (non-command) messaging between objects (all the way down), has proven none too popular in modern languages (excluding Objective-C), unlike those of Simula which introduced objects, classes, sub-classing and virtual functions.
Java is entirely consistent with these "original ideas".
---
"data class" is already in Kotlin flavor. 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.
Earlier quoted context omitted.
Today's fields are tomorrow's computed properties. Fields are rigid and cannot be changed without recompiling dependencies. Notice how few fields there are in Java's standard library. Why have fields at all?
How many times have you run into this in your career (the need to convert "today's fields to tomorrow's computer properties")?
In this scenario it's easy to make the old method do something sensible like "return the first item." But maintaining an old field is more difficult: you can't make it lazy, you can't eliminate its backing storage, etc.
Earlier quoted context omitted.
They are useless until one day they become extremely useful. In other words most of the time there’s minimal advantages. However by following good form you will eventually come across and instance where you have to do something and instead of having to change code in tons and tons of places, places you may not event have access to such as a public API, you don’t realize the importance. Hopefully you never across the…
Let me give a concrete example from my past. We had a public API of POJO domain objects that could be used to render templated files, think string replace. It worked great until one day someone had a special character that caused it all to fail. How do you fix this? Ask all customers to clean their values? Good luck with that!! However from our side we just added the code to clean the output, escape the special chara…
Earlier quoted context omitted.
Your definition of getter and setter are way too narrow. You exclude all getXX() and setXX() methods that don't directly manipulate a field and all C# property get/set the same way. The getter or setter is part of the public interface of the object. The public interface makes no guarantees about implementation -- encapsulation is one of the fundamental principles of OOP. It is only supposed to appear from outside tha…
I think you're not understanding what I'm saying. Luckily this person explained it better than I could. https://news.ycombinator.com/item?id=15607598
https://news.ycombinator.com/item?id=15607812
There simply isn't a better domain method term for moving data from one place to another than get/set. You could invent alternatives but they're just more confusing.
And even that linked comment addresses modification not retrieval. Sometimes you just want a value out of an object -- a getter.
I think understand the point that you're trying to make; the idea that an object just accepts messages that alter it's internal state but otherwise keep it completely hidden is a pervasive one. Exposing internal state can lead to coupling or violate the single responsibility principle. But that model is too simple, plenty of objects are just containers. And not dumb containers that are just bundles of simple fields but smart containers with data that isn't entirely internal.
AutoValue with Builders is nice: Animal dog = Animal.builder() .setName("dog") .setNumberOfLegs(4) .build(); https://github.com/google/auto/blob/master/value/userguide/b...
Not that nice compared to kotlin: data class Animal(dog: String, numberOfLegs: Int) val dog = Animal( name = "dog", numberOfLegs = 4 ) The amount of boilerplate for AutoValue builders is so ridiculous that most people use IDE plugins to generate it.
(def dog #:animal{:name "dog" :number-of-legs 4})