Al final el motivo por el que tener un constructor y trabajar con referencias es tan popular es porque necesitas usar código de otras personas y testarlo.
El tema de tener cosas a bajo nivel privadas o no, tansolo es una decision de que carga cognitiva y nivel de control sobre tu librería ceder al usuario. cuanto mas control, mas eficiencia a cambio de tener mayor carga cognitiva.
A nivel de testeabilidad aqui ya depende de la implementación de cada lenguaje, pero en la practica si o si, en todos necesitas punteros para poder tener interficies o pasar funciones y por tanto tener mocks.
Si tu tienes estas funciones, da igual el estilo:
struct Thing {}
func (t Thing) useThing() { }
func useThing(t Thing) { }
solo le podrás pasar un Thing, y tu quizás quieres testear este código verdad? podemos dar un paso mas y hacer esto:
struct Thing {}
func (t *Thing) useThing() { }
func useThing(t *Thing) { }
cuando le pasas el puntero ya no necesitas un Thing, necesitas un puntero que no deja de ser una dirección a memoria para la funcion a nivel sintáctico, asique si tu le pasas un nil por tu cara bonita o una dirección de memoria cualquiera, eso ya funciona en un primer nivel. Ahi las famosas NULL POINTER EXCEPTION jeje y todo el problema de la NULLABILIDAD. En caso de ser un puntero valido, el problema lo tendras porque esa dirección, al dereferenciarse y tratar de acceder al método que necesites, no encontrara la funcion... asique es tarea del compilador realizar el escáner de que esto va a ir bien...
Y es la tarea del programador hacer sintaxis fáciles de interpretar y sistemas de tipado inteligentes para que el compilador tenga la mayor potencia posible. Y de la misma manera de los usuarios del compilador, el escribir código IDIOMATICO para que este funcione lo mejor posible y detecte fallos en comptime para ayudarnos y haga el mejor compilado posible.
Imaginemos que tenemos:
interface Thing {
func useThing()
{
struct Foo {}
func (f *Foo) useThing()
struct Bar {}
func (b *Bar) useThing{}
Ahora tanto Foo como Bar, implementan la interface Thing, (*Thing = Thing, es lo mismo, en interface no hace falta poner el * explicito) asique en el código que usa la interface, podemos usar ambos. A nivel sintáctico esto no es mas que punteros, y a nivel semántico, el compilador solo tiene que dereferenciar y mirar si estos struct tienen el método que requiere. Fácil.
func useThing(t Thing) {
t.useThing()
}
func main () {
useThing(Foo)
useThing(Bar)
{
Volviendo al principio, si trabajamos sobre structs a pelo, no podemos mockear de esta manera. Aunque existen maneras de hacerlo. Punto positivo si alguien me dice como testear sin interfaces ni punteros. PS q en Go se puede.
En conclusion, deberiamos escribir siempre el código mas eficiente posible, sobretodo cuando es una librería interna que es para nosotros mismos... cuando damos el paso de hacer algo publico, ahi ya podemos empezar a pensar en la usabilidad y carga cognitiva de nuestro código.
Y como conclusion final, tu lenguaje de mierda C#, Java, PHP es una mierda xq tiene un compilador de mierda hecho por fperos que no saben lo que es un puntero y asi os va anormales. Tenesi que poner Foo implements Thing xq vuestro de lenguaje de mierda no llega ni al nivel de Go, que mira que Go es una puta mierda... pues imaginaos.
