Недоліки ооп

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

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

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

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

Багато хто вважає, що ООП є неефективним. Як же ж насправді? Ми повинні проводити чітку грань між неефективністю на етапі виконання, неефективністю у сенсі розподілу пам'яті і неефективністю, пов'язаної із зайвою універсалізацією.

1. Неефективність на етапі виконання. У мовах типу Smalltalk повідомлення інтерпретуються під час виконання програми шляхом здійснення їх пошуку в одній або кількох таблицях і за рахунок вибору відповідного методу. Звичайно, це повільний процес. І навіть при використанні найкращих методів оптимізації Smalltalk-програми в десять разів повільніше оптимізованих C-програм.У гібридних мовах типу Oberon-2, Object Pascal і C + + відправка повідомлення призводить лише до виклику через покажчик процедурної змінної. На деяких машинах повідомлення виконуються лише на 10% повільніше, ніж звичайні процедурні виклики. І оскільки повідомлення зустрічаються в програмі набагато рідше за інших операцій, їх вплив на час виконання впливу практично не робить.Однак існує інший фактор, який впливає на час виконання: інкапсуляція даних. Рекомендується не надавати прямий доступ до полів класу, а виконувати кожну операцію над даними через методи. Така схема приводить до необхідності виконання процедурного виклику кожен раз при доступі до даних. Однак якщо інкапсуляція використовується тільки там, де вона необхідна (тобто в тих випадках, коли це стає перевагою), то уповільнення цілком прийнятне.

2. Неефективність в сенсі розподілу пам'яті. Динамічне зв'язування і перевірка типу на етапі виконання вимагають по ходу роботи інформації про тип об'єкта. Така інформація зберігається в дескрипторі типу і він виділяється один на клас. Кожен об'єкт має невидимий покажчик на дескриптор типу для свого класу. Таким чином, в об'єктно-орієнтованих програмах необхідна додаткова пам'ять виявляється в одному покажчику для об'єкта і в одному дескрипторі типу для класу.

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

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

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

Лекція 12. Види відношень між класами, асоціація класів, наслідування.