Доступ до методів

Кожен метод має модифікатор доступу, що приймає одне з чотирьох значень: public, private, protected, internal. Модифікатором доступу за умовчанням є модифікатор private. Незалежно від значення модифікатора доступу, всі методи доступні для виклику при виконанні методу класу. Якщо методи мають модифікатор доступу private, можливо, опущений, то тоді вони доступні для виклику тільки всередині методів самого класу. Такі методи вважаються закритими. Зрозуміло, що клас, у якого всі методи закриті, абсурдний, оскільки ніхто не зміг би викликати жоден з його методів. Як правило, у класу є відкриті методи, що задають інтерфейс класу, і закриті методи. Інтерфейс - це лице класу, саме він визначає, чим клас цікавий своїм клієнтам, що він може робити, які сервіси надає клієнтам. Закриті методи складають важливу частину класу, дозволяючи клієнтам не вникати в деталі реалізації. Ці методи клієнтам класу недоступні, вони про них можуть нічого не знають, і, найголовніше, зміни в закритих методах ніяк не відображаються на клієнтах класу за умови коректної роботи відкритих методів.

Якщо деякі методи класу A повинні бути доступні для викликів у методах класу B, що є нащадком класу A, то такі методи слід забезпечити атрибутом protected. Якщо деякі методи повинні бути доступні тільки для методів класів B1, B2 і так далі, дружніх по відношенню до класу A, то такі методи слід забезпечити атрибутом internal, а всі дружні класи B помістити в один проект. Якщо деякі методи повинні бути доступні для методів будь-якого класу B, якому доступний сам клас A, то такі методи забезпечуються атрибутом public.

Тепер ми підійшли до поняття інкапсуляції. Інкапсуляцію найчастіше визначають як приховання даних. Об'єкти зазвичай не дозволяють доступ ззовні до своїх внутрішніх даних-членів (тобто для цих елементів указується рівень доступу захищений або закритий).

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

Той факт, що інкапсуляція дозволяє ховати інформацію від користувача, має наступні наслідки.

- Спрощується використання окремих об'єктів, оскільки користувач не вникає в подробиці способу їхньої реалізації.

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

- Внутрішні компоненти об'єкта невідомі іншим об'єктам - вони використовуються тільки цим об'єктом з метою реалізації функціональності, обумовленої його інтерфейсом.

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

Оскільки об'єкти є самодостатніми одиницями, імовірно, корисно було б мати методи, що обробляють специфічні ситуації створення і видалення об'єктів. Дійсно, такі спеціальні методи існують і називаються, відповідно, конструкторами (constructor) і деструкторами (destructor).

Дата добавления: 2015-08-18