- Об'єктно-орієнтований * є дуже яскравою фразою. Називаючи щось об'єктно-орієнтованим, ви можете звучати дуже розумно. Ruby позиціонує себе як об'єктно-орієнтована мова сценаріїв, але що насправді означає "об'єктно-орієнтовану"?
Є безліч варіантів відповіді це питання, всі у тому числі, мабуть, зводяться одного й тому. Замість того, щоб швидко резюмувати відповідь, подумаємо трохи про традиційну парадигму програмування.
Традиційно проблема програмування піддається підходу з деякими видами представлення даних і процедур, які оперують цими даними. У даній моделі дані є інертними, пасивними та безпорадними. Вони сидять повністю у владі якогось великого процедурного тіла, яке активно, логічно та всемогутньо.
Проблема такого підходу полягає в тому, що такі програми пишуться програмістами, які лише люди і можуть зберігати досить ясно деталі у своїх головах до певного моменту. Поки що проект не стане великим, і його процедурне ядро не зросте до тієї точки, з якої пам'ятати про всі речі не стане важко. Незначні провали в пам'яті та типографічні помилки в результаті призводять до добре прихованих баг. Складні та непередбачені дії починають з'являтися в процедурному ядрі, і розробка його стає схожою на спробу перенесення гнівного кальмара так, щоб вона не могла доторкнутися до вашого обличчя. Є посібники з програмування, щоб допомогти мінімізувати та локалізувати баги традиційної парадигми, але є найкраще рішення, яке включає фундаментальні зміни, з якими ми працюємо.
Що дає об'єктно-орієнтоване програмування? Воно дозволяє нам делегувати більшу частину моторної та повторюваної роботи в самі дані. Це змінює концепцію даних із пасивних до активних. Перефразуємо:
- Ми припиняємо обробку кожної частини даних як відкриту коробку, з якої ми дістаємо якісь речі і поміщаємо в неї якісь речі.
- Ми починаємо працювати з кожною частиною даних як робоча машина, яка закрита і має ряд перемикачів і циферблатів.
Те, що описано вище як машина, може бути дуже простим зовні і складним усередині; Ми не можемо сказати про неї щось зовні, і ми не дозволяємо собі відкрити цю машину (за винятком тих випадків, коли впевнені в тому, що всередині щось не так), тому ми повинні робити лише ті речі, які дозволяють робити перемикачі та циферблати, щоб взаємодіяти з даними. Після того як ця машина побудована, ми вже не хочемо думати про те, як вона працює всередині.
Ми можемо думати, що просто робимо більше роботи для себе, але це має тенденцію хорошої роботи щодо запобігання всім видам помилкових явищ.
Давайте почнемо з прикладу, який є надто простим, щоб бути практичним, але який повинен ілюструвати принаймні частину концепції. Ваш автомобіль має лічильник шляху. Його робота полягає у збереженні дистанції шляху пройденого машиною з останнього разу його обнулення. Як би ми його написали мовою програмування? C лічильник шляху буде просто числової змінної, можливо типу float . Програма керуватиме змінною поступово збільшуючи значення, з випадковим поверненням до нуля при необхідності. Що тут не таке? Баг у програмі може статися при присвоєнні змінної помилкового значення, при безлічі причин. Кожен, хто програмував на C, знає, що таке витратити кілька годин або днів на пошук такого бага, який знайдений, виявляється до абсурду простим. (Момент знаходження цієї помилки зазвичай позначається звук гучною бавовною по лобі)
Така сама проблема розглядатиметься під іншим кутом зору в объектно-ориентированном підході. Перша річ, про яку програміст запитує, коли розробляє лічильник шляху, це не "який тип даних найбільше підходить для опису даної речі?", а "як саме повинна працювати дана річ?". Відмінність тут досить велика. Потрібно витратити трохи більше часу, вирішуючи як саме лічильник шляху повинен взаємодіяти із зовнішнім світом. Ми вирішили спроектувати маленьку машину з керуванням, що дозволяє збільшувати лічильник, скидати його, зчитувати його значення та нічого більше.
Ми не надаємо способів надання довільного значення лічильник. Чому? Тому що ми знаємо, що лічильник не повинен так працювати. Є лише кілька речей, які ви можете зробити з лічильником, вони дозволені. Таким чином, якщо щось ще у програмі помилково спробує помістити інше значення (скажімо, температура клімат контролю в автомобілі) та лічильник, це негайно скаже нам про те, що щось пішло не так. На кажуть, що при виконанні програми (або можливо під час компіляції, залежно від природи мови) нам не дозволяється надати значення об'єкту лічильника шляху. Повідомлення не може бути точним, але цього достатньо, щоб зрозуміти помилку. Чи не так? Але це швидко вказує нам у бік причини збою. Це лише один із кількох способів, які в об'єктно-орієнтованому програмуванні можуть заощадити час.
Ми зазвичай беремо один крок абстракції в цьому випадку, тому що легко побудувати завод, який виробляє машини, які роблять машини з індивідуальним дизайном. Ми не можемо створити один таймер для всього, але можемо створити велику кількість таймерів з одного шаблону. Шаблон (або якщо вам подобається, фабрика лічильників) відповідає тому, що ми називаємо класом, а індивідуальний лічильник створюється з цього шаблону (або створюється фабрикою) відповідає об'єкту. Більшість об'єктно-орієнтованих мов вимагає, щоб клас був визначений до того, як буде створено об'єкт, але Ruby так не робить.
Варто зазначити, що використання об'єктно-орієнтованої мови означає дотримання правильного ООП дизайну. Дійсно, будь-якою мовою можна написати код, який буде брудним, неакуратним, неясним, забагованним і хитким у всьому. Що робить Ruby для Вас (на противагу, особливо, C++). Він робить практику об'єктно-орієнтованого програмування природним за відчуттями, навіть коли ви працюєте в малому масштабі. Ви не відчуваєте необхідність вдаватися до потворного коду, щоб заощадити зусилля. Ми обговорюватимемо способи, у яких Ruby виконує цю чудову мету в процесі вивчення даного керівництва. У наступному розділі будуть "перемикачі та циферблати" (методи об'єктів) і від них ми перейдемо до "фабрик" (класів). Ви ще з нами?
