Less Encapsulation With Object-Oriented Programming

A look at the apparent contradiction of following object-oriented principles leading to tight coupling.

Scott Meyers is a well known guy in the C++ developer community. He wrote a book called Effective C++, which is composed of items, which give specific advice on best practices in C++. Most of these I have forgotten and I no longer program in C++. Yet there is one item I believe has relevance to all object-oriented programming:

Effective C++ item 23: Prefer Non-member Non-friend Functions to Member Functions

In this story I want to talk about how this applies to my recent discussions of Java and Go programming. You see the Go standard library very much follows this advice while the Java standard library does not.

I want to try to demystify this advice because it will help explain why the Go code I showed in my previous story is so much shorter and easier to read than the Java code: Object-Oriented Coding: Java vs Go.

Let us take the example of io.Writer objects in Go, which can be compared to Java's OutputStream objects. It is defined like this:

type Writer interface {
        Write(p []byte) (n int, err error)
}