Чи слід завжди повністю інкапсулювати внутрішню структуру даних?

Врахуйте цей клас:

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThings(){
        return things;
    }

}

Цей клас виставляє масив, який він використовує для зберігання даних, будь-якому зацікавленому коду клієнта.

Я це робив у додатку, над яким працюю. У мене був ChordProgressionклас, який зберігає послідовність Chords (і робить деякі інші речі). Він мав Chord[] getChords()метод, який повертав масив акордів. Коли структуру даних довелося змінити (з масиву в ArrayList), весь код клієнта зламався.

Це змусило мене задуматися - можливо, наступний підхід краще:

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThing(int index){
        return things[index];
    }

    public int getDataSize(){
        return things.length;
    }

    public void setThing(int index, Thing thing){
        things[index] = thing;
    }

}

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

Коли структура даних змінюється, лише ці методи доводиться змінювати, але після їх виконання весь код клієнта все ще працює.

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

Чи підходить такий підхід? Що ти думаєш про це? Які недоліки у нього є інші? Чи доцільно змушує клас впроваджувати принаймні три загальнодоступні методи, щоб просто делегувати внутрішню структуру даних?

Код типу:

   public Thing[] getThings(){
        return things;
    }

Це не має особливого сенсу, оскільки ваш метод доступу не робить нічого, крім прямого повернення внутрішньої структури даних. Ви можете також просто заявити Thing[] thingsпро своє public. Ідея методу доступу полягає в створенні інтерфейсу, який захищає клієнтів від внутрішніх змін і не дозволяє їм маніпулювати фактичною структурою даних, за винятком дискретних способів, дозволених інтерфейсом. Як ви дізналися, коли зламався весь код вашого клієнта, ваш метод доступу цього не зробив - це просто марний код. Я думаю, що багато програмістів прагнуть писати подібний код, тому що вони десь дізналися, що все потрібно інкапсулювати методами доступу - але це з тих причин, які я пояснив. Робити це просто для "слідування за формою", коли метод доступу не виконує жодної мети - це лише шум.

Я б точно рекомендував запропоноване вам рішення, яке реалізує деякі найважливіші цілі інкапсуляції: надання клієнтам надійного, стриманого інтерфейсу, який ізолює їх від внутрішніх деталей реалізації вашого класу та не дозволяє їм торкатися внутрішньої структури даних. очікуйте способів, які ви вирішите прийнятними - "закон найменш необхідної пільги". Якщо ви подивитеся на великі популярні рамки OOP, такі як CLR, STL, VCL, запропонований вами шаблон є широко поширеним саме з цієї причини.

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

Єдиний недолік, який я бачу у вашій пропозиції, полягає в тому, що потрібно більше кодувати (і тепер вам доведеться перекодувати свої споживчі класи - але все одно ви повинні / повинні були це зробити.) Але це насправді не є недоліком - потрібно робити це правильно, а іноді це вимагає більше роботи.

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

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

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

Клас повинен мати одне чітке і стримане призначення і надати інтерфейс для підтримки цієї функціональності - не більше. Можливо, ви намагаєтесь зв’язати речі, які не належать один одному. Коли ви це зробите, все буде порушуватися щоразу, коли вам доведеться ввести зміни. Чим менші та більш дискретні ваші заняття, тим легше змінювати речі: Подумайте LEGO.

Ви запитували: Чи слід завжди цілком інкапсулювати внутрішню структуру даних?

Коротка відповідь: Так, більшість часу, але не завжди .

Довга відповідь: Я думаю, що класи поділяються на такі категорії:

1. Класи, які інкапсулюють прості дані. Приклад: 2D точка. Створювати загальнодоступні функції, які надають можливість отримувати / встановлювати координати X і Y, легко, але ви можете приховати внутрішні дані легко без особливих проблем. Для таких класів розкриття деталей внутрішньої структури даних не вимагається.

2. Класи контейнерів, які інкапсулюють колекції. STL має класичні контейнерні класи. Я вважаю std::stringі std::wstringсеред них теж. Вони забезпечують багатий інтерфейс для боротьби з абстракціями , але std::vector, std::stringі std::wstringтакож забезпечити можливість отримати доступ до необроблених даних. Я б не поспішав називати їх погано розробленими класами. Я не знаю виправдання для цих класів викриття їх необроблених даних. Однак у своїй роботі я вважав за необхідне викрити необроблені дані під час роботи з мільйонами сітчастих вузлів та даних про ці сітчасті вузли з міркувань продуктивності.

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

3. Заняття, що мають в основному функціональний характер. Приклади: std::istream, std::ostream, ітератори таких контейнерів STL. Дуже нерозумно розкривати внутрішні деталі цих класів.

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

На закінчення: Єдиний раз, коли я вважав за потрібне розкрити внутрішню структуру даних класу, це коли це стало вузьким місцем продуктивності.

Замість повернення необроблених даних безпосередньо, спробуйте щось подібне

class ClassA {
  private Things[] things;
  ...
  public Things[] asArray() { return things; }
  public List<Thing> asList() { ... }
  ...
}

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

class ClassA {
  private List<Thing> things;
  ...
  public Things[] asArray() { return things.asArray(); }
  public List<Thing> asList() { return things; }
  ...
}

Тепер у вас є відповідна інкапсуляція, приховати деталі реалізації та забезпечити зворотну сумісність (ціною).

Ви повинні використовувати інтерфейси для цих речей. Не допоможе у вашому випадку, оскільки масив Java не реалізує ці інтерфейси, але вам слід це робити з цього моменту:

class ClassA{

    public ClassA(){
        things = new ArrayList<Thing>();
    }

    private List<Thing> things; // stores data

    // stuff omitted

    public List<Thing> getThings(){
        return things;
    }

}

Таким чином ви можете змінитись ArrayListна LinkedListбудь-що інше, і ви не зламаєте жодного коду, оскільки всі колекції Java (крім масивів), які мають (псевдо?) Випадковий доступ, можливо, будуть реалізовані List.

Ви також можете використовувати Collection, які пропонують менше методів, ніж Listале можуть підтримувати колекції без випадкового доступу, або Iterableякі навіть можуть підтримувати потоки, але не пропонують багато в плані методів доступу ...

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