Czy istnieje różnica między komponentem a modułem

Mam mały problem z modułem terminów i komponentem. Moim zdaniem moduł to klasy pakietowe, do których można uzyskać dostęp tylko poprzez dobrze zdefiniowany interfejs. Ukryją wszystkie szczegóły implementacji i są wielokrotnego użytku. Moduły definiują moduły, od których są zależne.

Jaka jest różnica w stosunku do komponentów? Sprawdziłem to w niektórych książkach, ale opis komponentów jest bardzo podobny.

Warunki są podobne. Ogólnie myślę, że „moduł” jest większy niż „komponent”. Składnik jest pojedynczą częścią, zwykle o stosunkowo niewielkim zakresie, być może ogólnego przeznaczenia. Przykłady obejmują elementy sterujące interfejsu użytkownika i „elementy tła”, takie jak liczniki czasu, asystenci wątków itp. „Moduł” to większy element całości, zwykle coś, co wykonuje złożoną podstawową funkcję bez zewnętrznych zakłóceń. Może to być biblioteka klas aplikacji zapewniająca integrację z pocztą e-mail lub bazą danych. Może być tak duży, jak pojedyncza aplikacja pakietu, na przykład „Moduł modułu rozrachunków z odbiorcami” platformy ERP / księgowej.

Uważam też, że „moduły” są bardziej wymienne. Komponenty można replikować, przy czym nowe wyglądają jak stare, ale są w pewien sposób „lepsze”, ale zazwyczaj konstrukcja systemu jest bardziej ściśle zależna od komponentu (lub zamiennika zaprojektowanego tak, aby był zgodny z bardzo specyficznym zachowaniem tego komponentu). W kategoriach nie komputerowych „komponent” może być blokiem silnika samochodu; możesz majstrować w silniku, a nawet całkowicie go wymienić, ale samochód musi mieć silnik i musi być zgodny z bardzo sztywnymi specyfikacjami, takimi jak wymiary, waga, punkty mocowania itp., aby zastąpić „zapasowy” silnik, którym jest samochód został pierwotnie zaprojektowany, aby mieć. Natomiast „moduł” implikuje funkcjonalność typu „plug-in”; czymkolwiek jest ten moduł, można go komunikować w tak lekki sposób, że moduł można wyjąć i / lub wymienić z minimalnym wpływem na inne części systemu. Układ elektryczny domu jest wysoce modułowy; możesz podłączyć wszystko za pomocą wtyczki 120V15A do dowolnego gniazda 120V15A i oczekiwać, że coś, co podłączasz, zadziała. Okablowanie domu nie mogło mniej obchodzić, co jest tam podłączone, pod warunkiem, że zapotrzebowanie na moc w dowolnej gałęzi systemu nie przekracza bezpiecznych limitów.

Ogólne znaczenie modułu to grupa kodu wielokrotnego użytku, niepowiązana z jednym konkretnym programem. Może to być wszystko, od całego zestawu bibliotek GUI do pojedynczej klasy.

Ogólnym znaczeniem komponentu jest moduł z dodatkowym ograniczeniem zastępowalności przy użyciu określonego interfejsu. Jeśli utworzysz komponent Widżetu GUI, możesz go używać wszędzie tam, gdzie oczekuje się Widżetu, bez konieczności wykonywania specjalnych czynności w kodzie wywołującym. Moduły ogólnie nie mają takich ograniczeń. Qt i GTK + to moduły, ale nie mogę zamienić jednego na drugi bez znacznej pracy przy wywoływaniu kodu, dlatego nie są komponentami.

Wiele frameworków lub języków programowania używa tych terminów, by oznaczać coś o wiele bardziej szczegółowego, dlatego ludzie pytają o kontekst. Coś może być komponentem w sensie ogólnym, ale jeśli nie implementuje bardzo konkretnego IComponentinterfejsu, nie może być uważane za komponent w kontekście. W Pythonie modulema bardzo specyficzne znaczenie techniczne, które można uzyskać za pomocą importpolecenia. Zwykle ludzie odnoszą się do tych kontekstowych znaczeń.

Jeśli mamy wyodrębnić poszczególne języki, frameworki i ich własne interpretacje, hierarchia szczegółowości oprogramowania abstrakcyjnego jest następująca:

Product - application, library, service
  Module - GUI, core logic, data, etc...
    Component - purpose specific collection of objects
      Object - collection of primitives
        Primitive - numbers, functions, etc...

• Produkt

Prosty i prosty produkt to działająca kolekcja połączonych modułów funkcjonalnych.

• Moduł

Jak sama nazwa wskazuje, motywacją modułu jest modułowość. Wbrew temu, co twierdzi wielu, tak naprawdę nie oznacza to ponownego użycia kodu. Istnieje wiele modułów, które nie nadają się do wielokrotnego użytku i nie pasują do niczego, do czego nie zostały zaprojektowane.

Ważne jest, aby oddzielić różne warstwy oprogramowania, dzięki czemu oprogramowanie jest znacznie łatwiejsze do wdrożenia i utrzymania, a jeśli zajdzie potrzeba zaimplementowania czegoś takiego jak interfejs do innej struktury GUI, modułowość umożliwia to w łatwy i bezpieczny sposób, bez zerwania kod w dowolnym miejscu.

