Предыстория.

Представьте себе приложение на C++ с такой архитектурой,
есть главный класс Application, он содержит в себе объекты
остальных классов, при старте программы, инициализируется глобальный
указатель на объект главного класса, и в любой момент когда кому-то что-то нужно,
он, используя указатель на класс Application, добирается до любого нужного
ему объекта (почти все члены-данных объявлены как public).

Это пораждает массу проблем,
1)Каждый знает о каждом: изменение в одном месте требует перекомпиляции всей программы
2)Невозможно протестировать ничего отдельно
3)Много чего сделано public, для облегчения такого метода работы,
и соответственно абсолютно не ясны "контракты классов", ты что-то изменяешь,
и вуаля, вылезает через какое-то время ошибка.
4)Мне не нравиться это поддерживать

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

Я предложил постепенно изменить очевидные вещи, ну например:
есть GUI компонент основная задача которого вызывать Application->MethodX(),
все ему больше ничего не нужно знать ни об Application, ни о других классах,

я хочу отделить его использую boost signals/slots от остального приложения,
и так постепенно поступить со всеми простыми классами, общающимися
с Application, посредством вызова его двух, трех методов, а больше никак
не взаимодействующих с другими компонентами программы.

Сама история.

По почте произошел такой диалог:
— Я хочу для отделения классов друг от друга использовать boost signals
— Зачему это нужно и как это будет выглядеть?
— То как сделано это сейчас это известный анти-паттерн ООП и решение тоже давно известно,
вот патч показывающий как это будет выглядеть.
— Нет, мне это не нравиться, во-первых нужна отдельная библиотека для этого, во-вторых
мы знаем что мы будем вызывать на этапе компиляции, зачем нам это делать в runtime,
в-третьих мы можем сделать это проще использую static функции и callback аргумент,
но зачем, ради какого-то ООП паттерна, я так не думаю.

Чтобы вы сделали для объяснения своей правоты в данном вопросе,
или может я не прав?

Объяснения простые:
ООП и паттерны для того и предназначены, чтобы последующая модификация и поддержка приложения были проще, и было меньше ошибок.
Если у вас уже есть некоторые затруднения с поддержкой и изменением приложения, значит есть какие-то недочеты в архитектуре, и надо приводить ее в порядок.
Так что я думаю вы правы
А подскажите пожалуйста где можно почитать про boost signals подробнее???

Ну, мотивация "это антипаттерн" действительно не очень убедительна.
Кому — паттерн, кому — антипаттерн, тут дело такое

А вот конкретно продемонстрировать практический недостаток существующей архитектуры — надо постараться.
Выпиши конкретные ситуации, проблемы, которые возникали, объяснения их причин.
Может тогда и удастся прийти (привести?) к тому, что все-таки нужно как-то иначе делать.

Другой вопрос — как именно иначе, но это уже потом.

Здравствуйте, es3000, Вы писали:

E>Объяснения простые:
E>ООП и паттерны для того и предназначены, чтобы последующая модификация и поддержка приложения были проще, и было меньше ошибок.
E>Если у вас уже есть некоторые затруднения с поддержкой и изменением приложения, значит есть какие-то недочеты в архитектуре, и надо приводить ее в порядок.

На данный вопрос есть другая точка зрения,
подобные ошибки следствие того что я не все тщательно и регулярно тестировал,
а тот факт, что после изменения одной части программы (по сути полностью отдельной части),
приходится тестировать всю программу и делать это ручками, т.к. функциональные и юнит тесты
не напишешь при такой архитектуре конечно не учитывается.

E>Так что я думаю вы правы
E>А подскажите пожалуйста где можно почитать про boost signals подробнее???
здесь

А я честно говоря не понял фатальности недостатков ООП архитектуры. Вон, обьектная модель того же ворда или экселя примерно так и устроена — и живёт и здравствует. Может, стоит просто яснее выделить интерфейс между модулями (к примеру, прописать его в IDL или в виде чисто абстрактных классов)?

Здравствуйте, Left2, Вы писали:

L>А я честно говоря не понял фатальности недостатков ООП архитектуры.

То, что описано в первоначальном месадже не ООП, а свалка...

