LINUX.ORG.RU

Оптимальное количество классов в разделяемой библиотеке

 , , ,


0

1

Пишу Just for lulz графический движок - библиотеку классов для построения сцены(включая загрузку моделек) и её отрисовки на OpenGL. Через какое-то время проект разросся и на данный момент состоит из 59 классов, выполняющих самые разные функции. Ада зависимостей нет и поэтому библиотека спокойно разрезается на несколько частей - core и различные надстройки (поддержка текстурирования, освещения, ввода, графа сцены, форматов моделек и пр.). Разрезание на модули позволит приложениям-пользователям не тащить в зависимости то, что им не нужно (зачем, например, вьюверу моделей поддержка fbo и ввода с джойстика), а самое главное упростит изучение API и кода (планирую GPL-ить).

Собственно, какое количество классов оптимальное для разделяемой библиотеки c++? Нормально ли, когда в библиотеке лежит 1-3 маленьких класса и больше ничего?

★★★★

1) Надеюсь ты пишешь документацию
2) Линк скинь на твою либу

Судя из того что ты назвал, её можно разбить частей на 5-6. Микробиблиотечки по 3 класса имхо бред.

anonymous ()
Ответ на: комментарий от anonymous

Надеюсь ты пишешь документацию

Пока нет.

Линк скинь на твою либу

localhost:///home/robus/src/sib_engine3d

Просто до того как GPL-ну и документацию напишу хоть в каком-то виде, выкладывать не хочется.

Разрезание на модули вроде как должно помочь с документацией (самодокументируемый код, все дела)?

Микробиблиотечки по 3 класса имхо бред

Даже если это - дополнительные зависимости (поддержка qml, QtWidgets, etc).

robus ★★★★ ()
Последнее исправление: robus (всего исправлений: 1)

Разработчик в любом случае будет изучать только ту часть API или кода, что его интересует, вне зависимости от их разбиения на библиотеки. В отдельные части возможно стоит вынести что-то завязанное на третьи библиотеки (интеграция с Qt, Gtk, SDL, что там еще...). Всю основную часть, отвечающую собственно за 3D-мир стоит поставлять одной библиотекой, по крайней мере мне кажется, use-case для большинства разработчиков будет использовать все компоненты. И это избавит их от гугления undefined reference to.

staseg ★★★★★ ()
Ответ на: комментарий от staseg

Разработчик в любом случае будет изучать только ту часть API или кода, что его интересует, вне зависимости от их разбиения на библиотеки

Ok.

В отдельные части возможно стоит вынести что-то завязанное на третьи библиотеки (интеграция с Qt, Gtk, SDL, что там еще...).

Библиотека by design завязана на Qt5 GUI, в отдельные модули планирую вынести как минимум qml и виджеты.

Всю основную часть, отвечающую собственно за 3D-мир стоит поставлять одной библиотекой, по крайней мере мне кажется, use-case для большинства разработчиков будет использовать все компоненты.

Ну, да. Кого нынче удивишь .so-шкой размером в 1.5 Мб с 59 классами внутри.

И это избавит их от гугления undefined reference to.

Я думал можно накидать static_assert-ов, которые будут проверять флаги линковки текущего проекта (как-нибудь это ведь можно сделать?).

robus ★★★★ ()
Последнее исправление: robus (всего исправлений: 1)

Какое отношение имеет количество? Разделяй по смыслу/доменам.

invy ★★★★★ ()

Абсолютно нормально, хоть один класс. Количество классов вообще не то на что надо смотреть. Если библиотека бьётся на части, то нет причин не бить - это банально удобно.

anonymous ()

Я встречал либы с одним классом и парой структурой в публичном доступе. Все живы))

Norgat ★★★★★ ()

Какое отношение имеет количество? Разделяй по смыслу/доменам.

Абсолютно нормально, хоть один класс. Количество классов вообще не то на что надо смотреть. Если библиотека бьётся на части, то нет причин не бить - это банально удобно.

Я встречал либы с одним классом и парой структурой в публичном доступе. Все живы))

Прислушаюсь к этому. Спасибо за советы.

robus ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.