• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Якісний інтерфейс класів.

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

Інтерфейс класу повинен являти собою групу методів, чітко узгоджених один з одним. Розглянемо приклад невдалої побудови інтерфейсу класу (на С++). Інтерфейс, який виражав би погану абстракцію, складався б з набору різнорідних методів.

class Program {

public:

// відкриті методи

void InitializeCommandStack();

void PushCommand( Command command );

Command PopCommandO;

void ShutdownCommandStackO;

void InitializeReportFormattingO;

void FormatReport( Report report );

void PrintReport( Report report );

void InitializeGlobalDataO;

void ShutdownGlobalData();

private:

...

};

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

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

Виражати в інтерфейсі класу узгоджений рівень абстракції. В ідеалі, кожен клас повинен бути реалізацією тільки одного абстрактного типу даних (АТД). Приклад класу, який має неузгоджений інтерфейс:

class EmployeeCensus: public ListContainer {

public:

//абстракція рівня Employee

void AddEmployee(Employee employee);

void RemoveEmployee(Employee employee);

//абстракція рівня List

Employee NextItemInList();

Employee FirstItem();

Employee LastItem();

private:

...

}

Даний клас виражає 2 АТД – Employee та ListContainer. Але чи потрібно, щоб інформація про використання контейнера була частиною абстракції? Зазвичай, це є деталлю реалізації. яку потрібно приховувати.

class EmployeeCensus {

public:

// Абстракція, що формується всіма цими методами, тепер відноситься до рівня Employee

void AddEmployee(Employee employee);

void RemoveEmployee(Employee employee);

Employee NextEmployee();

Employee FirstEmployee();

Employee LastEmployee();

private:

//Факт використання List прихований

ListContainer m_EmployeeList;

...

}

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

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

Надавати методи разом з протилежними до них методами, якщо потрібно. При проектуванні класу потрібно перевірити кожен відкритий метод на предмет того, чи потрібний протилежний йому.

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

Побоюватись порушення цілісності інтерфейсу при зміні класу.

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

Розглядати абстракцію і зв’язність разом. Поняття абстракції і зв’язності (cohesion) тісно пов’язані: інтерфейс класу, який представляє хорошу абстракцію, зазвичай має хорошу зв’язність. І навпаки, класи, що мають високу зв’язність, зазвичай представляють хорошу абстракцію, хоча даний зв’язок виражений слабше.

Читайте також:

1. Cisco Packet Tracer - Знайомство з програмою. Інтерфейс
2. WEB-документи та CGI-інтерфейси
3. Аналіз паралельного інтерфейсу з DSP-процесорами: читання даних з АЦП, що під’єднаний до адресного простору пам’яті
4. Аналіз послідовного інтерфейсу з DSP-процесорами
5. Багаторівневий підхід. Протокол. Інтерфейс. Стек протоколів.
6. Види аналізів: макроскопічниій, мікроскопічний, люмінесцентний, хімічний якісний та кількісний, гістохімічний, фітохімічний, фізико-хімічний, біологічний.
7. Визначення конфігурації мережевих інтерфейсів
8. Віконний інтерфейс
9. Віконний, графічний інтерфейс.
10. Внутрішні GSM - інтерфейси
11. Електричний інтерфейс RS-232C
12. Завдання профорієнтації учнів 5-9-х класів.

Переглядів: 862