Добрый вечер! Изучаю книгу "Адаптивный код". В ней приводится пример

добавления библиотеки классов (C# и Visual Studio) в качестве зависимости у консольного приложения. Причём библиотека классов и консольное приложение это разные проекты, объединённые в одно "Решение" (типо "Группа проектов" в Lazarus и Delphi, насколько я понял).

В Lazarus аналогом библиотеки классов является общая библиотека (shared library). Какие есть варианты создания зависимости у проекта консольного приложения к проекту общей библиотеки? Пока в голову приходит только создание пакета.

MessagePrinter - библиотека классов SimpleDependency - консольное приложение

О сколько нам открытий чудных, готовить просвещения дух... Почитай лучше про планировщик процессов у Багеля. Вот это круть. Это не выполнение задач по расписанию. Это например зависимость процессов. Очень круто. До сих пор вспоминаю... а уж столько лет прошло.

Зачем ты хочешь себе геморрой создать?

Учусь создавать приложения, адаптирующиеся к изменениям

Эм. И мы думаешь "зависимость" - это повышение адаптации к изменениям?

При грамотно выбранной "точке сборки", имеет место быть.

Low Coupling - High Cohession.

Гэри Маклин Холл (автор книги) пишет что необходимо правильно составлять зависимости. Я буквально на первом примере застрял. Тут описывается взаимодействие Клиента (консольного приложения) и Службы (библиотеки классов)

Если это будет Git submodule - то да! 👍😁

При этом он не говорит, что эти зависимости - это хорошо

Он говорит что без зависимостей не обойтись

В дотнете уд точно

Пока накопал про Delphi packages. Они вроде как умеют так же классы экспортировать

Ну нахера тебе это надо?

Да я сам пока не знаю, я только начал изучать

Это работает в единичных случаях.

Ген, ну че ты колючки разбрасываешь для ищущего знания? Ты тоже только на чужих ошибках и опыте учился? "Дай человеку попрогать" © :)

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

ты покажи и отойди :) Зачем пинать?

Ну я и показал, там - говно, вон там - норм дорога

А интерфейс у вас описан вне библиотеки? И как вы его потом освобождаете?

Рекомендую при разработке отдавать приоритет потребностям, а не возможностям. То есть тебе надо сделать программку на 10 формочек, то делай как умеешь. Когда у тебя будет 100 формочек и постоянные доработки и перетасовки функционала, тогда потребность в модульности возникнет сама собой.

Интерфейс сам освободит память, если использовать его как обычно

То есть когда ссылки на него закончатся?

Начни читать. Если ты работаешь с интерфейсом, как с IInterface, он сам себя освободит, когда счетчик в 0 перейдет.

В данном случае, 100 формочек - тоже не оправдывает модульность. А вот, если часть формочек может быть не нужна вообще, тогда да

Да. Счетчик ссылок работает и "снаружи"

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

А интерфейс у вас описан вне библиотеки? Чтобы можно было с ним взаимодействовать

Интерфейс ты можешь описать где хочешь. Хоть скопировать. Главное, чтоб совпадали сигнатуры

поэтому интерфейсы удобно использовать когда нужно работать с совсем разными классами. можно один и тот же интерфейс реализовать в двух классах у которых нет общих предков и обращаться к интерфейсам однообразно. собственно как раз в VCL/FMX так и есть: классы полностью разные но реализуют одинаковый интерфейс и этого достаточно