L> Может, стоит просто яснее выделить интерфейс между модулями (к примеру, прописать его в IDL или в виде чисто абстрактных классов)?

То есть сделать нормальное ООП.
Инкапсуляцию и абстрактные классы собственно для решения подобных проблем и придумывали...

Здравствуйте, Igor Trofimov, Вы писали:

iT>Ну, мотивация "это антипаттерн" действительно не очень убедительна.
iT>Кому — паттерн, кому — антипаттерн, тут дело такое

Да, это было действительно моей ошибкой, я предполагал,
что мы оба читали книжки про ООП и говорим на одном языке.

iT>А вот конкретно продемонстрировать практический недостаток существующей архитектуры — надо постараться.
iT>Выпиши конкретные ситуации, проблемы, которые возникали, объяснения их причин.

Ну я предложил одно из описаний, оно выглядело примено так,
есть класс Icon, он отображает себя в виде иконки на панеле задач Desktop Envrioment,
и если окно приложения свернуто, можно двойным щелчком по ней востановить главное окно,
и при этом надо еще сделать действие Х,
это же действие Х надо сделать еще при некоторых событиях,
и каждый раз когда это надо сделать, мы это делаем так
global_pointer_to_app->mainwin->elm1.do1();
global_pointer_to_app->not_mainwin->elm1.do2();
и т.д.

и вот нужно было мне изменть действие X на Y,

пришлось искать и править в куче мест,
и в Icon я это пропустил, т.к. кто бы мог подумать что в Icon есть такой
код, а grep оказался бессильным.

И мне кажется что если бы global_pointer_to_app не был доступен, то
автоматически этот код бы существовал в виде функции в единственном числе
и в классе Application, где ему и место.

А вот моему коллеге кажется, что надо было мне лучше тестировать свои исправления.


iT>Может тогда и удастся прийти (привести?) к тому, что все-таки нужно как-то иначе делать.
iT>Другой вопрос — как именно иначе, но это уже потом.

Здравствуйте, daga, Вы писали:

D>Чтобы вы сделали для объяснения своей правоты в данном вопросе,
D>или может я не прав?


Могу предложить такой вариант. Хотя он потребует определённого времени.
Собирать информацию по всем найденным ошибкам в явном виде. Желательно и по его (коллеги) тоже, это даже должно произвести больше эффекта.
Прям в явном виде заносить каждую ошибку в таблицу в excel. Поля — когда найдена, когда была сделана, кем, где (в каком модуле), причина (например, дублирование — поменяли в одном месте и забыли в другом; или недостаток статической типизации — ошибку должен был показать компилятор, но не сделал этого; ручное управление ресурсами — недоглядели за освобождением памяти). Можно ещё что-то добавить.
По каждой ошибке ты можешь написать комментарий, в котором указать меры, если бы которые предпринимались, то таких ошибок не было бы. Например, если бы повсеместно применяли std::string и std::vector вместо char*, то у нас не было бы этих 20% ошибок с обращениями по невалидным поинтерам и 10% ошибок с утечками. Аналогично можно показать про дублирование и т.д.
Соответственно после накопления некоторой статистики можно делать выводы и показывать их коллеге.

Если он адекватный и с мозгами, то это должно подействовать. Если ему конечно всё пофигу и он на всё говорит "а зачем нам это делать? (мне и так хорошо — деньги то платят) то тут конечно сложнее — можно подумывать о смене места работы...

Здравствуйте, daga, Вы писали:

D>По почте произошел такой диалог:
D>- Я хочу для отделения классов друг от друга использовать boost signals
D>- Зачему это нужно и как это будет выглядеть?
D>- То как сделано это сейчас это известный анти-паттерн ООП и решение тоже давно известно,
D> вот патч показывающий как это будет выглядеть.
D>- Нет, мне это не нравиться, во-первых нужна отдельная библиотека для этого, во-вторых
D> мы знаем что мы будем вызывать на этапе компиляции, зачем нам это делать в runtime,
D> в-третьих мы можем сделать это проще использую static функции и callback аргумент,
D> но зачем, ради какого-то ООП паттерна, я так не думаю.

D>Чтобы вы сделали для объяснения своей правоты в данном вопросе,
D>или может я не прав?

