Digamos que el sitio vende productos en el sitio. Queremos mostrar productos en 3 lugares: en el catálogo, en la página de promoción y en la página del artículo de venta. Escribimos 3 funciones, y en cada una hicimos una solicitud a la base de datos:
Un ejemplo clásico de cambios en los requisitos comerciales: un gerente se nos acerca y nos dice: los productos ahora se dividen en activos (con el indicador activo = verdadero) e inactivos. Los productos activos deben mostrarse en los mismos 3 lugares, inactivos, no mostrados en ninguna parte.
Ahora podemos evaluar si nuestra arquitectura es buena o mala. Tenemos solo 3 funciones para recibir mercancías, y en exactamente 3 funciones, necesitamos agregar una marca para active = true. Resulta que la complejidad de los cambios en nuestro código es O (n), donde n es el número de funciones. Habría 5 funciones: getProductsCatalog, getProductsByAction, getProductsByArticle, getRecommendedProducts, getMostViewedProducts; sería necesario realizar cambios en 5 funciones, pero nuevamente la complejidad del código es solo O (n).
Si agrega 1 nivel de abstracción, ¡entonces puede reducir el número de cambios necesarios en el código a O (1)!
En este ejemplo, hemos introducido 1 nivel de abstracción y ahora es necesario realizar cambios solo en 1 lugar.
, , front , . :
- front , O(1). - O(n) - .. , , . - 1 . front , O(1+n) - 1 - , n - . , O(n+m), n - , m - .
O(1+n) O(1) 1 , 2.
:
O(n^2) - . 2 , 1 , , .
O(n) - . .
O(n+m) - , O(n), 1 , 2 n 1 m 2 .
O(1) - , .
O(0) - CMS . .
:
O, .
En este artículo, no me molesté con el nombre de las funciones. Les aconsejo que lean el artículo sobre la denominación de las funciones P / A / HC / LC y el seguimiento de ese artículo del participante de Habr.