Как организовать свою библиотеку функций?
Хочу сделать свою библиотеку функций в виде набора модулей.
Но хочу их сделать глобальными, чтобы пользователь не мучался с названием модуля, а просто писал название функций. Так можно переезжать чаще из модуля в модуль.
Все модули не использующие серверных или клиентской специфики будут в модулях с галками клиент, сервер и "Вызов сервера".
Префикс будет бф.
Примеры функций уже в библиотеке:
Модуль бфТабличныйДокументКС
--бфТекстТабличногоДокумента
Модуль бфЯзык
--бфПрисвоитьБезопасно
Как видите, в названиях согласуюсь с логикой языка, хотя можно было бы плясать от объекта: бфТабличныйДокументТекст а не бфТекстТабличногоДокумента
Покритикуйте подход, что можно улучшить?
Но хочу их сделать глобальными, чтобы пользователь не мучался с названием модуля, а просто писал название функций. Так можно переезжать чаще из модуля в модуль.
Все модули не использующие серверных или клиентской специфики будут в модулях с галками клиент, сервер и "Вызов сервера".
Префикс будет бф.
Примеры функций уже в библиотеке:
Модуль бфТабличныйДокументКС
--бфТекстТабличногоДокумента
Модуль бфЯзык
--бфПрисвоитьБезопасно
Как видите, в названиях согласуюсь с логикой языка, хотя можно было бы плясать от объекта: бфТабличныйДокументТекст а не бфТекстТабличногоДокумента
Покритикуйте подход, что можно улучшить?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Я вот, честно, пользуюсь только одним модулем БСП - общего назначения. Забыл уже, когда последний раз в другие лазил, хотя было время сам там много что добавлял (те же защищенные тома в работу с файлами, например). Правда сейчас и с конфигурацией работаю, в которой интеграции больше, чем 1Са.
А если про критику, то вот вообще без разницы. "бфБлаБла()" - смотрится на мой скромный взгляд так себе. А вот "БФ_БлаБла()" - сильно лучше. Но это мой взгляд. Я и из двух букв переменные вполне себе в итераторах коллекций юзаю.
А если про критику, то вот вообще без разницы. "бфБлаБла()" - смотрится на мой скромный взгляд так себе. А вот "БФ_БлаБла()" - сильно лучше. Но это мой взгляд. Я и из двух букв переменные вполне себе в итераторах коллекций юзаю.
Как было бы удобно лично мне:
1. Должен быть единый интерфейс - интерфейсный модуль, названный понятно не для вас, а для
пользователя, пусть это будет БиблиотекаУниверсальныхМетодов - над названием сами думайте, это я только для примера.
Может даже не надо всех этих бф префиксов именно в интерфейсном модуле, остальным, РАЗУМЕЕТСЯ, префикс нужен.
2. Ни в коем случае не глобальный. Крайне не удобно читать код с методом СделатьВсеХорошо, не понимая визуально, откуда у него ноги растут. Код надо читать как книгу, даже лишняя задержка на 0.5 секунды - плохо.
Я уже не говорю про то, что гениальная мысль назвать свой метод СтрЗаменить гарантировано придет в голову кому-то еще. :)
3. Все остальные методы, можете распихивать по своим модулям как хотите, только НЕ делайте их экспортными. Все обращение к их методам идут через единый интерфейсный модуль.
4. Исходите из того, что в интерфейсном модуле названия методов должны быть приколочены гвоздями и залиты бетоном. Поэтому написание метода может занять у вас 10 минут, а придумывая названия метода и параметров - час.
Тогда не будет казусов, как в ИР, где в версии 6.96.1 (может и в других) метод "ОТ" из ирПортативный.epf плавно уехал в
ирОбщий.epf, без объявления войны.
Это очень хороший продукт (проделан титанический труд, сохранивший лично мне много времени и нервов), тем показательней нарушение архитектурного решения. Я уже не говорю, что название ОТ или Открыть ну никак не способствуют пониманию, что этот метод делает. (Может поэтому в 6.96.1 в ирПортативный появилось какое-то другое название, не знаю, не нашел).
5. Прежде чем изобретать свой метод потратьте время и ясно ответьте на вопросы:
- чем он лучше уже имеющихся, если таковые есть, например, в ИР
- зачем он вообще нужен
- покрыт ли его код тестами - чтобы у вас все "вдруг" не рухнуло.
- достаточно ли он эффективно реализован.
- есть ли у него особенности при работе в разных OS (или требования к наличию определенных внешних библиотек)? Если да, то есть ли понимание как это довести до пользователя заранее, а не дожидаясь, когда он это поймет на своей шкуре?
1. Должен быть единый интерфейс - интерфейсный модуль, названный понятно не для вас, а для
пользователя, пусть это будет БиблиотекаУниверсальныхМетодов - над названием сами думайте, это я только для примера.
Может даже не надо всех этих бф префиксов именно в интерфейсном модуле, остальным, РАЗУМЕЕТСЯ, префикс нужен.
2. Ни в коем случае не глобальный. Крайне не удобно читать код с методом СделатьВсеХорошо, не понимая визуально, откуда у него ноги растут. Код надо читать как книгу, даже лишняя задержка на 0.5 секунды - плохо.
Я уже не говорю про то, что гениальная мысль назвать свой метод СтрЗаменить гарантировано придет в голову кому-то еще. :)
3. Все остальные методы, можете распихивать по своим модулям как хотите, только НЕ делайте их экспортными. Все обращение к их методам идут через единый интерфейсный модуль.
4. Исходите из того, что в интерфейсном модуле названия методов должны быть приколочены гвоздями и залиты бетоном. Поэтому написание метода может занять у вас 10 минут, а придумывая названия метода и параметров - час.
Тогда не будет казусов, как в ИР, где в версии 6.96.1 (может и в других) метод "ОТ" из ирПортативный.epf плавно уехал в
ирОбщий.epf, без объявления войны.
Это очень хороший продукт (проделан титанический труд, сохранивший лично мне много времени и нервов), тем показательней нарушение архитектурного решения. Я уже не говорю, что название ОТ или Открыть ну никак не способствуют пониманию, что этот метод делает. (Может поэтому в 6.96.1 в ирПортативный появилось какое-то другое название, не знаю, не нашел).
5. Прежде чем изобретать свой метод потратьте время и ясно ответьте на вопросы:
- чем он лучше уже имеющихся, если таковые есть, например, в ИР
- зачем он вообще нужен
- покрыт ли его код тестами - чтобы у вас все "вдруг" не рухнуло.
- достаточно ли он эффективно реализован.
- есть ли у него особенности при работе в разных OS (или требования к наличию определенных внешних библиотек)? Если да, то есть ли понимание как это довести до пользователя заранее, а не дожидаясь, когда он это поймет на своей шкуре?
(13) ИР - все таки в первую очередь пользовательский интерфейс, а не программный интерфейс (библиотека). Функции для режима отладки отображаются в удобной пользовательской и всегда актуальны там. Поэтому для ИР простительно по веским причинам иногда менять адреса этих функций.
(15)
У разработчика должны быть развязаны руки называть, реализовывать, переносить свои методы так, как хочет он.
А вот менять интерфейс нежелательно, пусть даже и пользовательский.
Microsoft наглядный тому пример.
Разумеется, если были веские причины поменять еще и интерфейс, то грех жаловаться.
Тем более на собственную лень, я даже не сподобился щелкнуть по кнопке с "жучком", тупо искал по модулям.
Вообще могу только еще раз сказать спасибо за ИР.
Поэтому для ИР простительно по веским причинам иногда менять адреса этих функций
У разработчика должны быть развязаны руки называть, реализовывать, переносить свои методы так, как хочет он.
А вот менять интерфейс нежелательно, пусть даже и пользовательский.
Microsoft наглядный тому пример.
Разумеется, если были веские причины поменять еще и интерфейс, то грех жаловаться.
Тем более на собственную лень, я даже не сподобился щелкнуть по кнопке с "жучком", тупо искал по модулям.
Вообще могу только еще раз сказать спасибо за ИР.
(18)
Тут тоже важен нормальный интерфейс, чтобы потом, ежели найдется чего получше, ничего кроме приватного "нутра" не менять. Да и другие чтобы не плодили дубли.
На личном печальном опыте: из-за того, что никто из программистов не знает где чего искать, в разных (а иногда и в одном и том же!) модулях, лежит, например 3 метода типа ТаблицаЗначенийВМассивСтруктур или ПроверитьНомерТелефона - со своими сигнатурами, вдобавок.
Разумеется, причина не только в этом, но тем не менее.
Хочу как-то систематизировать по принципу "лучшее враг хорошего"
Тут тоже важен нормальный интерфейс, чтобы потом, ежели найдется чего получше, ничего кроме приватного "нутра" не менять. Да и другие чтобы не плодили дубли.
На личном печальном опыте: из-за того, что никто из программистов не знает где чего искать, в разных (а иногда и в одном и том же!) модулях, лежит, например 3 метода типа ТаблицаЗначенийВМассивСтруктур или ПроверитьНомерТелефона - со своими сигнатурами, вдобавок.
Разумеется, причина не только в этом, но тем не менее.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот