якому випадку кожен модуль повинен вирішувати своє завдання і тільки її. p align="justify"> Потім з реалізацій маленьких завдань необхідно скласти рішення вихідної задачі. Цей процес називається композицією. Композиція - це фактично підйом по рівнях абстракції (збірка більш великих модулів з дрібніших). p align="justify"> Можна подумати, що процеси декомпозиції і композиції проходять окремо і рознесені в часі. Як правило, це не так. Всі завдання вирішуються поступово: виділяються підзадачі, вони вирішуються, інтегруються в систему, виділяються нові підзадачі ...
Повторне використання
У процесі виділення невеликих завдань часто з'ясовується, що деякі з них вже були вирішені: самим програмістом, іншим виробником ПЗ (постачальником бібліотеки) або розробниками стандартної бібліотеки мови. Іноді (особливо це стосується коду, написаного вашою командою) рішення потрібно злегка видозмінити (узагальнити), щоб його можна було використовувати повторно. p align="justify"> Повторне використання економить час на вирішенні тих же завдань, на розумінні стандартних рішень, на пошуку і виправлення помилок. Навіть якщо в повторно використовуваному коді знайшлася помилка, її потрібно виправити тільки один раз - і всі її прояви зникнуть. p align="justify"> Для ряду систем повторне використання може бути критерієм зовнішньої якості. Зазвичай це фактор внутрішній. Необхідно проектувати систему так, щоб всі її компоненти могли бути легко використані повторно. p align="justify"> Одне з найстрашніших зол - дублювання коду. І не тільки коду: дублювання ідей, проектних рішень, понять - все це шкодить загальній справі. p align="justify"> ООП дуже допомагає при повторному використанні коду: успадкування і поліморфізм - це дуже ефективні інструменти для вирішення таких завдань.
Інкапсуляція
Людина схильна бути неуважним до попереджень, написаним у коментарях: він просто їх не бачить. Якщо ж попередження немає, можна вважати, що помилка вже здійснена. Найцікавіше в тому, що автор того чи іншого класу часто сам норовить його неправильно використовувати. p align="justify"> Отже, всі модулі повинні вести себе так, щоб звести до мінімуму можливість здійснення помилки клієнтами. Це стосується як користувальницького інтерфейсу, так і API. p align="justify"> Є ідея: чим менше API, тим простіше його захистити. Давайте сховаємо від сторонніх очей все, що можна сховати. Шкода, але сховати все не вийде: треба дати можливість користуватися модулем. Звідси випливає важливий принцип: В«Все, що не є необхідним для користувача, має бути прихованеВ». p align="justify"> Все те, що користувачеві необхідно, повинно працювати так, щоб він не зміг допустити помилки. Причому, найкраще захищатися навіть від таких помилок, які ще не відомі. p align="justify"> Принцип приховування всіх деталей реалізації називається інкапсуляцією. Його можна ...
