Cuando es la abstracción y modularización de una mala práctica de programación?

Question

acabo de ver este comentario en "¿qué JS lib hacer uso de" encuesta

"@Xanti - sí, sí, la modularización y la abstracción en la programación es una terrible práctica.Las funciones que llaman a otras funciones?Desperdiciar".

Y que me dejó curioso porque estoy usando Kohana framework para PHP y la librería Jquery de javascript.

¿Por qué algunas personas consideran que la abstracción y modularización de las malas prácticas?No son los marcos y las bibliotecas hecho de facilitar y acelerar el desarrollo?

he aquí una enlace la encuesta

Answer 1

He encontrado que el exceso de abstracción puede ser peligroso para tu productividad:

• Un mal elegido abstracción puede ser peor que ninguna abstracción en todo.

• Si usted necesita leer cuatro o cinco módulos diferentes con el fin de entender cómo un simple algoritmo funciona, la abstracción de las barreras probablemente no están en los lugares correctos.Tal vez hay una buena manera de refactorizar el código, o tal vez sería más fácil sólo para eliminar las barreras.

• Si la abstracción no corresponde a una relativamente familiarizados idea, puede ser difícil para los nuevos miembros del equipo para aprender.

La abstracción no es un "sin sentido bien";existe para servir a propósitos específicos.Entre los propósitos más comunes son

• A proteger los invariantes de una estructura de datos

• A encapsular las decisiones de diseño que se pueden cambiar

Mi mayor experiencia con la abstracción en el camino fue con nuestra investigación compilador para C--.Había una gran cantidad más de abstracción de los estudiantes estaban acostumbrados a ver en el compilador de clase:

• El objetivo de la máquina es abstracta
• El lenguaje ensamblador es abstracta
• Las convenciones de llamada eran abstractas
• La pila-marco de diseño de un inusual "bloquear" la abstracción

Cada una de estas abstracciones sirve un propósito importante para nuestra investigación, pero el efecto total fue de que se trataba muy difícil para los nuevos estudiantes a aprender el compilador.Por lo tanto, incluso si el comentario fue en tono de broma, no son lugares donde la abstracción puede causar problemas.

Answer 2

Cuando se trabaja sobre los recursos limitados, puede agregar fácilmente por encima.

seguro de que hay cosas compilador optimizarán distancia, pero si crea cuatro objetos ordenados en cuatro archivos .c aseado, ellos compilar a cuatro archivos .so ordenadas y luego vincularlos con un enlazador mudo, las llamadas de función del módulo transversal que podrían ser inline fácilmente todavía se hacen con volcado de estado completo, piezas que podrían ser optimizados desaparezca del todo todavía se ejecutan, y así sucesivamente.

les aseguro si se inicia la programación de un microcontrolador PIC de 8 bits con 4K RAM y 16K flash utilizando las mejores prácticas de lenguajes orientados a objetos, el uso de patrones de diseño avanzado y la creación de más de una capa de abstracción, su programa no se ejecutará. "La optimización prematura es la raíz de todo mal" fue dicho por un tipo que nunca ha programado para una plataforma que tiene 128 bytes de RAM.

Answer 3

Probablemente podemos asumir el comentarista no estaba hablando en serio.

No puedo imaginar a alguien reclamando la modularización y la abstracción son una mala práctica y en realidad lo que significa que.

Answer 4

La abstracción y la modularización, en general, son buenos y esencial. Es posible que haya malas abstracciones por ahí, por ejemplo: marcos que no son compatibles o más caro o simplemente no utilizable, o grande, o no actualizados, o la opción 2, etcétera. La biblioteca "mercado" en general es enorme. ¿Qué tipo de bibliotecas se encuentra usando depende de las circunstancias y preferencias personales.

  

¿Por qué algunas personas consideran que las prácticas de extracción y malas modularización? ¿No son los marcos y   bibliotecas hechas para facilitar y acelerar el desarrollo?

El cambio y el aprendizaje es a veces difícil - para que la gente luchar contra ella. Si te gusta estudiar este tipo, usted podría comenzar su investigación en: http://thedailywtf.com/ : - ) me gustaría simplemente ignorarlos y bibliotecas de uso y los marcos, ya que le sirven y hacen su vida programador mejor.

Answer 5

Un desarrollador afirmará que una abstracción o la modularización es una mala práctica cuando son capaces o requerido para interactuar con dicha abstracción o la modularización y son incapaces de entender su propósito o diseño.

Answer 6

Cuando todas las funciones (y funciones de ayuda) está en su propio módulo?

Answer 7

Era tranquilo Hace algún tiempo, pero un manual para un compilador FORTRAN recomienda elegir identificadores como cadenas de la misma longitud y las letras seleccionadas al azar.

Explicación? así se permite la distribución uniforme de los nombres en la tabla hash interno del compilador y debido a esto ofrece para la compilación más rápido.

Creo que el texto que está citando pertenece justo al lado de esta recomendación

Answer 8

Las buenas abstracciones a menudo se utilizan

Las buenas abstracciones se hace referencia a los 2 o más lugares en su software.

Ejemplos:

• Las funciones con sitios 2+ llamadas.
• clase abstracta con las clases 2+ concretas.
• Interfaces con 2+ implementaciones.
• Los genéricos con ejemplificaciones 2 +
• Bibliotecas con 2+ usuarios.
• etc.

Una abstracción que se hace referencia a los 2 o más lugares ayuda a reducir el tamaño del código, mediante la factorización a cabo las cosas comunes, y esto es una cosa buena.

Sin embargo, si usted tiene un montón de abstracciones que se hace referencia únicamente una sola vez, entonces hay una buena probabilidad de que la abstracción no es necesario.

Algunos ejemplos cuando abstracciones innecesarias vienen:

• código felices objeto de Escritura (interfaces y clases abstractas en todas partes que tiene solamente 1 aplicación o concreción). Estas interfaces y clases abstractas no son necesarios (en ese punto del desarrollo). YAGNI principio.
• Alguien construye un "nuevo y brillante" de la interfaz a la antigua, donde las nuevas funciones después de algún conversión sólo llamar a la interfaz de edad. Se puede imaginar lo que es un gran lío es el resultado, si se repite esto varias veces. En este caso, las funciones tendrán un solo sitio de llamadas, por lo que no son necesarios. Es necesario mover el código de las funciones en el nuevo o no escriba uno nuevo y modificar la anterior.

Algunos ejemplos de muy buenas abstracciones:

• capa de abstracción de hardware:. Proporciona una única interfaz para aplicaciones de modo que no es necesario para desarrollar código para cada tipo de hardware
• Sistema de archivos: No importa que utilice FAT, NTFS, EXT3 lo que sea. Se le permite a los archivos y directorios de uso, el controlador del sistema de archivos hace el resto.
idioma
• C: no es necesario transferir su programa para cada arquitectura de CPU. Sólo compilarlo.

Así que para responder a su pregunta pragmática: Las abstracciones son malos, cuando se hace referencia a partir de menos de 2 lugares

.

En cuanto a la modularización, su subjetiva: se puede organizar el código lo que quiera. Si el código fuente de la biblioteca se encuentra en un solo archivo fuente que no significa que sea peor que si se pone explotar varias cientos de archivos.

Cuando la calificación de sus abstracciones como bueno o malo, siempre tenga en cuenta el panorama general:. Todo el proyecto, toda la línea de productos, etc.