Разбиение программы, использующей SDL, на модули

[ElectroMent]

Сообщение от _Bers

1.Тщательнее проектировать архитектуру.
2. см #15 сообщение.

Вот именно такой "конкретики" человек и ждет... стало ясно что к чему.

[_Bers]

Сообщение от Пепел Феникса

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

Экономия на спичках? В ущерб сопровождению?

И потом, почему вообще разным единицам трансляции могут вдруг понадобиться масса данных инициализированных в других единицах трансляции?

Чем можно объяснить такую ситуацию?

Это нарушение инварианта модулей. То есть, модулям для нормальной работы требуется знание о существовании других модулей. Более того, ситуация, когда стабильность работы одного модуля зависит от стабильности работы другого модуля ни о каком инварианте уже и речи не идёт - архитектурный фейл.

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

Сообщение от Пепел Феникса

хотя насчет кучи "незаменимых" глобальных переменных согласен.
но функция вместо переменной не лучше.

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

[_Bers]

Сообщение от ElectroMent

Вот именно такой "конкретики" человек и ждет... стало ясно что к чему.

Не понял этого сообщения.

[ElectroMent]

Сообщение от _Bers

Не понял этого сообщения.

Сарказм .

[mmx358]

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

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

[Пепел Феникса]

То есть, модулям для нормальной работы требуется знание о существовании других модулей.

начнем с того что модуль, который использует другой, итак знает о его существовании.

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

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

Экономия на спичках? В ущерб сопровождению?

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

И потом, почему вообще разным единицам трансляции могут вдруг понадобиться масса данных инициализированных в других единицах трансляции?

я же сказал что они должны быть минимизированы до реально необходимых.
например в том же С, errno, она реально нужная.
в С++, это std::cin, std::cout, std::cerr.

[mmx358]

Сообщение от mmx358

..... Я решил это, передавая указатель по ссылке .....

Не по ссылке, а по значению, через параметр.

[_Bers]

Сообщение от Пепел Феникса

начнем с того что модуль, который использует другой, итак знает о его существовании.

Ну вот чем меньше знает модуль, тем он надёжнее в конечном итоге.

Рассмотрим такой пример: есть два файла: SomeClass.h и SomeClass.cpp

Смотришь в хэдэр - ничего такого криминально не видишь. Он к себе ничего сверху особенного не подключает.

Смотришь .cpp, там мало того, что инклюдится ещё целая гора заголовочных не_стандартных файлов. Это ещё фигня. Это можно пережить.

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

Вот это жессть. Захочешь этот SomeClass выдернуть из общей архитектуры, что бы пересадить в другой проект - он за собой половину всей этой упоротой архитектуры потянет.

И что самое главное - это все происходит совершенно прозрачно от пользователя.

Сообщение от Пепел Феникса

ни капли, если вынесено именно то что реально нужно, а не все подряд.
особенно в С++ с пространствами имен.
ущерба нет ни капли.
getScreen() хуже чем глобальная переменная Screen, ибо если в цикле, то это же замедление значительное.

Что мешает один раз при инициализации модуля взять из единой глобальной точки доступа все, что необходимо для работы?

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

Сообщение от Пепел Феникса

хуже когда вместо методов/функций(и переменных) для работы со Screen(Screen должен быть один объект, который в себе хранит все что нужно для работы с экраном) используются тысячи глобальных переменных, это реальный фейл.
я же сказал что они должны быть минимизированы до реально необходимых.
например в том же С, errno, она реально нужная.
в С++, это std::cin, std::cout, std::cerr.

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

Примерном грамотно использованного глобального объекта можно считать тот же std::cout - как ты свои модули не конструируй, проблем с каутом не будет. Он всегда корректно проинициализируется. И не требует от модулёй какой то особой заботы о себе. Просто сделай #include <iostream> в единице трансляции, и пользуйся на здоровье.

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

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

[Пепел Феникса]

Захочешь этот SomeClass выдернуть из общей архитектуры, что бы пересадить в другой проект - он за собой половину всей этой упоротой архитектуры потянет.

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

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

я к этому и клонил.

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

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

он рискует утонуть в extern

если их сразу грамотно писать, то все будет ок.
но к самим extern'ам, а вот архитектура к ним(верному применению extern) уже не имеет отношения

[_Bers]

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