| |
|
|
| | Хочу описать классами 4 алгоритма расчетов.
Частично, функции составляющих элементов расчетов совпадают.
Вижу три варианта решения.
1. Вынести совпадающие функции расчетов в отдельный модуль.
Плюс - при изменении алгоритма расчета править придется в одном месте, не будет дублирующихся функций.
Минус - класс теряет самодостаточность.
2. Дублировать совпадающие функции в каждом классе.
Плюс - классы самодостаточны.
Минус - при изменении алгоритма расчета править придется во всех классах. Много повторяющихся функций.
3. Описать один универсальный класс.
Плюс - класс самодостаточен. Нет повторяющихся функций.
Минус - класс получается "тяжелым" за счет универсальности.
Может у кого какие мысли вслух имеются.
Благодарю за внимание. | |
| |
| |
| |
|
|
| | Все предложенные варианты имеют шансы.
Мысль вслух:
Если возможность есть, алгоритм расчёта забейте в таблицу и пусть юзер сам его меняет. А классу по барабану - считывает алгоритм с таблицы и запускает расчёт. | |
| |
| |
| |
|
|
| | расскажите, как эти пользовательские алгоритмы правильно оформлять и обрабатывать...
бо я пришел к этому потихоньку...
ну не расскажите, а ткните что читать ))) | |
| |
| |
| |
|
|
| |
расскажите, как эти пользовательские алгоритмы правильно оформлять
|
по оформлению - предостаточно материала на этом портале
вот пример различного оформления одной процедуры
http://hiprog.com/forum/read.php?id_forum=1&id_theme=4115&page=1
а по обработке - в соответствии с заданием, тут рекомендации трудно давать | |
| |
| |
| |
|
|
| | Благодарю.
..считывает алгоритм с таблицы и запускает расчёт...
|
Этого, к сожалению, пока не умею.
...пусть юзер сам его меняет...
|
А при этом варианте можно сразу вешаться.
Я исхожу из того, что пользователю лучше оставлять только необходимый "партизанский минимум".
Желательно вообще одну кнопку - "Выход".  | |
| |
| |
| |
|
|
| | как-то надоело мне бегать к коммунальщикам и я подсунул им таблицу для формирования алгоритма расчётов лицевых счетов(расчёт достаточно простой). Разумеется, флажки кругом расставлены , формировать таблицу алгоритма можно только из тех компонентов, которые есть в базе(что-то похожее - конфигуратор 1С). Так вот, в сентябре было очередное изменение порядка взимания платы за лифт и вывоз мусора. Всего два звонка и ни одного выезда... | |
| |
| |
| |
|
|
| | Вот так, благодаря умению и грамотно изготовленной софтине, alecks_lp остался без премиальных за изменение алгоритма расчета в софтине. | |
| |
| |
| |
|
|
| | и это тоже надо учитывать - так и забыть могут...  | |
| |
| |
| |
|
|
| | Наверное внедрять такой механизм изменений расчетов нужно, но пользоваться им самому, дабы не лезть по всякому пустяку в код.
А с учетом постоянных изменений в ценообразовании и т.п. можно долго "пенки снимать", я полагаю.  | |
| |
| |
| |
|
|
| | я ж говорю - надоело бегать..., а с пенками не так всё просто - конкуренция большая | |
| |
| |
| |
|
|
| | кстати по теме: в этом случае мне пришлось отказать ся от класса, так как работал медленнее, чем обычный модуль. При количестве лицевых счетов более 5000 отставание было заметное. Особенно на старых компах. | |
| |
| |
| |
|
|
| | Моя тема проще. Одноразовый расчет - и в историю.
Про "торможение классов" я где-то уже встречал вкратце.
Но настолько удобнее классом, что удобства перевешивают "подтормаживание". | |
| |
| |
| |
|
|
| | я бы использовал 1-й вариант. | |
| |
| |
| |
|
|
| | Благодарю.
Я начал с первого варианта, но вот что тормознуло:
1. Приходится во внешние функции передавать и возвращать аргументами переменные, которые в классе я имею запросто. Получается транзитная цепочка, довольно неуклюжая.
2. Не будет ли "накладок" при одновременном использовании нескольких экземпляров класса при обращении к Public функциям? Или это фантомная боязнь? | |
| |
| |
| |
|
|
| | По идее не должно быть. ( в смысле накладок ) | |
| |
| |
| |
|
|
| | "Приходится во внешние функции передавать и возвращать аргументами переменные, которые в классе я имею запросто"
да как-то не подумал... наследование тоже не получится...
Крутиться какая-то мысль о создании родительского класса который будет содержать общие функции и коллекции дочерних классов... но пока окончательно не сформировалась... трудная неделя была | |
| |
| |
| |
|
|
| | У Гетца реализовано несколько классов для перерисовки окон ( глава 7 ). И осуществляется вызов ф-ций из разных классов. Можно попробовать реализовать в этом же духе. | |
| |
| |
| |
|
|
| |
...о создании родительского класса который будет содержать общие функции и коллекции дочерних классов...
|
Пожалуй в моем случае, оптимальный вариант.
Благодарю всех. | |
| |
| |
