Groovy !Encapsulation

I don’t know why I always kinda felt weird writing code in Groovy. Having avoided Java development for years, I liked how Grails/Groovy was easy to create something. What I learned later (when I learned Java Development and C++ Development) is that Groovy had some odd concepts, especially when it came to things like basic OOP.

Take Encapsulation for example. The idea that data should be private, unless specifically needed to be public is a classic OOP that’s taught in almost every language.

Groovy tricked me… and maybe that’s why I feel so jaded about the language. The trick is this:

class Car{

private color(){
    println("red")
    }
}

Car car = new Car()
car.color()  

That private method color should not be accessible. Groovy accepts the “private” syntax, but it doesn’t keep it private. This issue of not having real privacy goes back to 2009 when it was raised as a bug. That bug has never been resolved.

Instead it is a “feature.” The feature (as I understand it) is that Groovy sets all things private, but adds getters and setters under the hood so you can access it.

BUT THAT ISN’T PRIVATE

JavaScript also has a lack of encapsulation, but JavaScript has one redeeming aspect – They don’t trick you into thinking it is private, when it isn’t.

Saying it’s private but we put invisible getters and setters in there… is rather like saying, “look i put locks on all your doors, but i gave everyone in town a key to your house.”

Traits

I never really grasped the interest in Traits. A lot of Java dev’s I know hate Traits. But then I realized something. By adding Traits into Groovy, the language picked up a way to work around the Encapsulation issue.

trait Greeter {
    private String greetingMessage() {                      
        'Hello from a private method!'
    }
    String greet() {
        def m = greetingMessage()                           
        println m
        m
    }
}
class GreetingMachine implements Greeter {}                 
def g = new GreetingMachine()
assert g.greet() == "Hello from a private method!"          
try {
    assert g.greetingMessage()                              
} catch (MissingMethodException e) {
    println "greetingMessage is private in trait"
}

The above code is from the groovy language documents. It’s an example of privacy within the trait. The trait is accessed through an implementation. This implementation can not directly access the private fields or private methods.

But… Still there’s the old way

Still a dev team could feasible not know this, think they are making private methods… private fields, by using the private keyword. In fact I met a dev just today who thought that Groovy did lock things down with the private keyword.

Now imagine another dev on the same team, who starts directly calling private methods that they shouldn’t be accessing. Why would they do that?

Well imagine a large codebase, they open it up in JetBrains or some IDE… they instantiate some Class, and hit that “.” and up pops all the methods they can access…. Oh look, “.highScore” that sounds useful, let’s go bump the high score through this other method I’m writing in some other class. Without any logic of the instantiated class, the other dev has inadvertently bypassed some core functionality, to simply set call or set a value they shouldn’t be able to touch.

I don’t know… I just feel more discouraged about the language, the more I learn about OOP practices. Newer JVM languages like Kotlin and Scala are more syntactic to write, and they adhere to some core principals like Encapsulation.