| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Для новичков > Процедуры и функции как метод класса, или... |
| Автор: Pcrepair 3.9.2013, 15:20 |
| Добрый день. Есть программа, которая использует потоки (потомок TTread) Код потока состоит из множества функций и процедур, которые в настоящий момент прописаны как методы класса и все работает как предначертано. Для улучшения восприятия кода(и удаления повторов кода Ф и П) в принципе можно вынести процедуры и функции в отдельный модуль (подключив CoInitialize(nil); код CoUninitialize; с учетом вызова подпрограмм из потоков) Вопрос: как правильно сделать? оставить подпрограммы методами классса или вынести в отдельный модуль? наверняка есть какието косяки |
| Автор: Illusion Dolphin 3.9.2013, 15:51 | ||||
CoInitialize/CoUninitialize лучше делать в потоке, имхо
Зависит от логики. Если классы большие то лучше разбивать. |
| Автор: Pcrepair 3.9.2013, 19:17 |
| вопрос был: наверняка есть какието косяки??? так значит, косяков нет? просто обложить вызов процедуры CoInitialize(nil); CoUninitialize;(ну там используется АКтивХ и вызов Mlang.dll), а если нет АктивХ то можно обойтить и без(если компиллятор не скажет что нужно) ту кое кто кое где утверждал идею о том что лучше чтоб все подпрограммы были методами класса другие же утверждают: неважно где лежит подпрограмма, важно откуда она вызывается, что входит в противоречие с первым высказыванием кто имеет опыт по этому вопросу? |
| Автор: Illusion Dolphin 3.9.2013, 21:08 |
| Если работа идёт с ActiveX то каждый поток должен вызвать CoInitialize до работы с АКтивХ и CoUninitialize после. Это лучше оставить в потоке, избавив функции он необходимости "думать" о том, стоит или не стоит делать CoInitialize. Остальное можно (<> нужно) выносить в любый другие модули. Конкретное решение о выносе кода принимается исходя из личного опыта и архитектуры программы, логики кода. |
| Автор: Poseidon 4.9.2013, 07:41 | ||
Первые правы в плане организации кода. Хотя тут конечно, как говорится, "на вкус и цвет...", но в большинстве своем гораздо удобнее когда код, с которым работает класс, является методом этого класса, а не лежит абы где и не понятно кто там еще его использует. Вторые тоже правы. Если все сделано правильно, то для конечного результата на самом деле это не важно. По-моему там есть какие-то нюансы в плане скорости вызовов и оптимизации кода, но это вторичный вопрос. Другое дело что такие подпрограммы не защищены от вызовов. Нельзя организовать область видимости. Если вдруг встанет задача что-то изменить в алгоритме этой подпрограммы для корректирования результата, который передается в наш класс, мы не сможем гарантировать того, что эти изменения не повлияют на что-то другое. Ведь такие подпрограммы могут вызывать кто угодно. Это хорошо если вы единственный разработчик и хорошо знаете свою программу. А если это большой командный проект, то нет гарантии что кто-то другой не использует эту же подпрограмму и для него она должна работать именно так как работает. Поэтому лично мен мнение - класс должен быть единым целым и его составляющие должны быть внутри его. До, есть исключения на подобии служебных функций, вроди IntToStr, реализацию которых нет смысла вносить в методы класса. Но если подпрограмма носит не общий характер, а связана непосредственно с работой класса, то она должна быть реализована в виде метода. |
| Автор: Pcrepair 4.9.2013, 13:44 | ||||
что это значит? сейчас так:
то есть CoInitialize - CoUninitialize обложено только вызов функции использующей АктивХ есть какие то другие варианты? |
| Автор: Illusion Dolphin 4.9.2013, 14:35 | ||
Если TLoader это поток, то это значит, что можно сделать так:
В таком случае если функции АктивХ вызываются несколько раз не тратятся ресурсы за поднятие и остановку АктивХ. В таком случае всё остальное можно вынести в другие модули и забыть об инициализации и остановке АктивХ. P.S. Возможны проблемы если АктивХ должен быть инициализирован по-разному (см. CoInitializeEx) для разных функций, а если всем хватает обычного CoInitialize от и нет проблем. |
| Автор: Pcrepair 4.9.2013, 18:08 |
| теперь стало понятнее. спасибо |
| Автор: mes 4.9.2013, 21:21 | ||
ага, но имхо с оговоркой... надо стремиться в классе оставить только необходимый минимум.. но при этом надо учесть, что все лишнее выделенное из класса должно быть "чистым" т.е. не иметь жесткого сцепления с этим классом.. если не получается, то конечно лучше иметь один неуклюжий класс, чем разбросанные по коду неуклюжие фрагменты.. |