LLD lub projekt niskiego poziomu to proces projektowania na poziomie komponentu, który następuje krok po kroku poprzez proces udoskonalania. Wejściem do LLD jest HLD.
Co to jest projekt niskiego poziomu lub LLDn
Ważne tematy dotyczące projektowania niskiego poziomu (LLD)
- Co to jest projektowanie niskiego poziomu (LLD)?
- Czym różni się LLD od HLD
- Jak utworzyć LLD z HLD?
- Mapa drogowa do projektowania niskopoziomowego
Co to jest projektowanie niskiego poziomu (LLD)?
LLD, czyli projektowanie niskiego poziomu, to faza procesu tworzenia oprogramowania, podczas której określane są szczegółowe komponenty systemu i ich interakcje. Polega na przekształceniu projektu wysokiego poziomu w bardziej szczegółowy plan uwzględniający określone algorytmy, struktury danych i interfejsy. LLD służy jako przewodnik dla programistów podczas kodowania, zapewniając dokładne i efektywne wdrożenie funkcjonalności systemu. LLD opisuje diagramy klas za pomocą metod i relacji pomiędzy klasami a specyfikacją programu.
Pamiętać: Projektowanie niskiego poziomu jest również znane jako projektowanie na poziomie obiektowym Lub poziom mikro Lub szczegółowe projektowanie .
Diagram klas w LLD
Na tym schemacie w zasadzie wymieniamy wszystkie elementy, które mogą być częścią komponentów. Diagramy klas powstają, gdy programistom łatwiej jest przekonwertować je na kod.
Na przykład:
User Service <-- User <--Profile <--ID>
Czym różni się LLD od HLD
Jak studiowano, Projekt wysokiego poziomu lub HLD to ogólny projekt systemu, w którym dokonujemy kompromisów między różnymi frameworkami, komponentami i różnymi bazami danych i wybieramy najlepszą, biorąc pod uwagę potrzeby biznesowe i sposób, w jaki system powinien działać, zarówno pod względem aspektów funkcjonalnych, jak i niefunkcjonalnych. Tutaj definiujemy komponenty i sposób, w jaki te komponenty będą się ze sobą komunikować. Dlatego tutaj zajmujemy się następującymi ogólnymi sprawami i nie przejmujemy się kodem.
- Wybór komponentów, platform i różnych narzędzi.
- Projekt bazy danych.
- Krótki opis relacji pomiędzy usługami i modułami.
Jak utworzyć LLD z HLD?
Jak zbadano powyżej, danymi wejściowymi do projektowania niskiego poziomu (LLD) jest HLD. Tutaj, w LLD, dbamy o to, jak będą wyglądać nasze komponenty, struktura posiadająca różne podmioty oraz to, w jaki sposób różne podmioty będą ponosić odpowiedzialność (wspierane operacje). Do tej konwersji używamy Diagramy ujednoliconego języka modelowania (UML). . Dodając do tych diagramów używamy Zasady OOPS I SOLIDNE zasady podczas projektowania. Dlatego też, korzystając z tych 3 paradygmatów, możemy przekonwertować dowolny HLD na LLD, aby można go było wdrożyć.
Mapa drogowa do projektowania niskopoziomowego
Aby połączyć koncepcje LLD z prawdziwym kodem, spróbujmy zrozumieć, jak zaprojektować dowolny diagram niskiego poziomu, wykonując następujące kroki:
1. Zasady obiektowe
Wymagania użytkownika są przetwarzane przy użyciu koncepcji programowania OOPS. Dlatego zaleca się, aby przed przystąpieniem do projektowania dowolnego systemu niskiego poziomu dobrze opanować koncepcje OOPS. Koncepcja programowania obiektowego 4 filary są niezbędne, aby rozpocząć naukę projektowania niskiego poziomu, a programista powinien być bardzo dobrze zaznajomiony z tymi 4 filarami, a mianowicie:
- Dziedzictwo
- kapsułkowanie
- wielopostaciowość
- abstrakcja
Jeśli chodzi o polimorfizm, powinniśmy jasno określić polimorfizm w czasie kompilacji i w czasie wykonywania. Programiści powinni mieć całkowitą jasność co do koncepcji OOPS w zakresie dogłębności aż do klas i obiektów, ponieważ OOPS jest podstawą, na której opiera się niskopoziomowość w dowolnym systemie. Projektowanie niskiego poziomu jest „wyjątkowo subiektywne”, ponieważ musimy optymalnie wykorzystać te koncepcje podczas kodowania, aby zbudować system niskiego poziomu poprzez implementację jednostek oprogramowania kodującego (klas, funkcji, modułów itp.)
przekonwertuj ciąg znaków na liczbę całkowitą Java
2. Proces analizy i projektowania
Jest to faza analizy, która jest naszym pierwszym krokiem, podczas którego przekształcamy problemy świata rzeczywistego w problemy świata obiektowego, korzystając z koncepcji OOPS i zasad SOLID.
3. Wzorce projektowe
Teraz implementacja naszego powyższego problemu obiektowego odbywa się za pomocą wzorców projektowych. Wzorce projektowe to rozwiązania typowych problemów napotykanych podczas projektowania oprogramowania, które można ponownie wykorzystać. Zapewniają ustrukturyzowane podejście do projektowania poprzez wychwytywanie najlepszych praktyk i sprawdzonych rozwiązań, ułatwiając tworzenie skalowalnego, łatwego w utrzymaniu i wydajnego oprogramowania. Wzorce projektowe pomagają usprawnić proces tworzenia oprogramowania, promować ponowne wykorzystanie kodu i poprawiać ogólną jakość systemów oprogramowania.
Każdy wzorzec opisuje problem, który pojawia się wielokrotnie w środowisku, a jego rozwiązania można stosować wielokrotnie bez redundancji.
Dlaczego potrzebne są wzorce projektowe?
Problemy te pojawiały się wielokrotnie, w związku z czym opracowywano te rozwiązania. Problemy te napotykają i rozwiązują doświadczeni projektanci w świecie programowania, a rozwiązania są niezawodne w czasie, oszczędzając dużo czasu i energii. Dlatego złożone i klasyczne problemy w świecie oprogramowania są rozwiązywane za pomocą wypróbowanych i przetestowanych rozwiązań.
Wskazówka: Zdecydowanie zaleca się dobre zrozumienie typowych wzorców projektowych, aby mieć dobrą kontrolę nad projektowaniem niskiego poziomu.
teoria drzew i grafów
Różne typy wzorców projektowych
Istnieje wiele typów wzorców projektowych. Omówmy 4 typy wzorców projektowych, które są szeroko stosowane na całym świecie:
- Fabryczny wzór projektowy
- Abstrakcyjny wzór fabryczny
- Wzór Singletona
- Wzór obserwatora
Zaleca się również przestudiowanie poniższych 5 wzorców projektowych, ponieważ są one mniej potrzebne, ale zaleca się naukę w celu podstawowego zrozumienia wzorców projektowych.
- Wzór budowniczego
- Wzór łańcucha odpowiedzialności
- Wzór adaptera
- Wzór fasady
- Wzór wagi muszej
4. Schemat UML-a
Są dwa typy diagramów UML:
- Strukturalny diagram UML: Tego typu diagramy zasadniczo definiują strukturę różnych bytów i obiektów oraz definiują relacje między nimi. Są pomocne w przedstawianiu wyglądu komponentów w odniesieniu do struktury.
- Diagram behawioralny UML: Tego typu diagramy zasadniczo definiują, jakie są różne operacje, które obsługuje. Tutaj inny behawioralny UML prezentuje różne zachowania
Wskazówka: Ważne diagramy UML często używane przez programistów są następujące:
- Schemat klas z Strukturalny diagram UML
- Sekwencja , Przypadek użycia I Działalność z behawioralnego diagramu UML.
5. SOLIDNE zasady
Są to zestawy 5 zasad (zasad), których należy ściśle przestrzegać zgodnie z wymaganiami systemu lub wymaganiami dotyczącymi optymalnego projektowania.
Aby napisać skalowalny, elastyczny, łatwy w utrzymaniu i nadający się do ponownego użycia kod:
- Zasada jednej odpowiedzialności (SRP)
- Zasada otwartego-zamkniętego (OCP)
- Zasada substytucji Liskova (LSP)
- Zasada segregacji interfejsu (ISP)
- Zasada inwersji zależności (DIP)
Należy pamiętać, że zasady SOLID to jedynie wytyczne, a nie rygorystyczne zasady, których należy przestrzegać. Kluczem jest znalezienie równowagi pomiędzy przestrzeganiem tych zasad a uwzględnieniem konkretnych potrzeb i ograniczeń wymagań biznesowych.