Public Морозов

вместе с божественным объектом.

При каких обстоятельствах вы с этим сталкивались?

когда достигнуты пределы гибкости API приходится либо API допиливать, либо применять костыли.

Нельзя сказать, что это всегда плохо.

инкапсуляция же. зачем тогда вообще ооп использовать если можно сделать кучу глобальных переменных и не парится. только тогда устанешь везде и всё исправлять если придётся эти глобальные переменные как-то менять.

На самом деле это зависит от схемы разработки. Любой программист для начала ваяет moc в паблике, делает функционал, а уже потом формирует схему доступа. Если у тебя в продакшене есть паблики, которых ты не хотел, то ССЗБ.

класс, который по запросу выдаёт доступ ко всем, даже приватным, свойствам класса-родителя

Ну и да, через ревлекшн можно получит доступ ко всему, но что это делает на лоре?

Любой программист индус для начала ваяет moc в паблике, делает функционал, а уже потом формирует схему доступа.

Fixed.

По теме: такие жуткие костыли не нужны при грамотно продуманной архитектуре.

С другой стороны, всего не предусмотришь.

С другой стороны, всего не предусмотришь.

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

У нас вот вообще песня, а не софт: сначала наделали огороженных классов, а потом начали плодить френдов. И теперь у каждого класса у нас по 15 френдов. Посмотришь на такое, и паблик морозов начинает казаться идеальным архитектурным решением.

не сталкивался, ибо java, чаще попадаются классы-шлюхи у которых все унутренее состояние можно поюзать да и из другого потока.

Кстати о классах насколько обращение к полю в структуре быстрее обращения к свойству класса?

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

А что же за такая система?

на практике io тормозит настолько сильнее что оптимизации такого рода это херня.

Другое дело если у тебя действительно Задача с большой буквы, но там тебе профайлер подскажет что тормозит, а вот так вот заранее оптимизировать - маразм.

Использую для фиксов утечек памяти в одной из версий MFC (оно живое и шевелится!)

MFC

Я вероятно много чего не понял. Но чем обусловлен выбор именно MFC ?

класс, который по запросу выдаёт доступ ко всем, даже приватным, свойствам класса-родителя

Что эта ненаучная фантастика делает в devel?

это суровая реальность

Суровая реальность состоит в том, что к private имеет доступ только тот класс, где они объявлены. Если конечно мы говорим за default language.

ну мало ли, может он по смещению от this к приватным полям обращается

Копипаста из лурка:

/*
Чтобы получить доступ к private- или protected- членам класса, в C++ можно иногда увидеть паттерн «Паблик Морозов», открывающий доступ к защищенным данным и методам:
*/

#define private public
#define protected public
#include <header.h>
#undef private // А вот пока анонимус не дописал undef это и было грязным хаком.
#undef protected

// ...

Header *h = new Header();
int x = h->m_value; // m_value в прошлой жизни - private

//Более чистый способ — добавиться в «друзья» всех классов:

#define private friend class Descendant; private // приписываем friend class Descendant во все классы
#include <Ancestor.hpp>
#undef private

// ...

Descendant *h = new Descendant();
int x = h->m_value; // m_value в прошлой жизни - private из Ancestor

Ясное дело, что в этом контексте, они только философски приватные, примерно как private video.

#define private public

Гнать из профессии за такое.

Увы, иногда приходится разгребать такое говно после тех, кого выгнали.

Но чем обусловлен выбор именно MFC

Если бы я знал...

Это значит плохая архитектура. Не нужно к такому привыкать.

Ынтерпрайз что ли?

Ну почти. В духе «ты может свалишь, а нам твой проект поддерживать/доделывать».

Кстати да. В мелком ынтерпрайзе люди всегда хотят сделать что нибудь что бы стать незаменимыми. А всё из за того что никаких гарантий нет.

Иногда бывает и наоборот