Коли слід використовувати приватний / внутрішній клас?

Щоб уточнити, про що я прошу

public class A{
    private/*or public*/ B b;
}

vs.

public class A{
    private/*or public*/ class B{
        ....
    }
}

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

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

Припустимо, ви будуєте дерево, список, графік тощо. Чому слід виставляти внутрішні деталі вузла чи комірки зовнішньому світу?

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

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

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

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

Наприклад, якщо вам потрібно прив’язати список даних, що складається з двох непов'язаних класів:

public class UiLayer
{
    public BindLists(List<A> as, List<B> bs)
    {
        var list = as.ZipWith(bs, (x, y) => new LayerListItem { AnA = x, AB = y});
        // do stuff with your new list.
    }

    private class LayerListItem
    {
        public A AnA;
        public B AB;
    }
}

Якщо ваш внутрішній клас використовується іншим класом, слід поставити його окремо. Якщо ваш внутрішній клас містить будь-яку логіку, слід поставити його окремо.

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

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

• Вкладені класи іншою мовою (наприклад, C ++) не мають такої прив'язки. Ви просто використовуєте контроль масштабування та доступності, який надає клас.

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

Одним із застосувань для приватного статичного внутрішнього класу є модель Memo. Ви поміщаєте всі дані, які потрібно запам’ятати, в приватний клас і повертаєте їх з якоїсь функції як Object. Ніхто ззовні не може (без роздумів, десеріалізації, перевірки пам’яті…) зазирнути в нього / змінити його, але він може повернути його до вашого класу, і він може відновити його стан.

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

// async_op.h -- someone else's api.
struct callback
{
    virtual ~callback(){}
    virtual void fire() = 0;
};

void do_my_async_op(callback *p);



// caller.cpp -- my api
class caller
{
private :
    struct caller_inner : callback
    {
        caller_inner(caller &self) : self_(self) {}
        void fire() { self_.do_callback(); }
        caller &self_;
    };

    void do_callback()
    {
        // Real callback
    }

    caller_inner inner_;

public :
    caller() : inner_(*this) {}

    void do_op()
    {
        do_my_async_op(&inner_);
    }
};

У цьому випадку do_my_async_op вимагає передавання йому об’єкта типу зворотного виклику. Цей зворотний дзвінок має підпис функції громадського члена, який використовує API.

Коли do_op () викликається з external_class, він використовує екземпляр приватного внутрішнього класу, який успадковує необхідний клас зворотного виклику замість вказівника на себе. Зовнішній клас має посилання на зовнішній клас для простої мети шунтування зворотного виклику в приватну функцію члена do_callback зовнішнього класу .

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

За словами Джона Скета в C # in Depth, використання вкладеного класу було єдиним способом реалізувати повністю ледачий безпечний для потоків синглтон (див. П'яту версію) (до .NET 4).

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

У C ++, крім приватного класу, тієї ж концепції можна досягти, реалізуючи анонімний простір імен класу cpp. Це добре допомагає приховати / приватизувати деталі реалізації.

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