Let's say the site sells products on the site. We want to display products in 3 places: in the catalog, on the promo page and on the selling article page. We wrote 3 functions, and in each we made a request to the database:
A classic example of changes in business requirements - a manager comes to us and says: products are now divided into active (with the active = true flag) and inactive. Active products must be shown in the same 3 places, inactive - not shown anywhere.
Now we can assess whether our architecture is bad or good. We have only 3 functions for receiving goods, and in exactly 3 functions, we need to add a check for active = true. It turns out that the complexity of changes in our code is O (n), where n is the number of functions. There would be 5 functions: getProductsCatalog, getProductsByAction, getProductsByArticle, getRecommendedProducts, getMostViewedProducts - it would be necessary to make changes in 5 functions, but again the complexity of the code is only O (n).
If you add 1 level of abstraction, then you can reduce the number of necessary changes in the code to O (1)!
In this example, we have introduced 1 level of abstraction, and now it is necessary to make changes only in 1 place.
, , 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, .
In this article, I didn't bother with the name of the functions. I advise you to read the article on the naming of the P / A / HC / LC functions and the follow-up of that article from the Habr participant.