He tenido un colega que me dijo una vez trabajó para una empresa que tenía como una política de nunca tener condicionales («si» y «switch» (declaraciones) en el código y que permita que todas las decisiones en el código se pueden hacer usando polimorfismo y (supongo) algunos otros OO principios.

Me tipo de entender el razonamiento detrás de esto, de tener el código fuente que es más SECO y más fácil de actualizar, pero estoy en busca de una explicación más profunda de este concepto. O tal vez es parte de una más general, el enfoque de diseño.

Si alguien tiene los recursos para este o estaría dispuesto a explicar o incluso tienen algunos de los más términos relacionados con este puedo usar para encontrar más respuestas yo estaría muy agradecido.

He encontrado una pregunta sobre el MODO que era algo relacionado pero estoy familiarizado con C++ por lo que no entiende demasiado de las respuestas allí.

(Yo no soy OO gurú por cierto, pero que puede manejar)

Estoy más competentes en PHP, y después de que Python así que prefiero info que utiliza esos idiomas.

Actualización: le voy a pedir a mi colega para obtener más información sobre a qué se refería exactamente.

Actualización 2015: después de algunos años más de experiencia en programación ya veo que el objetivo de esta política fue probablemente para evitar que los programadores de la adición de la funcionalidad en forma aleatoria con sólo añadir condicionales (if) en ciertos lugares. Una mejor manera de ampliar el software es el uso de la «Abierto/Cerrado»el principio de, donde el software se extiende mediante la herencia y el polimorfismo. Estoy muy en duda si la política fue super estricta en todos los condicionales como es un poco difícil ir completamente sin ellos.

  • ¿Qué es esta empresa que su colega hablar de? Yo pregunte lo puedo evitar. Control de flujo declaraciones son fundamentales para la programación. Si ni siquiera puedo utilizar las herramientas más básicas cuando están adecuados para hacer el trabajo, ¿qué otra cosa puedo usar? Sí, es cierto que se puede abusar de if declaraciones, pero eso es cierto para todo lo demás.
  • silico – control de Flujo declaraciones son fundamentales para la procedimiento de programación. El polimorfismo es fundamental para la programación orientada a objetos. Dicho esto, la mayoría de nosotros usamos ambos paradigmas.
  • El control de flujo es fundamental para la programación imperativa y programación orientada a objetos es como mucho, basado en la programación imperativa como la programación procedimental. Incluso cuando te vayas «pura» de la programación orientada a objetos, usted todavía tiene la misma cosa envuelto en un paso más en la programación orientada a objetos-y vestido (condition ifTrue, como Smalltalk hace, que esencialmente tiene el mismo efecto y significado como if condition). Y usted tiene que utilizar algunos de control de flujo sobre el polimorfismo, a menos que quiera ajustar todo (tales como la uniformidad de un entero), dedicado a los objetos.
  • Buenos puntos.
  • posibles duplicados de se Puede escribir cualquier algoritmo sin una instrucción if?
  • Polimorfismo depende en gran medida de la sobrecarga, de modo que para idiomas como el js y php están condenados con este enfoque.

InformationsquelleAutor Niels Bom | 2011-08-31

6 Comentarios

  1. 56

    Hay algunos recursos en la Anti-SI la Campaña sitio, tales como este artículo.

    Creo que es una cuestión de grado. Los condicionales no siempre son malas, pero pueden ser (y frecuentemente son abusados.

    Pensamientos adicionales (un día después)

    Refactorización: Mejorar el Diseño de Código Existente es una buena referencia en esta materia (y muchos otros). Cubre Reemplazar Condicional con el Polimorfismo. También hay una nueva, Reemplazar Condicional con el Visitante, en el sitio web.

    Valoro la sencillez y la solo responsabilidad sobre la eliminación de todas las if declaraciones. Estos tres objetivos a menudo coinciden. Las herramientas de análisis estático que apoyan la ciclomático de complejidad métrica rápidamente puede señalar código con anidados o serie de condicionales. El if declaraciones pueden permanecer post-refactorización, pero podría ser roto en pequeños métodos y/o de varias clases.

    Actualización: Michael Plumas escribió un artículo sobre Incondicional De Programación.

    Este es un tema popular: Phil Haack en Muerte a la instrucción IF!

  2. 7

    He leído el post que enlaza y parece que ellos fueron sobre todo hablando de la eliminación de la necesidad de las oraciones condicionales dentro de una clase, que no debe confundirse con el código de todos en general. La idea es que si usted necesita para comprobar el estado de un objeto (con un condicional) para determinar si es cierta funcionalidad, a continuación, en la actualidad se tienen dos objetos (uno que admite la funcionalidad y uno que no lo hace) y debe definir como dos clases relacionadas en su lugar.

  3. 7

    He tenido un colega que me dijo una vez trabajó para una empresa que
    había como una política de nunca tener condicionales («si» y «cambio»
    declaraciones) en el código y que permita que todas las decisiones en el
    código realizarse utilizando polimorfismo y (supongo) algunos otros OO
    principios.

    Creo que su colega entendido algo o se utilizan mal las palabras para explicarlo.
    Y no se puede evitar completamente las instrucciones condicionales.

    Hay una cosa que decir: la proliferación de declaraciones y si dentro de la programación orientada a objetos puede ser un síntoma de la mala programación. Algunos ejemplo:

    No utilizar si para verificar el valor de retorno de la función como un viejo C-estilo de programación:

    int ret = some_func();
    if (ret != null)
       //do something
    

    Esto era típico en código C, pero con la programación orientada a objetos debe utilizar excepción:

    try{
        do_something();
    }catch(Exception e){
        e.printStackTrace(); //why I was not able to do something
        handle(e); //there is something else I could do to handle the occurred error
    }
    

    A veces si las declaraciones proliferación está relacionado con un mal diseño. Considere el siguiente ejemplo en Java:

    BaseClass base;
    if (base instanceof DerivedClassOneFromBase){
        DerivedClassOneFromBase d = (DerivedClassOneFromBase)base;
        d.methodOne();
    }else if (base instanceof DerivedClassOneFromBase){
        DerivedClassTwoFromBase d = (DerivedClassTwoFromBase)base;
        d.methodTwo();
    }
    

    Este es otro ejemplo de malas si las declaraciones, probablemente relacionado con un mal diseño. Si los dos derivados de objeto tiene un método común definidos en su clase base BaseClass, la que podría haber llamado a ese método, en lugar de comprobar su tipo concreto y fundición de ellos:

    base.commonMethod();
    
    • Estoy de acuerdo en que también ifs dentro de una aplicación es una mala symoton! Pero el uso de try catch como un flujo de estructura de decisión es aún peor, 1. se está utilizando si/demás de la misma manera 2. es DEMASIADO LENTO (auto experiencia!!!). ps; no estoy diciendo que el código de arriba es bueno o malo como su aislada de cualquier contexto.
    • como usted dice, es sobre el contexto. Microsoft recomienda el uso de excepciones para la presentación de informes de errores y fracasos, en oposición a los valores de retorno. Hay un capítulo sobre esto en Marco de las Directrices de Diseño.
    • Gama: sí Excepciones son ligeramente más lento, pero el punto es que son excepciones. Su no se supone que el flujo de control de la estructura de decisión, pero manejar errores ocasionales.
    • Como un menor de edad a un lado, las excepciones son ortogonales a la programación orientada a objetos, aunque no puedo pensar en cualquiera de los lenguajes de programación orientada a objetos que carecen de ella (además de Ir, que es sólo de tipo de OO.)
  4. 5

    A veces condicionales dentro de los métodos son malos, como son una señal de que usted se acaba de realizar varias funciones o varios tipos de métodos en el método.

    Si usted tiene una clase llamada de Automóviles y subclases, tales como la Bicicleta y el Automóvil, y un método, tales como:

    drive(Automobile a)
       if (a.isCar)
          //do stuff
       else if (a.isBike)
          //do stuff
    

    usted es la mayoría de likey haciendo algo mal. Incluso si no es un interruptor basado en el tipo, a menudo puede ser malo. Si el método es la realización de varias funciones dependiendo de algunas variables, es a menudo tratando de hacer más de una cosa y, probablemente, se debe dividir en varios métodos.

    Por ejemplo:

    save(Car c)
       if (c is new)
          //do some stuff
       else if (c is old)
          //do some stuff
    

    potencialmente podría ser dividido en guardar y actualizar, ya que son dos funciones diferentes. A pesar de que hace depender.

    De prohibición completa de declaraciones y si sería tonto, aunque como tienen muchos válido casos de uso.

  5. 0

    Evitar condicionales no necesariamente significa que usted necesita para lograr que se haga por polimorfismo o la herencia, por ejemplo, tomar :

    Tiene 3 diferentes carpetas para almacenar las imágenes, los vídeos que hayas subido y subido pdf

    Puede escribir código como :

    uploadMedia(mediaType){
       if(mediaType == images){
         uploadTo("myProject/images");
       }else if(mediaType == videos){
         upoloadTo("myProject/videos);  
       }else if(mediaType == pdf){
         uploadTo("myProject/pdf");
      }
    }
    

    Otra alternativa que se puede utilizar es el interruptor de caso :

    uploadMedia(mediaType){
             switch(mediaType){
             case : images
             uploadTo("myProject/images");
             break;
    
             case : videos
             uploadTo("myProject/videos");
             break;
    
             case : pdf
             uploadTo("myProject/pdf");
             break;
        }
    }
    

    Pero entonces usted puede evitar totalmente la instrucción condicional por el uso de algo como diccionario/hashmap/json (Dependiendo de lo que el trabajo con) :

    Por ejemplo :

    HashMap<String,String> mediaMap = new HashMap<>();
    
    mediaMap.put("images","myProject/images");
    mediaMap.put("videos","myProject/videos");
    mediaMap.put("pdf","myProject/pdf");
    
    //mediaType can be images/videos/pdf same as keys of mediaMap
    uploadMedia(mediaType){
      uploadTo(mediaMap.get(mediaType));
    }
    

    Esta es una especie de pseudo-código, por lo que puede haber errores de sintaxis, pero en general, este concepto también es útil para evitar las oraciones condicionales. También la línea de código puede ser reducido.

    • Interruptor de declaraciones son sólo en el caso de las declaraciones por escrito con otras palabras, también conocida como «azúcar sintáctico», por lo que no es realmente responder a mi pregunta. El hashmap es básicamente otra manera de escribir una instrucción switch. Si menos de programación (como yo lo entiendo) es más sobre cómo evitar los problemas que (muy probablemente) tendrá al uso de instrucciones if (mucho). Ellos tienden a multiplicarse y hacer que el código sea difícil de leer. Si utiliza el abierto/cerrado o principio de herencia que se le puede evitar que (y ganar otros problemas, por supuesto).
    • Yo no se que esta parte de tu comentario El hashmap es básicamente otra manera de escribir una instrucción switch. Pensé en él como una alternativa para cambiar de caso y en el caso de los demás, hacer el código más fácil de leer. También, realmente me ayudaría a entender si usted o tal vez alguien que esta leyendo esto podría decirme efecto en el rendimiento de la utilización de hashmap más de if/else o switch/case. Esto podría ayudar a entender los cuellos de botella de rendimiento. Gracias 🙂
    • Usted está en lo correcto, el uso de un hashmap es una alternativa para cambiar y if-else. Es una alternativa que a veces puede hacer que el código sea más fácil de leer. No es una alternativa si usted está buscando algo que no es un condicional. Es sólo escriben de forma diferente. Si quieres descubrir los efectos de rendimiento de una solución de programación más que otro, simplemente puede medir con temporizadores. Pero no vamos a ir en offtopic en este hilo 🙂
    • Gracias, tienes razón, no debería ir en off topic en este hilo 😅

Dejar respuesta

Please enter your comment!
Please enter your name here