Правильное ООП и модульность

Нужны советы опытных программистов.

Решил сделать рефакторинг проекта. Общие правила я знаю и стараюсь следовать им (понятные имена методов, избегание дублирование кода и т.д.).

Но хотелось бы разъяснить несколько вопросов.

Функции должны быть отделёны от интерфейса. Но стоит ли выносить их все в отдельный модуль? Сейчас, например, они все описаны в юните главной формы в классе формы, а сам модуль поделён на две части: в первой половине описываются события интерфейса, а во второй части методы функциональные.

И отсюда второй вопрос: стоит ли выделять отдельный класс для этих методов?

Заминка в том, что многие написанные методы работают с определёнными элементами на форме. То есть отдельный модуль уже будет узкоспециализированный. А если переписать их, добавив параметры, то это существенно снизит удобность. Вместо DoSmth придётся каждый раз писать DoSmth(AVar1, Avar2, Avar3).

0

0

Не скажу, что прям уж совсем не по теме)

Идея понятна — в погоне за красотой кода есть риск чрезмерно усложнить архитектуру программы, не говоря уже о потраченном времени. Но всё же какой вариант предпочтительней (понятно, что первый потребует больше времени, но и ошибки при таком подходе быстрее находятся)? Или истина как всегда посередине?

0

Сообщение от Duxan Или истина как всегда посередине?

Риторический вопрос.

1

Сообщение от Duxan Функции должны быть отделёны от интерфейса. Но стоит ли выносить их все в отдельный модуль? Сейчас, например, они все описаны в юните главной формы в классе формы, а сам модуль поделён на две части: в первой половине описываются события интерфейса, а во второй части методы функциональные.

Да, разумеется.
Только, наверное, не функции, а отдельный класс - без привязки к gui.

Сообщение от Duxan И отсюда второй вопрос: стоит ли выделять отдельный класс для этих методов?

По ситуации. Можно и без класса обойтись, но классы же не зря придумали.

Сообщение от Duxan Заминка в том, что многие написанные методы работают с определёнными элементами на форме.

Это плохо, отвязывайте.

Сообщение от Duxan То есть отдельный модуль уже будет узкоспециализированный.

Ну так и надо.

Сообщение от Duxan А если переписать их, добавив параметры, то это существенно снизит удобность. Вместо DoSmth придётся каждый раз писать DoSmth(AVar1, Avar2, Avar3).

По ситуации. Либо вы храните значения внутри класса, либо передаёте их через параметры, третьего не дано.
Если вам действительно "придётся каждый раз писать" - храните это в классе.
Главное - чтобы в классе не было ничего лишнего. Лишнее в классе в вашем случае - это всё, что относится к gui.

1

Сообщение от dondublon Это плохо, отвязывайте.

это с какого перепуга? если у меня есть вывод в мемо, к примеру, какого ляда я должен описывать эту процедуру вне класса формы?

0

Спасибо за советы.

Сообщение от DenNik это с какого перепуга? если у меня есть вывод в мемо, к примеру, какого ляда я должен описывать эту процедуру вне класса формы?

Как мне кажется, код не должен быть запутанным. А обилие классов и функций этому не способствует. Не очень удобно, когда чтобы добраться до кода действия какой-либо кнопки, приходиться по цепочке просмотреть полдюжины функций в разных модулях и классах.

0

Сообщение от dondublon Да, разумеется.

"Забудьте всё, чему вас учили в Институте, как дурной сон..."
(с) М.Жванецкий

P.S. Если бы речь шла о написании учебника по основам ООП или о сферическом коне в вакууме (что почти одно и то же) я бы согласился с таким категоричным заявлением.

0

Сообщение от DenNik это с какого перепуга?

Ну вот так вот.

Сообщение от DenNik если у меня есть вывод в мемо,

Прочитайте ещё раз, о чём я сказал "плохо".

Сообщение от northener P.S. Если бы речь шла о написании учебника по основам ООП или о сферическом коне в вакууме (что почти одно и то же) я бы согласился с таким категоричным заявлением.

Будем меряться письками опытом работы?

Добавлено через 56 минут

Сообщение от Duxan А обилие классов и функций этому не способствует.

Судя по вашему посту, вам это пока не грозит.

Сообщение от Duxan Не очень удобно, когда чтобы добраться до кода действия какой-либо кнопки, приходиться по цепочке просмотреть полдюжины функций в разных модулях и классах.