Moduł zawiera zbiór komponentów, które służą wspólnemu celowi zdefiniowanemu w wymaganiach modułu. Moduł powinien być samowystarczalny i kompletny, i chociaż sam tak naprawdę nie nadaje się do użytku, powinien być w stanie współpracować z dowolną zgodną implementacją.

• Składnik

Pod względem ziarnistości komponent znajduje się między modułem a obiektem. Celem komponentu jest zebranie kolekcji obiektów ogólnego przeznaczenia w celu utworzenia jednostki określonej dla określonego celu.

Jak sama nazwa wskazuje, w przeciwieństwie do modułu, komponent nie jest „samodzielny”, jest częścią większej funkcjonalnej całości.

• Obiekt

Obiekty to mniejsze elementy składowe komponentów. Obiekty są kolekcjami prymitywów i łączą je ze sobą, aby służyć niższemu poziomowi, bardziej uniwersalnemu, a jednocześnie nieco bardziej specyficznemu celowi.

• Prymitywny

Prymitywy to najmniejszy, najprostszy i najniższy poziom szczegółowości programowania. Zasadniczo są to liczby całkowite i rzeczywiste oraz funkcje / operatory, chociaż większość języków ma swoich własnych „obywateli pierwszej klasy”.

Niewiele można zrobić z prymitywami, a jednocześnie jest na tak niskim poziomie, że można osiągnąć z nim praktycznie wszystko. Jest to po prostu bardzo, bardzo szczegółowe, niesamowicie skomplikowane i niemożliwie nużące do osiągnięcia podczas bezpośredniej pracy z prymitywami.

• Jaki jest sens tego wszystkiego?

Jak już wspomniano powyżej, bezpośrednia praca z prymitywami jest bardzo złym pomysłem. Nie tylko dlatego, że jest niemożliwie skomplikowany, powolny i żmudny w tworzeniu współczesnego oprogramowania, ale jest również niezwykle natarczywy i przeszkadza w testowaniu i konserwacji.

Włączenie wszystkich tych części pojęciowych do rozwoju oprogramowania sprawia, że ​​jest to łatwiejsze, szybsze, prostsze i bezpieczniejsze. Nie budujesz domu z atomów, niezależnie od tego, jak wszechstronne i uniwersalne są atomy. To byłoby ćwiczenie na próżno. Twoje atomy są twoimi prymitywami, glina jest twoim przedmiotem, cegły są twoimi komponentami, ściany, podłoga i dach to twoje moduły, połączone razem ukazują produkt końcowy.

Ludzie tak naprawdę niczego nie wymyślają, odkrywamy tylko rzeczy, które już istnieją we wszechświecie, a następnie kopiujemy i stosujemy je w naszym życiu. Ta sama hierarchia ziarnistości jest nieodłączna dla samego wszechświata, od atomów, a nawet poniżej, do cząsteczek organicznych, białek, tkanek, narządów, organizmów i wyżej, sama rzeczywistość przestrzega tej samej zasady - łącząc małe, proste, ograniczone funkcje i cel abstrakcyjnych rzeczy w większe, bardziej złożone, bardziej funkcjonalne rzeczy i rzeczy bardziej szczegółowe.

• Ostrzeżenia terminologiczne

Z technicznego punktu widzenia wszystkie są „obiektami”, wszystkie są „komponentami” rozwoju oprogramowania, wszystkie są na tyle „modułowe”, że można je ze sobą połączyć, wszystkie są „produktami” w tym sensie, że zostały wyprodukowane i tak dalej. ..

Tu nie chodzi o terminologię ani nomenklaturę, chodzi o to, jak skalowanie w górę i w dół wpływa na różne aspekty kreatywności i wydajności. I o tym, jak ważne jest nie tylko stosowanie tych wszystkich różnych poziomów, ale także o tym, jak ważne jest, aby nie próbować osiągnąć celu na niewłaściwym poziomie, co może przynieść efekt przeciwny do zamierzonego.

To zależy od twojego kontekstu. Moduł jest już używany w odniesieniu do grup poziomów DLL w niektórych językach, w innych przypadkach „pakiet” lub „asembler”. Komponent jest używany do tworzenia elementów COM, a także elementów opartych na elementach typowych dla tworzenia gier.

Ogólnie rzecz biorąc, zarówno moduł, jak i komponent zwykle odnoszą się do pewnego pakietu kodu za dobrze zdefiniowanym interfejsem. Zasadniczo moduł odnosi się do większych pakietów. Często istnieje zestaw interfejsów, a moduł może stać samodzielnie.

Z drugiej strony komponenty są zwykle mniejszymi pakietami kodu, często mniejszymi niż pełna klasa. Z nazwy mają tendencję do bycia częścią czegoś większego. Czasami jest to sama aplikacja, ale wraz ze wzrostem wykorzystania kompozycji w projektowaniu klasowym częściej oznacza ona element większego obiektu. Dobrze zdefiniowane interfejsy komponentów również pozwalają aplikacji na wzajemną wymianę komponentów. Moduły zwykle nie mają takiej możliwości wymiany.