Der Schwierigkeitsgrad von Codeänderungen mit O ist groß

Angenommen, die Website verkauft Produkte auf der Website. Wir möchten Produkte an drei Stellen anzeigen: im Katalog, auf der Promo-Seite und auf der Verkaufsartikelseite. Wir haben 3 Funktionen geschrieben und in jeder eine Anfrage an die Datenbank gestellt:





Ein klassisches Beispiel für Änderungen der Geschäftsanforderungen - ein Manager kommt zu uns und sagt: Produkte werden jetzt in aktiv (mit dem Flag active = true) und inaktiv unterteilt. Aktive Produkte müssen an denselben drei Stellen angezeigt werden, inaktiv - nirgendwo angezeigt.





Jetzt können wir beurteilen, ob unsere Architektur schlecht oder gut ist. Wir haben nur 3 Funktionen für den Wareneingang und in genau 3 Funktionen müssen wir eine Prüfung für active = true hinzufügen. Es stellt sich heraus, dass die Komplexität der Änderungen in unserem Code O (n) ist, wobei n die Anzahl der Funktionen ist. Es würde 5 Funktionen geben: getProductsCatalog, getProductsByAction, getProductsByArticle, getRecommendedProducts, getMostViewedProducts - es wäre notwendig, Änderungen in 5 Funktionen vorzunehmen, aber auch hier ist die Komplexität des Codes nur O (n).





Wenn Sie 1 Abstraktionsebene hinzufügen, können Sie die Anzahl der erforderlichen Änderungen im Code auf O (1) reduzieren!





In diesem Beispiel haben wir eine Abstraktionsebene eingeführt, und jetzt müssen Änderungen nur an einer Stelle vorgenommen werden.





, , 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 diesem Artikel habe ich mich nicht mit dem Namen der Funktionen beschäftigt. Ich empfehle Ihnen, den Artikel über die Benennung der P / A / HC / LC-Funktionen und die Weiterverfolgung dieses Artikels durch den Habr-Teilnehmer zu lesen.








All Articles