Чи є різниця між компонентом і модулем

У мене є невелика проблема з модулем та компонентом термінів. На мій погляд, модуль - це класи, які доступні лише через чітко визначений інтерфейс. Вони приховують усі відомості про реалізацію та підлягають багаторазовому використанню. Модулі визначають модулі, від яких вони залежать.

Чим відрізняються компоненти? Я шукав це в деяких книгах, але опис компонентів дуже схожий.

Умови подібні. Я, як правило, вважаю, що "модуль" є більшим, ніж "компонент". Компонент - це окрема частина, як правило, порівняно невеликого за обсягом, можливо, загального призначення. Приклади включають в себе елементи керування інтерфейсом користувача та "фонові компоненти", такі як таймери, помічники різьблення тощо. "Модуль" - це більший фрагмент цілого, як правило, те, що виконує складну первинну функцію без зовнішніх втручань. Це може бути бібліотека класів програми, яка забезпечує інтеграцію з електронною поштою або базою даних. Він може бути таким же великим, як одноразове застосування набору, наприклад "модуль дебіторської заборгованості" платформи ERP / бухгалтерський облік.

Я також думаю, що "модулі" є більш взаємозамінними. Компоненти можна тиражувати, причому нові виглядають як старі, але в деякому роді є "кращими", але зазвичай конструкція системи суворіше залежить від компонента (або заміни, призначеної відповідно до дуже специфічної поведінки цього компонента). У некомп'ютерному плані "складовою частиною" може бути блок двигуна автомобіля; Ви можете повозитися в двигуні, навіть повністю замінити його, але автомобіль повинен мати двигун, і він повинен відповідати дуже жорстким специфікаціям, таким як габарити, вага, місця кріплення тощо, щоб замінити "запас" двигуна автомобілем спочатку був розроблений. "Модуль", з іншого боку, передбачає функціональність типу "плагін"; що б не був цей модуль, з нею можна зв’язуватися таким легким способом, що модуль можна буде зняти та / або замінити з мінімальним впливом на інші частини системи. Електрична система будинку є високомодульною; ви можете підключити що-небудь за допомогою штекера 120V15A до будь-якої ємності 120V15A і очікувати, що справа, яку ви підключаєте, працює. Проводка будинку не могла б перейматися тим, що підключено куди, за умови, що потреби в електроенергії в будь-якій одній гілці системи не перевищують безпечних меж.

Загальне значення модуля - це група багаторазового коду, не пов'язана з однією конкретною програмою. Це може бути все, від цілого набору бібліотек GUI до одного класу.

Загальне значення компонента - це модуль з додатковим обмеженням замінюваності за допомогою певного інтерфейсу. Якщо ви створюєте компонент GUI Widget, його можна використовувати будь-де, де очікується віджет, без необхідності робити щось особливе в коді виклику. Модулі взагалі не мають такого обмеження. Qt і GTK + - це модулі, але я не можу поміняти один на інший без значної роботи в коді, що називає його, тому вони не є компонентами.

Багато фреймворків або мов програмування використовують такі терміни, щоб означати щось набагато конкретніше, саме тому люди запитують про контекст. Щось може бути компонентом у загальному сенсі, але якщо воно не реалізує дуже специфічний IComponentінтерфейс, воно може не вважатися компонентом у контексті. У python moduleмає саме конкретне технічне значення того, що ви можете отримати за допомогою importкоманди. Зазвичай люди посилаються на ці контекстні значення.

Якщо ми хочемо абстрагуватися від певних мов, фреймворків та власних інтерпретацій, то ієрархія абстрактної програмної деталізації полягає в наступному:

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

• Товар

Простий і простий, Продукт - це робоча колекція підключених функціональних модулів.

• Модуль

Як випливає з самої назви, мотивація модуля - це модульність. На противагу тому, що багато хто стверджує, це насправді не передбачає повторного використання коду. Є багато модулів, які насправді не можуть бути використані повторно, і не підходять до того, що вони не були розроблені.

Важливо відокремити різні версії програмного забезпечення, що значно спрощує програмне забезпечення у впровадженні та технічному обслуговуванні, а у разі необхідності повторного втілення чимось на кшталт переднього кінця в інший графічний інтерфейс, модульність дозволяє легко і безпечно відбуватись, не порушуючи код у всьому місці.

