Page 36 - 4836

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

34