A pontuação de dificuldade das mudanças de código com O é grande

Digamos que o site venda produtos no site. Queremos apresentar os produtos em 3 locais: no catálogo, na página promocional e na página do artigo de venda. Escrevemos 3 funções e em cada uma fizemos uma solicitação ao banco de dados:





Um exemplo clássico de mudanças nos requisitos de negócios - um gerente chega até nós e diz: os produtos agora são divididos em ativos (com o sinalizador ativo = verdadeiro) e inativos. Os produtos ativos devem ser mostrados nos mesmos 3 lugares, inativos - não mostrados em nenhum lugar.





Agora podemos avaliar se nossa arquitetura é boa ou ruim. Temos apenas 3 funções para receber mercadorias e, em exatamente 3 funções, precisamos adicionar um cheque para ativo = verdadeiro. Acontece que a complexidade das mudanças em nosso código é O (n), onde n é o número de funções. Haveria 5 funções: getProductsCatalog, getProductsByAction, getProductsByArticle, getRecommendedProducts, getMostViewedProducts - seria necessário fazer alterações em 5 funções, mas novamente a complexidade do código é apenas O (n).





Se você adicionar 1 nível de abstração, poderá reduzir o número de alterações necessárias no código para O (1)!





Neste exemplo, introduzimos 1 nível de abstração e agora é necessário fazer alterações apenas em 1 local.





, , 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, .





Neste artigo, não me preocupei com o nome das funções. Aconselho você a ler o artigo sobre a nomenclatura das funções P / A / HC / LC e o acompanhamento desse artigo do participante do Habr.








All Articles