Debate sobre OOP

#2 Has hecho bien porque ha soltado en 10 minutos mas gilipolleces que las que se sueltan en este hilo.

#4 Es un video muy largo y me da pereza transcribirlo, pero si puede crear un debate interesante lo hago. Si no entiendes mi respuesta pregúntame por algo concreto. 4 puntos.

Ese video habla de como se hace la oop en java y los benficios que te puede aportar.
No habla de la oop en general.

Básicamente la oop es una manera de hacer cosas.
Pero puedes hacer las mismas cosas de otras maneras. No?
Las cosas que haces no definen la manera.

Habla de 4 principios, encapsulacion, abstraccion, herencia, polimorfismo
Estos 3: encapsulacion, abstraccion, polimorfismo. Los puedes tener sin OOP. (la reflection es un patron @Wei-Yu )
La herencia no estoy seguro de que significa la verdad, yo lo entiendo como algo muy característico de OO pero desconozco si se puede interpretar a nivel mas general.

Si en lugar de hacer ese video con ese tono, para mi pedante, te hubiese hecho el video hablando de como conseguir esos 4 principios en oop, (hacer algo de una manera) no me parecería una mierda. Sobretodo cuando lo ve tanta gente, 40k. Calidad pajeet de medium, no hace ningún favor a la comunidad.

Todo esto claro, es mi opinion. Sin entrar al contenido del video que ha soltado un par de perlas.

#6 Cuando habla de getters y setters por ejemplo. No se como estara el famoso debate pero si tienes una clase y la llenas de getters y setters para que coño has hecho la "clase"? No viola sus principios?

Luego la mutacion de estado. Utilizar OOP no te garantiza en ningun momento que no haya condiciones de carrera o que se haga un uso inadecuado de clases. Si ademas tienes setters estas exponiendo los campos a todo el modulo directamente xd.

El polimorfismo lo he comentado mil veces. Otros lenguajes tienen polimorfismo de otras formas y con otros pros/cons.

Luego creo dice que la encapsulacion te permite tener TDD. lol Tambien podia haber hablado un poco de DDD y soltar un par de siglas mas que quedan bien.

#8 Si tienes getters y setters estas exponiendo tus fields privados xd por tanto no te sirve para encapsular el codigo y controlar quien puede acceder a estos campos. Deberías entonces hablar a nivel de visibilidad de modulo / package para demostrar estos principios.

Aademas segun la oop si tienes un objeto animal que tiene una velocidad a la que camina, p.e,
no deberias tener un metodo setVelocity sino que deberias tener un metodo usando el lenguaje "Ubiquitous" y decir move()/run()/walk(), e internamente el metodo move te adaptara la velocidad.

Los getters/setters en los beans se usaba por temas de meta, lo he leido por la maniana en algun lado de hecho. Librerias que scanean tu codigo para gener objetos, spring, jackson/gson, beans...

Ademas se utilizan "hoy en día" para poder usarlos en los maps/filters y hacer programación declarativa.

list.stream().filter(Animal::isDuck).map(Animal::getName).collect()

Si haces oo bien, no deberían poder usar tus objetos mal, de ahi a la encapsulacion. Puedes tener getters que te devuelvan copias del estado, y setters que uses como datos. Pero la gente siempre lo hace mal.

La gente ha usado siempre POJOs en java, que no son más que structs y punto. Crud a db con hibernate y listo

#11 Ya bueno, pero si la gente no sabe usar mi código que se le va a hacer? En su día estuve dándole al tema... Te pongo este ejemplo basado en https://fsharpforfunandprofit.com/posts/13-ways-of-looking-at-a-turtle/ Cogi un objeto que tiene estado y lo alteraba, primero oop mutable, luego separe el estado y lo hice funcional, luego hice un "monad".

No se como lo harías tu o a si te refieres a algo diferente.

Pille Scala para probar porque es algo mas potente.. y se asemeja a java/kotlin. Quizas lo utilice muy mal xdd Asi se veria la api.

object ClientOOP {
  def main(args: Array[String]): Unit = {
    val p1 = new Pacman(1, 2, false)
    p1.enable()
    p1.move(2, 3)
  }
}

object ClientFUN {
  def main(args: Array[String]): Unit = {
    val pacmanService = new Pacman().Pacman
    val initial = pacmanService.create()
    val state = pacmanService.move(2, 3, initial)
    val state1 = pacmanService.enable(state)
    val state2 = pacmanService.move(-1, -1, state1)
    println(state2.toString)
  }
}

object ClientMON {
  def main(args: Array[String]): Unit = {

val initial = PacmanService.create()

// Esto lo podrias tener en otro lado
val enable: Pacman => PacmanState = pacman => PacmanService.enable(pacman)
val disable: Pacman => PacmanState = pacman => PacmanService.disable(pacman)
val move: (Int, Int) => Pacman => PacmanState = (dx, dy) => PacmanService.move(dx, dy)

val result = initial
  .bind(enable)
  .bind(move(1, 2))
  .bind(disable)
  .bind(move(3, 1))
  .bind(enable)
  .bind(move(3, 1))

print(result)

  }
}

Ya me jodería conocer la programación funcional gracias a Java.

#20 Los patrones de diseño solo son ruido en lenguajes pobremente diseñados. No voy a hacer más respecto a esto, y respecto a paradigmas de programación tampoco. Alguna cosa que he dicho en este hilo esta mal. Si quieres hablamos por MP.

moon, pony y julia pre 0.7