Подходы к проектированию больших программ
Всем привет.
Есть такая проблема. Когда пишу программы, мне сложно определиться с ее конструкцией. Если программы простые - до 1,5-2 тыс. строк - все без проблем рисуется, весь проект держится в голове и на выходе получается хорошая программа. Если же ТЗ требует большей функциональности (появляются панели, интерактивное общение с пользователем, сложные алгоритмы входа и т.д.), то начинаются проблемы. Программу переписываю по несколько раз, меняя функции местами, изменяя функциональность блоков и т.д. до тех пор, пока заказчик не напишет "возвращай деньги, 58 месяцев уже пишешь, ******* "
Искал различный материал по проектированию приложений, много читал - и статей, и книг, но годного материала для себя не нахожу - либо сухая теория, либо не то, что нужно.
В связи с этим вопрос: поделитесь опытом, кто как решает такие проблемы? Как проектировать эти программы?
ООП используете?
Еще вот эту ветку форума почитайте https://www.mql5.com/ru/forum/193223
- 2017.05.24
- www.mql5.com
ООП используете?
Еще вот эту ветку форума почитайте https://www.mql5.com/ru/forum/193223
При таких проблемах с ООП можно еще больше запутаться. Основная проблема - как общую задачу разделить на подзадачи, если с ООП разделить неправильно на подзадачи, то исправление еще сильнее усложняется.
Только разбивка на задачи. К примеру, есть задача: собрать автомобиль. Большая задача для одного человека, если учесть, что автомобиль состоит в том числе из гаек и болтов в огромном количестве.
Чтобы не пугать мозг количеством болтов и гаек, которых масса в разрабатываемом изделии, не стоит сразу же опускаться до такого уровня детализации. Сначала разбиваем большую задачу на несколько мелких. Из чего состоит автомобиль на макроуровне? Это трансмиссия, двигатель, несущая конструкция, ходовая часть, системы управления и электрооборудование.
Итак, вместо одной большой задачи мы получили шесть задач помельче. Теперь выбираем одну из полученных задач и снова начинаем разбивать ее на более мелкие. К примеру, берем ходовую часть и делим ее на колеса и подвеску. Подобным образом опускаемся все глубже и глубже, пока не дойдем до винтов и гаек, ниже которых (до молекул) опускаться нет смысла.
Решив все задачи одной ветки, переходим к другой. При этом не должен расстраивать тот факт, что по мере решения новых подзадач будут всплывать нерешенные части какой-то другой ветви. Это нормально. С опытом таких случаев будет все меньше и меньше.
Всем привет.
Есть такая проблема. Когда пишу программы, мне сложно определиться с ее конструкцией. Если программы простые - до 1,5-2 тыс. строк - все без проблем рисуется, весь проект держится в голове и на выходе получается хорошая программа. Если же ТЗ требует большей функциональности (появляются панели, интерактивное общение с пользователем, сложные алгоритмы входа и т.д.), то начинаются проблемы. Программу переписываю по несколько раз, меняя функции местами, изменяя функциональность блоков и т.д. до тех пор, пока заказчик не напишет "возвращай деньги, 58 месяцев уже пишешь, ******* "
Искал различный материал по проектированию приложений, много читал - и статей, и книг, но годного материала для себя не нахожу - либо сухая теория, либо не то, что нужно.
В связи с этим вопрос: поделитесь опытом, кто как решает такие проблемы? Как проектировать эти программы?
Вы слишком обще описываете проблему. Значит и ответы будут крайне абстрактные.
В целом Вам правильно заметили, что формальное знание ООП Вам само по себе не даст преимуществ при проектировании большой программы. ООП это как нун-чаки. В руках Брус Ли - это оружие которому нет равных, но в руках неподготовленного пользователя - это две палки для битья самого себя.
Общие рекомендации такие:
1. Старайтесь понять к какому классу принадлежит задача. Т.е. практически всегда любая задача является частным случаем более абстрактного множества задач. Когда Вы поймете, к какому множеству принадлежит задача, попробуйте написать код, который обобщает решение задач из этого множества. Затем сведите решение Вашей конкретной задачи к частному случаю решения этого множества.
2. Применяя первый метод, разделите решение задачи над подмножество подзадач. Каждая из этих подзадач должна решаться без участия других подзадач и модулей, т.е. быть самодостаточной.
3. Используйте композицию. Когда все задачи разъеденены в отдельные, несвязанные между собой модули, их снова нужно собрать под "одной крышей". Так, что бы был удобный прямой доступ к любому из модулей.
4. Минимизируйте интерфейсы взаимодействия. Когда классы содержат десятки GetSet методы, а тот или иной метод использует множество других классов, создается очень запутанный код, где каждый модуль зависит от всех других модулей. Это чревато последствиями. Поэтому в идеале, модуль не должен зависит от других модулей, а другие модули от него. Для этого взаимодействие между модулями нужно свести к минимуму.
Спасибо за ссылки и за советы. Но пока немного не то, о чем хотелось бы поговорить. Видимо, действительно, слишком абстрактно объясняю.
Виталий, ссылка по uml-схемам интересна. Это я тоже иногда использую. Но с ростом программы опять-таки вычерчивание таких схем становится крайне неудобным. Приходится создавать такие схемы в нескольких приближениях - сначала общая схема всей программы, потом отдельная схема для каждого его блока.
Проблем со знанием программирования у меня нет. И ООП использую, и старо-mql-овский подход с функциями. И полиморфизм, и прочие причуды ООП мне знакомы. Рефакторинг хорошо изучил. Пишу (думаю что) грамотно, оптимально. Но именно для того, чтобы этой оптимальности достичь, приходится некоторые функции по несколько (десятков) раз переписывать, по-разному код компоновать, добавлять и удалять переменные.
Вопрос даже безотносительно к конкретному языку, будь то семейство mql, си или иные языки.
Ведь при проектировании техники сначала над проектом работают конструкторы, потом технологи, потом непосредственно производство. И здесь, при программировании, хочется всю работу разбить на этапы - сначала написать блоки программы на бумаге, решив, что к чему; какой кусок за что должен отвечать; выстроить все от и до - за что какая функция отвечает, с кем взаимодействует. И только после этого переходить уже непосредственно к реализации всего этого в коде.
Просто мне не верится, что все работают так, что сразу создают новый файл в метаэдиторе и начинают набрасывать код, дополняя и расширяя его так, как в текущий момент сработала фантазия... Хочется поэтапно - сначала спланировать программу от и до, потом писать, как будто автомобиль из конструктора собираешь - все детальки друг к другу подходят и обеспечивают взаимодействие.
Всем привет.
Есть такая проблема. Когда пишу программы, мне сложно определиться с ее конструкцией. Если программы простые - до 1,5-2 тыс. строк - все без проблем рисуется, весь проект держится в голове и на выходе получается хорошая программа. Если же ТЗ требует большей функциональности (появляются панели, интерактивное общение с пользователем, сложные алгоритмы входа и т.д.), то начинаются проблемы. Программу переписываю по несколько раз, меняя функции местами, изменяя функциональность блоков и т.д. до тех пор, пока заказчик не напишет "возвращай деньги, 58 месяцев уже пишешь, ******* "
Искал различный материал по проектированию приложений, много читал - и статей, и книг, но годного материала для себя не нахожу - либо сухая теория, либо не то, что нужно.
В связи с этим вопрос: поделитесь опытом, кто как решает такие проблемы? Как проектировать эти программы?
насколько видно у вас не с проектированием проблема, а с исполнением проектов и самодисциплиной.
рецепт довольно простой: ведите а-ля контрактную работу "сам-с-собой", ставя ясные достижимые цели и способы их проверки. То есть время от времени надо смотреть на свою-же работу как заказчик. Выполнил какой-то этап, сам у себя его принял и "сдал/подписал/оплатил". А когда в следующий раз возникнет мысль "а не перелопатить ли тут добрую половину", глянь на это дело со стороны себя-заказчика и ответь на вопрос "за чей счёт этот праздник жизни".
Просто мне не верится, что все работают так, что сразу создают новый файл в метаэдиторе и начинают набрасывать код, дополняя и расширяя его так, как в текущий момент сработала фантазия...
Как раз здесь большинство так и работает. Потому что специфика другая - исследование той или иной идеи, когда изначально есть только приблизительное понимание того, что хочется получить в итоге. Причем в большинстве случаев выходит то, что и представить не мог. Какое тут проектирование?
Вы же говорите о другом: есть задача, нужна реализация. В этом случае сначала требуется составить ТЗ. Это и есть проектирование, для которого Meta Editor не нужен. Только после разработки конечного ТЗ наступает момент перехода к набору кода и затем - к отладке. Про этап разработки ТЗ большого проекта я написал выше.
...
Виталий, ссылка по uml-схемам интересна. Это я тоже иногда использую. Но с ростом программы опять-таки вычерчивание таких схем становится крайне неудобным. Приходится создавать такие схемы в нескольких приближениях - сначала общая схема всей программы, потом отдельная схема для каждого его блока.
Проблем со знанием программирования у меня нет. И ООП использую, и старо-mql-овский подход с функциями. И полиморфизм, и прочие причуды ООП мне знакомы. Рефакторинг хорошо изучил. Пишу (думаю что) грамотно, оптимально. Но именно для того, чтобы этой оптимальности достичь, приходится некоторые функции по несколько (десятков) раз переписывать, по-разному код компоновать, добавлять и удалять переменные.
...
Сам, я такие схемы не рисую. Но к тому что выше вам советовали добавить мне не чего. Я по этому и спросил, про ООП потому, что если разбить задачу на несколько мелких задач поместив их реализацию в отдельных классах то это позволит в дальнейшем намного проще без переписывания большой части кода изменять и расширять ваш код. Для изменения или расширения достаточно просто создать наследника от первоначального класса просто изменив и/или расширив его функционал. При чем базовый класс останется без изменений и можно если что вернутся к прежней версии или использовать этот класс в других задачах.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Всем привет.
Есть такая проблема. Когда пишу программы, мне сложно определиться с ее конструкцией. Если программы простые - до 1,5-2 тыс. строк - все без проблем рисуется, весь проект держится в голове и на выходе получается хорошая программа. Если же ТЗ требует большей функциональности (появляются панели, интерактивное общение с пользователем, сложные алгоритмы входа и т.д.), то начинаются проблемы. Программу переписываю по несколько раз, меняя функции местами, изменяя функциональность блоков и т.д. до тех пор, пока заказчик не напишет "возвращай деньги, 58 месяцев уже пишешь, ******* "
Искал различный материал по проектированию приложений, много читал - и статей, и книг, но годного материала для себя не нахожу - либо сухая теория, либо не то, что нужно.
В связи с этим вопрос: поделитесь опытом, кто как решает такие проблемы? Как проектировать эти программы?