Не очень удобно, когда вам понадобилось использовать написанный функционал в другом месте, не только по той кнопке, и ВНЕЗАПНО вы обнаруживаете, что его невозможно вытянуть, не потащив за собой StringGrid1, CheckBox1..3 и RadioButton1 и всё остальное.

Ну и возникает вопрос - если вы так хорошо разбираетесь в этом, зачем задаёте вопросы?
Или вы хотите получить от публики оправдание вашему говнокоду - "Да, классы действительно не нужны", чтобы на душе приятнее было?

0

Сообщение от dondublon Не очень удобно, когда вам понадобилось использовать написанный функционал в другом месте, не только по той кнопке, и ВНЕЗАПНО вы обнаруживаете, что его невозможно вытянуть, не потащив за собой StringGrid1, CheckBox1..3 и RadioButton1 и всё остальное. Ну и возникает вопрос - если вы так хорошо разбираетесь в этом, зачем задаёте вопросы? Или вы хотите получить от публики оправдание вашему говнокоду - "Да, классы действительно не нужны", чтобы на душе приятнее было?

Хочу разобраться, как всё таки наиболее правильно, и в том числе и с точки зрения дальнейшего сопровождения. Часто говорят — смотрите исходники проектов. Но вот на них не пишется их рейтинг с точки зрения красоты и правильности архитектуры. Смотря код достаточно больших проектов, видел и дублирующий код, и интерфейс связанный с логикой, и минимум классов. И не поймёшь — то ли они так делают по незнанию (что странно, учитывая размер проекта), либо специально в целях экономии времени.

0

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

0

Сообщение от dondublon Не очень удобно, когда вам понадобилось использовать написанный функционал в другом месте, не только по той кнопке, и ВНЕЗАПНО вы обнаруживаете, что его невозможно вытянуть, не потащив за собой StringGrid1, CheckBox1..3 и RadioButton1 и всё остальное.

если у меня возникает функционал, который нужно использовать в разных местах, то я, естественно, оформляю это отдельной функцией с передачей ей нужного " StringGrid1, CheckBox1..3 и RadioButton1 и всё остальное".
в данном вопросе нет черного и белого. не стоит категорично заяалять

Сообщение от dondublon Это плохо, отвязывайте.

не зная структуры программы.

0

Сообщение от DenNik если у меня возникает функционал, который нужно использовать в разных местах, то я, естественно, оформляю это отдельной функцией с передачей ей нужного " StringGrid1, CheckBox1..3 и RadioButton1 и всё остальное". в данном вопросе нет черного и белого. не стоит категорично заяалять

"Если" Как будто он изредка возникает, внезапно.
А я буду категорично заявлять, уж извините.
Потому что знаю, как устроена нормальная программа. Это айсберг, в котором большая, подводная часть - это именно без-гуишный функционал. И таки да, передавать туда gui-шные элементы - это тоже говнокод.

Сообщение от DenNik не зная структуры программы.

Зная структуру программы (вернее, про её отсутствие), топикстартер достаточно всё описал. Ещё замечания?

1

Сообщение от dondublon И таки да, передавать туда gui-шные элементы - это тоже говнокод.

окей, гуру. приведи пример неговнокода применительно к ситуации, когда нужно взаимодействовать с gui, но без привязки к gui (тавтология получилась, уж не обессудьте), а также чтобы НЕ

Сообщение от dondublon передавать туда gui-шные элементы

0

Сообщение от DenNik окей, гуру. приведи пример неговнокода применительно к ситуации, когда нужно взаимодействовать с gui, но без привязки к gui (тавтология получилась, уж не обессудьте), а также чтобы НЕ

Возможны варианты.
Смотрим со стороны gui. Не-гуишный код назовём ядром (просто чтобы как-то назвать).
1. Ничего в ядро не передаём, только получаем. Кстати, самая простая и частая ситуация.
2. Когда в gui не можем отследить момент, что в ядре что-то произошло, а отобразить надо - из gui подписываемся на события ядра. Разумеется, сами события должны быть запрограммированы.
Ну и
3. Передавать контол в ядро тоже можно, в некоторых случаях это бывает хорошо, НО! обязательно при этом абстрагируем контрол, чтобы ядро не как конкретный контрол его рассматривало, а как нечто более абстрактное. По хорошему - интерфейс (не в смысле gui, а в смысле IInterface). Имеет смысл, когда класс в ядре только затем и делается, чтобы его рисовать.

