Otra dudita de Java :D

Flashk #61 Abr '21

#60 Leete algún libro de patrones de diseño e informarte acerca de bajo acoplamiento y alta cohesión y luego, si quieres, seguimos hablando.

No es mejor código el que menos líneas de código tiene, sino aquel que más mantenible y adaptable a modificaciones es. El software no es algo que codificas y te olvidas, es algo que está en constante cambio, pero para poder hacer esos cambios, tienes que seguir unas pautas, porque si asignas a una clase la interfaz que no debes o la responsabilidad que no le corresponde, el día de mañana te será muy difícil hacer adaptaciones.

Patrones de diseño como el que te he intentado explicar, o principios como KISS, DRY o SOLID no están ahí porque si o porque lo diga yo, sino porque desarrolladores que han pasado antes que tú y que yo YA se han encontrado con esos mismos problemas antes y han establecido unas guías sobre la que trabajar para que no haya que reinventar la rueda en cada nuevo programa que se haga. Por supuesto que el mismo código se puede hacer con menos líneas, pero, ¿a qué coste?

1 respuesta

desu #62 Abr '21

#61 He leído bastantes libros sobre el tema. No me considero un experto en OOP ni Java tampoco. Siempre se aprende algo nuevo como bien dices... Sobre referencias no mantengo una lista actualizada pero tengo esta de hace unos a;os donde hay alguno sobre la temática que comentas:

2018 y 2019

Por favor, sigamos. Me parece un debate interesante el tema de jerarquías de objetos y que prepongas el uso de estos patrones de dise;o pre java 1.8 (anteriores al 2014) en el a;o 2021 con java ya casi 17. Te he preguntado:

Ahora vamos a poner ademas el caso mas variable de todos, las películas cambian de tipología y ademas el precio de una novedad depende de la pelicula o de un factor externo. Si el precio de RegularPrice cambia y este depende de la pelicula como lo modificas?

No veo como tu jerarquía se adaptara los cambios de requerimientos. Es obvio que si tenemos un cine el precio dependerá de la película o puede haber eventos especiales. O puede haber packs que reduzcan aplicando descuentos... etc. Como se adapta exactamente es código?

#61Flashk:
porque si asignas a una clase la interfaz que no debes o la responsabilidad que no le corresponde, el día de mañana te será muy difícil hacer adaptaciones.

Entonces porque tu solución inicial es construir una jerarquía e implementar interfaces? Por que no propones hacer la solución mas simple y sencilla y mas mantenible desde un principio y te ahorras los problemas que te ocasionara?

Si tu mismo dices que una abstracción incorrecta hace que sea muy difícil hacer adaptaciones no es contradictorio proponer solucionar un problema haciendo abstracciones con jerarquías de objetos y dynamic dispatch si después te costara mantenerlo? Sin entrar en que no conoces como este se implementa internamente ni lo que supone, podemos dejar de lado la eficiencia y el rendimiento. No es contradictorio decir que tienes tantísimos beneficios de poco acoplamiento y fácil de modificar pero después te pido un cambio trivial y dices que cuesta cambiar el cogido y no me lo pones?

1 respuesta

Flashk #63 Abr '21

#62 Es correcto lo de que mi jerarquía no se adaptaría a esos cambios, pero también es verdad que un ejemplo es un ejemplo; en concreto un ejemplo de como se implementa un Strategy básico para poder sustituir un switch-case. De hecho el ejemplo te lo he sacado directamente del libro de "Refactoring", y a lo largo del libro Fowler va introduciendo refactorizaciones adicionales.

Obviamente, lo que no voy a hacer es ir repasando todo el libro o pensando para rebatir cada pega que saques comentario tras comentario. Te lees el libro si quieres, y sacas tus conclusiones. Que ojo, está genial tener mente crítica, pero también lo está tener mente abierta.

¿Tu solución más simple es meter todo el código en una sola clase? Vale, hazlo como tú veas. Yo no estoy aquí para convencerte, estoy para dar mi visión del asunto. XD

1 respuesta

desu #64 Abr '21

#63 Te lo soluciono.


public class Main {

static class Movie {

    enum Type {
        New, Regular, Kids
    }

    public final Type type;

    public Movie(Type type) {
        this.type = type;
    }

}

public static void main(String[] args) {
    var regularMovie = new Movie(Movie.Type.Regular);
    var regularMoviePrice = computeMoviePrice(regularMovie);
    
    var newMovie = new Movie(Movie.Type.New);
    var newMoviePrice = computeMoviePrice(newMovie);
    
    System.out.println(computePrice(regularMoviePrice, 2));
    System.out.println(computePrice(newMoviePrice, 3));
}

public static int computePrice(int price, int days) {
    return price * days;
}

public static int computeMoviePrice(Movie movie) {
    return switch (movie.type) {
        case New ->  2;
        case Regular ->  3;
        case Kids ->  1;
    };
}

}

Pideme cambiar lo que quieras. Rebajas segun el dia? packs de multiples peliculas? A;adir mas tipologias de peliculas. Tener en cuenta multiple ocurrencias de un tipo para aplicar rebajas, contar que cada 7 dias se hace rebaja por ser finde. Usuarios con penalizaciones que deben pagar mas... Lo que quieras de verdad.

edit: para los pros, en mi solucion se que hay 1 cosa mal, soy consciente.

cabron #65 Abr '21 Judas

resumen:

"All problems in computer science can be solved by another level of indirection, ...except for the problem of too many layers of indirection."

1 respuesta

desu #66 Abr '21

#65 Hoy por la ma;ana he leído este:

Complex OO code is modern analog to unstructured "spaghetti code" of 1970.

https://talks.golang.org/2015/gophercon-goevolution.slide#18

Creo que es de Robert Griesemer, al menos la presentación es suya.

JuAn4k4 #67 Abr '21

Os estáis liando con el precio de las películas cuando el precio depende de la sala, la butaca, si has pillado o no las gafas 3d de plástico y si eres socio o no. Y no de la película.

1 respuesta

desu #68 Abr '21

#67 Tendriamos que tener la entidad Movie y la entidad MovieTicket. Que es mas o menos a lo que te refieres.

Si vas a hacer OOP al menos empieza con DDD porque hace obvios muchos problemas de acoplamiento en el namespace equivocado.

No se si es a lo que te refieres pero vamos, es lo que le iba a a;adir al siguiente refactor pero parece que el amigo OOP no quiere jugar conmigo XD

Usuarios habituales

Tags