Класи проти структур - stack overflow російською

У Сі ++ основна різниця між структурою і класом - це модифікатор доступу, який використовується за умовчанням для їх членів. Для класів, за замовчуванням використовується модифікатор private. а для структур - public. Звичайно, принципи інкапсуляції структури таким чином підривають. але класи, в свою чергу гальмують стадію проектування. яка зачіпає структурну еволюцію проекту.

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

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

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

відповідь дан 22 Березня '13 о 8:48

- Mutable structs are evil. Це ж твердження для C # в належній мірі відноситься і до non-legacy C ++, відповідно, має сенс прагнути при написанні коду до immutab'ельності типів даних. - Саме в вашому прикладі, ніщо не заважає користувачеві після створення об'єкта з розмірами картинки вручну змінити його значення ширини, що, в свою чергу призведе до рассинхронизации даних. Особливо, якщо код пише не Const Nazi розробник. - Costantino Rupert 22 Березня '13 в 8:43

Я говорив не про постійному зберіганні цих даних, а про тимчасове. Приклад: для відтворення мені необхідно знати її розміри, тоді набагато зручніше отримати їх структурою (констаннтной посиланням на неї), ніж отримувати двома окремими елементами. Знову ж таки, тут обговорюється сама концепція структур, а не їх конкретноу застосування. Хоча погоджуся, приклад не є ідеальним. - Dmitry Lepeshkin 22 Березня '13 в 8:54