Добавлено через 1 минуту
DenNik, предвижу сарказм про ненужное усложнение. Ну что ж, такова селяви.

0

Распишу более конкретно.

В программе динамически создаются вкладки на Page Control. За это отвечает процедура NewTab без параметров (так как Page Control существует в единственном экземпляре и сразу ясно, где создавать). Согласно вышесказанному, стоит переписать эту процедуру NewTab, передавая ей в качестве параметра нужный Page Control? И аналогично со всеми другими процедурами?

И вопрос по поводу свойств. Свойства нужны для работы с полями. Но только ли через них работать?
На примере: есть поле типа динамического массива, в котором хранятся ссылки на создаваемые табы. В данном случае я работаю не используя свойства, просто напрямую обращаясь к нужной вкладке:
FTabList[I].Key.Name := 'Smth';
В данном случае то мне кажется удобным, при том что само поле описано в секции Private. Или же я просто не понял смысл свойств?

0

Сообщение от Duxan В программе динамически создаются вкладки на Page Control. За это отвечает процедура NewTab без параметров (так как Page Control существует в единственном экземпляре и сразу ясно, где создавать). Согласно вышесказанному, стоит переписать эту процедуру NewTab, передавая ей в качестве параметра нужный Page Control? И аналогично со всеми другими процедурами?

Я бы сделал на событиях. Это не так сложно, даже писать особо не надо - уже костяк написан.
В TList<T> (Generics.Collections)
Ваши данные объединяете в класс, внутри класса список ваших объектов TList<T>.
У него уже готово событие OnNotify, на него подписываетесь.
В этой процедуре делаете обработку - если появился новый итем, исходя из него уже делаете NewPage.
Конечно, можно и ещё аккуратнее сделать, в частности, прямо в BigData определять Action, но тут уж писать мне лень.

2

Спасибо за идею, попробую реализовать.

0

Долго слежу за темкой.
Во всём согласен с dondublon.
Могу добавить ещё такую мысль. Для работы с гуёвыми контролами с целью наполнения данными неких сущностей, можно использовать разные подходы, начиная от обычного MVC и заканчивая Bindings , для чего существуют всякие библиотеки.
Для тренировки навыка работы в ООП стоит заморочиться такими вещами. Конечно, в реальных проектах так бывает усложнять некогда и незачем. Но также и бывает, что при необходимости каких-то переделок и доводок могут быть сложности с жёстким кодом, что увеличит время разработки. Гибкость, конфигурируемость и модифицируемость сильно облегчают жизнь, и ооп в этом неслабо помогает.

Сообщение от Duxan И вопрос по поводу свойств. Свойства нужны для работы с полями. Но только ли через них работать? На примере: есть поле типа динамического массива, в котором хранятся ссылки на создаваемые табы. В данном случае я работаю не используя свойства, просто напрямую обращаясь к нужной вкладке: FTabList[I].Key.Name := 'Smth'; В данном случае то мне кажется удобным, при том что само поле описано в секции Private. Или же я просто не понял смысл свойств?

Тут всё просто. Свойство служит для сокрытия способов доступа к данным через методы, т.е. при обычном чтении и присвоении массива Вы не заметите необходимости свойств. Но стоит чуть вывести систему из равновесия - например не уследить за индексами, или когда код из разных мест меняет данные, и нарушается целостность (когда нечто хранит данные в таком массиве, а другой их поменял, первый не будет "осведомлён" об изменениях и будет "полагать" что данные старые). На примере индексов - при неверном индексе - будет исключение доступа к памяти, работая через метод же, легко набросить проверку индекса и упростить ошибку до обычного сообщения пользователю, а код который работал с массивом при переделке на массивовое свойство даже не потребуется менять.
Более того, свойства часть используются для ограничения области видимости и возможностей доступа - например только на чтение. Внутри одного модуля, элементы разных классов конечно видят всю подноготную других классов (кроме случая с модификатором strict), поэтому разделение на модули даст ещё большее повышение надёжности классов - Вы будете уверены что никакой другой код не имеет доступа к внутренностям, а может работать только через публичные методы и свойства только разрешённым образом.
Есть ещё одна интересная особенность свойств. Вы можете не иметь под них даже данных (полей), а вычислять значение на лету, в функции, для внешнего же пользователя данного класса, это будет выглядеть как обращение к "переменной", что упрощает понимание.
И ещё много всяких тонкостей и особенностей есть. Советую почитать http://delphikingdom.ru/asp/vi... logid=1186

1