Hola, soy Luis y para hoy les traigo un artículo.
Índice
Un enfoque más consciente del diseño de software
Cuando los desarrolladores de software consideran cómo se ve un buen diseño de software cuando trabajan con lenguajes de programación de alto nivel, muchas mentes deambulan instintivamente hacia los principios rectores de la programación orientada a objetos (OOP).
La encapsulación, la abstracción, la herencia y el polimorfismo son cuatro principios muy importantes en el diseño de software que funcionan bien dentro del paradigma orientado a objetos. Al tiempo que proporcionan altos niveles de reutilización y mantenibilidad del código . Los méritos de la programación orientada a objetos son numerosos y están bien documentados.
Si bien no hay nada intrínsecamente malo en el diseño orientado a objetos, los desarrolladores pueden programarse en una caja porque se han limitado a las dimensiones de un mundo orientado a objetos.
El código que se modela bien desde una perspectiva orientada a objetos en realidad puede disfrazar el hecho de que el código no está resolviendo el problema en cuestión de una manera óptima, ignorando el propósito detrás de escribir el código en primer lugar.
Adoptar un enfoque centrado en cómo funciona realmente el código para transformar los datos del programa, un enfoque orientado a datos, puede ayudar a los programadores a evitar las trampas que el código orientado a objetos puede ocultar.
Introducción al diseño orientado a datos (DOD)
Cuando adoptamos un enfoque estrictamente orientado a objetos para escribir software, tendemos a perder de vista los objetivos subyacentes a nuestro código.
El código es una guía paso a paso a través de la cual los humanos pueden explicarle a un sistema informático en particular cómo resolver un problema dado de una manera eficiente.
Algunos problemas son obviamente más complicados que otros, pero casi todos los problemas resueltos por software se reducen a la manipulación de datos de una forma a otra.
El código es simplemente la herramienta que utilizan los programadores para resolver este problema de transformación de datos.
Para resolver este problema de la manera más óptima, los programadores deben comprender cómo afecta su código a la plataforma de hardware a la que se dirigen. Los programadores a menudo ignoran esta parte a favor de priorizar un paradigma orientado a objetos.
Los cachés permiten que una computadora aproveche la ubicación de los datos para aumentar en gran medida la eficiencia del acceso a la memoria; sin embargo, si el programador no escribe su programa teniendo en cuenta la localidad de los datos, se está perdiendo este impulso clave del rendimiento.
El diseño orientado a datos es la idea de escribir código para crear estructuras de datos optimizadas para un procesamiento eficiente en lugar de escribir código para estructurar datos alrededor de objetos del mundo real.
Esto significa que los datos y la funcionalidad están separados para que las funciones puedan actuar sobre los datos de una forma más general. Esto facilita la optimización del rendimiento mediante la utilización de la caché y la paralelización.
Diseño orientado a datos: ejemplo en C ++
(El código que escribí para este ejemplo está disponible aquí en Github. Tenga en cuenta que no está destinado a ser utilizado para nada más que para mostrar las diferencias entre los paradigmas de diseño de software )
Este ejemplo analiza dos implementaciones diferentes de un sistema de gestión de cartera de acciones simple en C ++
. El primer fragmento de código muestra una estructura de clases consistente con principios de diseño orientado a objetos.
El miembro de datos clave en esta clase es la cartera de acciones que consta de un vector de estructuras de posición de acciones.
Cada posición de acciones consta de un símbolo de acciones, el valor actual de una acción de esa acción, el número de acciones que se poseen y el costo promedio pagado por cada acción.
Modelar una cartera de acciones como una lista de modelos de posición de acciones es una forma muy intuitiva de estructurar este código.
Sin embargo, realizar cálculos en esta estructura de datos requiere recorrer la cartera de acciones y acceder al fragmento de memoria de 56 bytes
para cada posición de acciones, incluso cuando el cálculo solo necesita una pequeña información sobre cada posición de acciones.
Alternativamente, un diseño orientado a datos de un sistema de cartera de acciones podría verse así:
La diferencia clave en este ejemplo es que en lugar de utilizar un matriz de estructuras (AoS) como tuvimos en el primer ejemplo, esta clase usa un estructura de matrices (SoA) para almacenar todos los datos asociados con la cartera de acciones.
Esto nos permite realizar cálculos que iteran sobre matrices de miembros de datos más pequeños que pueden almacenarse en caché de manera más eficiente. Esto puede aumentar significativamente la velocidad de la aplicación en la que se utiliza esta clase.
Una implementación de métodos computacionales en el orientado a objetos la versión podría verse así:
Mientras tanto, una implementación de métodos computacionales en el orientado a datos la versión podría verse así:
Cuando el rendimiento total se calcula en una cartera de acciones que consta de 1500
posiciones de acciones, la implementación orientada a datos supera a la implementación orientada a objetos por un factor de 2
en promedio (GCC 7.5.0
; Ubuntu 18.04
de 64 bits
; g ++ -O2
).
Incluso para un fragmento de código tan pequeño, el cambio en la estructura del código resultó en un sistema significativamente más eficiente porque el hardware tenía un acceso más directo a los datos.
Con base en este ejemplo, es fácil ver cómo el código orientado a objetos escrito sin tener en cuenta el hardware subyacente puede resultar en un sistema inferior, incluso cuando la estructura del código parece razonable.
Sí, DOD
y OOP
pueden (y deben) coexistir
Se caracteriza por programar con un enfoque principal en la solución del problema de transformación de datos antes incluso de considerar el diseño de código.
Una vez que el programador ha decidido cómo debe interactuar el hardware con los datos, el código puede diseñarse en torno a estos datos.
A partir de aquí, el programador puede comenzar a analizar las compensaciones entre diferentes modelos orientados a objetos.
A menudo, es razonable (y preferible) sacrificar diferencias de rendimiento imperceptibles por una base de código más mantenible y / o reutilizable, pero el programador solo puede comprender el valor de esta compensación si comprende cómo afecta la relación entre el hardware y los datos.
Esto solo se puede hacer si el programador adopta un enfoque orientado a datos para escribir su código.
Conclusión
Al escribir código con lenguajes de programación de alto nivel, es fácil perderse en los niveles convenientes de abstracción que se nos brindan, y esto nos lleva a olvidar que nuestro código es responsable de decirle al hardware cómo transformar datos de una manera muy específica en un nivel inferior.
Una filosofía orientada a datos conduce a un código que es fundamentalmente sólido y obliga a los desarrolladores a comprender realmente lo que hace su lenguaje de programación bajo el capó.
Es posible que ser consciente del diseño orientado a datos no cambie radicalmente la forma en que escribe el código, pero tener una mejor comprensión de por qué es importante lo convertirá en un mejor desarrollador.
- Noel Llopis – «Diseño orientado a datos (o por qué podría estar disparándose en el pie con
OOP
)». - Richard Fabian – Libro de diseño orientado a datos (gratis, en línea, versión reducida).
-
CppCon 2014
: Mike Acton «Diseño orientado a datos yC ++
«. -
CppCon 2018
: Stoyan Nikolov «OOP
está muerto, diseño orientado a datos de larga duración». -
CppCon 2019
: Matt Godbolt «Path Tracing Three Ways: AStudy of C ++ Style
«.
¡Siéntete libre de sugerir cualquier recurso que deba agregar!
Gracias por leer este artículo.
Añadir comentario