Мне, кажется, вы хотите двигаться слишком большими шагами. Принять за один раз signals, новую библиотеку, разделение объектов, анти-pattern, юнит-тестирование и зачем всё это нужно, "когда и так всё потихоньку работает", — в общем, это довольно круто для человека, который для простоты делает все члены класса публичными

Самый главный совет: перестаньте оперировать терминами "известный анти-pattern", boost и т.д. Это всё будет позволено после того, как вы сделаете несколько оптимизаций помельче и на практике докажете, что на ваши решения можно полагаться. Вариантов "шагов помельче" может быть много. Лично я бы для начала предпочёл заворачивать вызовы application->subObject->methodX() в методы Application. Эти методы выделять в отдельные интерфейсы, чтобы один за одним делать части вашей системы тестируемыми. И всё это только при реализации новой функциональности или исправления старой (чтобы была видна конкретная причина и польза)

А если советовать по серьёзному, посмотрите книгу Michael Feather "Working with the legacy code". Целая книга о вашей ситуации, написанная хорошим понятным языком

Здравствуйте, daga, Вы писали:

[...]
D>> мы знаем что мы будем вызывать на этапе компиляции, зачем нам это делать в runtime,

— я полностью поддерживаю Ваше стремление к более управляемой архитектуре и минимизации взаимозависимостей;

— с другой стороны я согласен с вашим визави относительно того, что использование "позднего связывания" и прочих неявных интерфейсов суть моветон (во всяком случае, внутри одной системы, а не для общения с внешними системами). Я бы предложил искать более другие подходы к упорядочению архитектуры.

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

Regards,
Mike

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, daga, Вы писали:

А>[...]
D>>> мы знаем что мы будем вызывать на этапе компиляции, зачем нам это делать в runtime,

А>- я полностью поддерживаю Ваше стремление к более управляемой архитектуре и минимизации взаимозависимостей;

А>- с другой стороны я согласен с вашим визави относительно того, что использование "позднего связывания" и прочих неявных интерфейсов суть моветон (во всяком случае, внутри одной системы, а не для общения с внешними системами).

Лишние 20К для десктопной программы, а взамен получение системы разделенные на модули,
взамен одного большого модуля непонятно, как работающего моветон?

>Я бы предложил искать более другие подходы к упорядочению архитектуры.

В данной кокретном случае речь идет в основном о GUI,
ваши предложения о работе с GUI на C++ без slots/signals?

Здравствуйте, daga, Вы писали:

D>Я предложил постепенно изменить очевидные вещи, ну например:
D>есть GUI компонент основная задача которого вызывать Application->MethodX(),
D>все ему больше ничего не нужно знать ни об Application, ни о других классах,

D>я хочу отделить его использую boost signals/slots от остального приложения,
D>и так постепенно поступить со всеми простыми классами, общающимися
D>с Application, посредством вызова его двух, трех методов, а больше никак
D>не взаимодействующих с другими компонентами программы.

Отделить — вещь хорошая, а почему обязательно boost signals/slots? Signals/slots, насколько я понимаю, это publisher-subscriber pattern, который в основном нужен, когда неизвестное заранее число неизвестно каких компонент должно быть оповещено о каких-то событиях, Вы уверены, что именно это нужно в данном случае? Почему бы не сделать попроще, например, выделить интерфейс ISupportsMethodX, в application реализовать интерфейс, а компоненте передать адрес интерфейса? При этом компонента даже не обязана быть в отдельной библиотеке, вполне достаточно, если это будет отдельный класс в рамках того же проекта.

Ну то есть я не знаю полностью Вашей задачи и поэтому не могу сказать, может быть, Вы и правы полностью. Но, исходя из того, что я прочел, мне ситуация видится так:
— есть проблема
— Вы предлагаете глобальное, вычитанное из книги, на бумаге смотрящееся красиво, решение
— решение не совсем к месту: вообще-то паттерн предназначен для другого, а в данном случае притянут за уши
— Вашему партнеру не нравится эта глобальность и книжность, и он чувствует притянутость за уши (хотя, может быть, и не может это явно сформулировать)
— а Вы увлечены своей идеей и его считаете ретроградом.

Еще раз, я не знаю деталей, может, все это и не так. Но по крайней мере, попробуйте взглянуть на это с такой стороны .