Проектирование кода

Sly

Вообще неплохая идея написать книжку по проектированию кода и решению конкретных задач. Где на примере написания какого нибудь приложения (или даже нескольких), объяснялись и принципы MVC , и тоже ООП и часто используемые алгоритмы. Тоже по своему очень скромному опыту могу сказать, что прочитав книгу или справочник по языку и начиная пробовать, что то писать, кучу времени тратишь на изобретение велосипедов заново, пихая код в одно место.

---

poslegg

Статья очень хорошая но немного мне кажется короткая. Можно было бы рассмотреть разработку отдельного проекта на С# в котором было бы хотя бы 2 класса и показана их взаимодействие, правильная реализация кода, в плане наследования . В наше время много программеров которые лепят всё так что там пипец полный .......  

---

Денис Ильясов

Большое спасибо, наконец-то. :)

---

Александр Перечнев

Актуальная статья. Вы действительно написали её в самый подходящий момент.

---

аноним

Поздравляю всех с праздником великой победы!

---

почитал... в принципе понял, но возникает вопрос чем плох подход размещения кода в модуле формы, в классе формы? у меня так реализовано 90% проектов, неужели это так плохо? комментарии к коду присутствуют, процедурам и переменным стараюсь давать осмысленные имена, применяю форматирование кода...

P.S. есть некоторые общие функции для всех модулей которые выношу в отдельный модуль, но это 10% кода

---

Михаил Фленов

Это ужасно со всех точек зрения. Видимо ты не столкнулся с проблемами. На сколько большие проекты?

---

ronin

почему?



с какими? примеры?



для одного человека и 3 лет разработки достаточно большие

---

klamm

Тема супер, это уже другой уровень кодинга. Книгу по теме купил бы сразу.

---

Михаил Фленов

2ronin

Простейший пример я описал в статье - использование кода логики вне зависимости от морды. Один и тот же движок без изменений используется у меня в программе с визуальным интерфейсом построенном на WinForms и WPF. Я хотел сделать еще Web морду для этого проекта на сайте www.profwebdev.com, но у меня наровый хостинг, а для такого лучше выделенный.

Если бы у меня двиг был бы прямо в модулях с формами, то мне пришлось бы копировать код на два разных проекта.

---

Дмитрий

Михаил, подумайте о написании книги на эту тему. Такой литературы хорошей нет, по крайней мере я не встречал.

---

Михаил Фленов

2ronin

Дописал пару абзацев еще с примерами в статью

---

Михаил Фленов

Книг не планирую писать

---

Legens

мир в котором программисты пишут (нормальный проект я не говорю про project с 10 строчками работы с формой) всё в одном общем модуле не разделяя проект ЭТО КАША!!!!!)) в которой им же потом и копаться, я молчу про групповую разработку.......  

---

ronin

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

опять же я слабо представляю как можно отделить интерфейс программы от движка, было бы неплохо на примере, ведь в модуле формы я всего лишь описываю логику интерфейса (обработчики событий...), а всё остальное как раз и носит модульную структуру и соответствует принципам ООП (модули данных, библиотеки компонентов), разве не так? по моему delphi (и другие среды) именно так и проектировались, так что хоть убей не понимаю что не так в этом подходе

ну а по поводу конкретного примера, про веб интерфейс, конкретно в моём случае система применяется для конкретной задачи (оперативный учёт на производстве), в которой не предвидится и навряд ли когда либо такое понадобится, есть спектр решаемых задач, и система успешно с этим справляется

если бы стояла такая задача, или предполагалась необходимость доступа через веб, то конечно я бы думал над этой задачей, и систему проектировал бы изначально по такому принципу как вы предлагаете

---

ronin

я понимаю о чём вы, но лично я с таким не сталкивался, я не представляю как можно спихать всё в один модуль, ведь всё равно, если брать тот же delphi, для каждой формы создаётся отдельный модуль и логика работы именно с этой формой, а не со всеми остальными формами, находится в модуле этой формы, так же как и модули для работы с данными преполагают размещение действий по работе с бд

---

Михаил Фленов

Посмотри для примера DPhotoWorkshop. Не идеал проектирования (я проект набросал за неделю), но хотя бы какое-то представление даст.

---

VVS

Для WPF можно использовать паттерн mvvm(model view viewmodel), он просто великолепно справляется с задачей разделения ответственности в коде. При этом во всех модулях форм не будет ни одной строчки вашего кода (только автоматически сгенерированный).
Зачем все это нужно?
Ваш код станет четко структурированным, его будет легко сопровождать, очень легко тестировать, и т.д. Попробуйте потестируйте ваш код "в модулях формы", ничего хорошего у вас не выйдет.

---

Максим

Паттерн MVVM в чистом виде хорош только для относительно простых проектов. Для создания крупных проектов с дружественным для пользователя интерфейсом он не всегда удобен. Например, в рамках данного паттерна, довольно сложно в нужные моменты автоматически выставлять фокус в поле ввода, в WP7 ApplicationBar не поддерживает DataBinding и приходится писать свою обертку и так далее.  

---

Overdrive

Вот почему мне не нравится php. Логика от представления не отделена и это очень не удобно. Что и породило кучу шаблонизаторов и велосипедов, хотя php по своей сути и есть шаблонизатор.
Спасибо, хорошая статья.

---

Влад

Знаю, что значит неудачно спроектировать:( Можно разделить на модули, на классы, но так, что части кода всё равно нельзя будет использовать в другом проекте... И модифицировать всё это добро, через некоторое время будет тяжело...

---

ronin

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

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

---

ronin

по этому поводу хотел ещё сказать следующее, недавно как раз столкнулся с такой ситуацией, получил частный заказ на программу, но у заказчика были другие требования предъявляемые к программе, т.е. по сути тот же проект но уже с изменённым (местами новым) функционалом, всё что я сделал это так сказать форкнул проект, создал отдельную ветку проекта в svn репозитории (использую локальный), и всё

да согласен многие функции копируются, т.е. по сути создал полную копию проекта, соответственно при изменении каких то общих функций приходится изменять в одной ветке проекта, а потом выполнять слияние с другой веткой, но в этом случае очень помогает Tortoisse SVN, трудозатраты небольшие, естественно общий функционал (модули) остаётся общим

разве такой подход плох?

---

Владимир (Гаврилов)

Хорошая статья. Интуитивно я конечно понимал все это. А вот Итог особенно понравился. ("учавствовал" поправьте)

---

Денис

Очень понравилась статья! Хотелось, чтобы вы Михаил описали шаблон MVC на простом примере в Делфи. Допустим на примере маленькой базы. Есть форма, на ней TDBGrid, а остальное куда, эту бизнес логику засунуть? Ну и т.д

---

Денис

И ещё, Михаил можете посоветовать какие-нибудь книги по этой теме или ссылки. Кто там великий проектировщик Гради Буч по-моему?

---

Михаил Фленов

Я читал кучу книг и какие уже и не помню. Много пришло просто с опытом, а что-то по ошибке. Не помню, читал я Буча или нет.

---

Илья

Михаил, а как у Вас на работе?? Вы проектируете программный продукт изначально?? Или  выполняете ту часть, которую поручают??

---

Еще что-нибудь

Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.