Модуль включає в себе сукупність компонентів, які служать спільному призначенню, визначеному вимогами модуля. Модуль повинен бути автономним і повним, і хоча він не є дійсно корисним самостійно, він повинен мати можливість працювати в поєднанні з будь-якою відповідною реалізацією.

• Компонент

Що стосується деталізації, то Компонент знаходиться між Модулем та Об'єктом. Мета компонента - скласти колекцію об'єктів загального призначення, щоб сформувати цільову одиницю.

Як випливає з назви, на відміну від Модуля, Компонент не є "автономним", він є частиною більшого функціонального цілого.

• Об'єкт

Об'єктами є більш дрібні будівельні блоки компонентів. Об'єкти - це колекції примітивів і поєднуються їх разом, щоб служити нижчому рівню, більш універсальному, але все ще дещо конкретному призначенню.

• Примітивні

Примітиви - це найменший, найпростіший і найнижчий рівень деталізації розробки програмного забезпечення. Це в основному просто цілі та дійсні числа та функції / оператори, хоча більшість мов мають свої додаткові «першокласні громадяни».

З примітивами ви можете зробити дуже мало, і в той же час, це на такому низькому рівні, що ви можете виконати з ним практично все. Це просто дуже, дуже багатослівний, шалено складний і неможливо виснажливий під час прямої роботи з примітивами.

• Який сенс у всьому цьому?

Як вже було сказано вище, робота з примітивами безпосередньо - вкрай погана ідея. Не тільки тому, що це неможливо складно, повільно і нудно зробити для розробки сучасного програмного забезпечення, але це також надзвичайно нав’язливо і перешкоджає тестуванню та обслуговуванню.

Включення всіх цих концептуальних частин у розробку програмного забезпечення робить простішим, швидшим, простішим та безпечнішим. Ви не робите будинок з атомів, незалежно від того, наскільки універсальними і універсальними є атоми. Це було б вправою у марності. Ваші атоми - це ваші примітиви, глина - ваш предмет, цегла - ваші компоненти, стіни, підлога і дах - це ваші модулі, зібрані разом, вони виявляють кінцевий продукт.

Люди насправді нічого не вигадують, ми лише відкриваємо речі, які вже є у Всесвіті, а потім копіюємо та застосовуємо їх у нашому житті. Ця ж ієрархія зернистості є властивою самій Всесвіту, від атомів і навіть нижче, до органічних молекул, білків, тканин, органів, організмів і вище, сама реальність підпорядковується тому ж принципу - поєднуючи невеликі, прості, обмежені функції і цілі абстрактні речі в більші, складніші, більш функціональні речі та конкретніші речі.

• Застереження щодо термінології

Технічно вони всі "об'єкти", всі вони "компоненти" розробки програмного забезпечення, всі вони "модульні", щоб можна було поєднатись, вони всі "продукти" в тому сенсі, що вони були вироблені тощо. ..

Йдеться не про термінологію чи номенклатуру, це про те, як масштабування речей впливає на різні аспекти творчості та продуктивності. І про важливість не лише використання всіх цих різних рівнів, а й важливості не намагатися досягти мети на неправильному рівні, що може бути лише контрпродуктивним.

Це залежить від вашого контексту. Модуль вже використовується для позначення груп рівнів DLL на деяких мовах, подібних до 'пакет' або 'збирання' в інших. Компонент використовується для COM-речей, а також предметів, заснованих на об'єктах, що часто зустрічаються в розробці ігор.

У загальному випадку архітектура, модуль і компонент, як правило, посилаються на деякий пакет коду за чітко визначеним інтерфейсом. Взагалі модуль має тенденцію посилатися на більші пучки. Часто існує набір інтерфейсів, і модуль, як правило, може самостійно стояти.

Компоненти, з іншого боку, мають тенденцію бути меншими пакетами коду, часто меншими за повний клас. За своєю назвою вони, як правило, є складовою чогось більшого. Іноді це сама програма, але із збільшенням використання композиції в дизайні класу вона частіше означає компонент більшого об'єкта. Чітко визначений інтерфейс для компонентів також, як правило, дозволяє додатку міняти компоненти один для одного. Модулі, як правило, не мають такої заміни.