Советы по переходу к объектно-ориентированному программированию из VB 6 'style'

Question

Я разработчик vb.net в небольшом ИТ-отделе, и у меня возникли проблемы с переходом к программированию исключительно с объектами.

Я понимаю принципы ООП, шаблоны проектирования, модульное тестирование и т. Д., Но когда дело доходит до разработки моих приложений, либо мой объектный дизайн плохой, либо я вообще пропускаю построение с объектами. Я знаю, как создавать юнит-тесты, но не уверен в том, что я создаю.

Я создаю почти исключительно приложения для ввода данных и создания отчетов. В большинстве случаев большая часть бизнес-логики находится в базе данных в виде хранимых процедур и пользовательских функций. Я занимаюсь разработкой ASP.NET и Winforms приложений для внутренних и внешних клиентов.

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

Каковы некоторые хорошие первые шаги к тому, чтобы оторваться от моих старых путей 'VB 6'?

Спасибо!

Answer 1

Коллега поразил меня книгой Эрика Эванса «Дизайн, управляемый доменом». Это действительно заставило меня отойти от разработки, основанной на данных, когда это было необходимо.

Кроме того, участие в группе пользователей .NET в вашем регионе будет способствовать поиску людей, которые более чем готовы вам помочь.

Answer 2

Слышу, чувак. Я тоже живу в вашем мире. Мир, где деловые люди требуют отчетов. Комплексные отчеты. Отчеты, которые легко создаются с помощью сложных хранимых процедур. В этом мире легко думать, что база данных - король, и она управляет приложением. Эта линия мышления ведет к сложному коду TSQL базы данных, представлениям, функциям и хранимым процедурам.

Конечно, если вам действительно нужен отчет, то ответом может быть сложное SQL-выражение. Однако вы хотите знать, как вырваться из этого мира, управляемого данными, и войти в объектно-ориентированный мир.

Я думаю, что типичные учебные пособия по ОО не оправдают вас. Кого волнует, является ли собака типом животного, а немецкая овчарка - типом собаки. Это не объясняет, как вы ведете бизнес на работе. Кроме того, это только пример наследования ОО. Другие OO-шаблоны, такие как состав и внедрение зависимостей, в большинстве случаев гораздо полезнее.

Я думаю, вам следует подойти к следующему проекту или задаче - временно забыть о базе данных. Представьте, что вы живете в волшебном мире, где получение данных из базы данных не должно происходить, а запись данных в базу данных также не должна происходить. Вы живете в мире, где ваши объекты всегда заполнены правильными данными. Сначала смоделируйте свои объекты в этом абстрактном мире. После этого тогда (и только тогда) займитесь грязными деталями реализации получения и записи в базу данных. База данных существует только для сохранения ваших данных. Ваши данные живы, потому что вы уже смоделировали их, чтобы они соответствовали правилам вашего домена.

Понимание UML очень поможет в этом типе моделирования. Сначала используйте модели UML для моделирования своего домена. Затем используйте код для этих проектов. Затем обработайте их так, чтобы они соответствовали ограничениям вашей базы данных.

Эрик Эванс "Domain Driven Design" - отличная книга, которая помогает понять этот и многие другие важные вопросы. Он подчеркивает, что моделирование предметной области является критически важным элементом успешного моделирования приложения. Далее он отмечает, что объектно-ориентированное проектирование лучше подходит для моделирования предметной области, чем любая другая парадигма программирования.

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

Answer 3

В дополнение к советам, данным в других ответах, вы должны отказаться от VB.NET и изучить C #.

Это не сделает все для вас, но поможет вам избавиться от старого мышления.

Answer 4

Я был на твоем месте несколько лет назад. Я помню, как читал статью, в которой оценивалось, что вы потратите от 6 месяцев до года, просто читая об объектно-ориентированной разработке, прежде чем начнете «получать ее».

Я начал с того, что просто попытался представить объекты в моем повседневном процедурном программировании. Затем я попытался извлечь как можно больше обработки из пользовательского интерфейса. Затем я попытался создать «слои» для своей бизнес-логики и доступа к данным. Я понимаю, что большая часть вашей бизнес-логики уже может быть в базе данных, но было бы не плохо иметь слой BL в случае, если это изменилось. Прямо сейчас он может функционировать как проход.

У меня есть Эрик Эван, управляемый доменом, который еще предстоит прочитать, но пара книг, которые мне помогли, это " Объектно-ориентированный мыслительный процесс " и та, которую я сейчас читаю " Microsoft .NET: Архитектура приложений для предприятия". Эта книга, хотя, может быть, больше, чем вам действительно нужно сейчас, является первой, которая помогла мне действительно понять слои и как их реализовать.

В любом случае, удачи в путешествии. Просто помните, это будет процесс, а не пункт назначения!

Answer 5

Я бы порекомендовал две вещи:

1. Посмотрите на диаграммы классов UML и поиграйтесь с инструментом диаграмм классов в Visual Studio. Цель ООП состоит в том, чтобы сделать вещи более «концептуальными», думая в терминах объектов, и, по крайней мере для меня, диаграммы классов помогают это сделать.
2. Прочитайте некоторые хорошие шаблоны проектирования, такие как шаблон метода Decorator или Factory. Поскольку большинство шаблонов проектирования в полной мере используют объектно-ориентированное проектирование и, как правило, хорошо описаны, они действительно могут помочь понять концепции.

Answer 6

1. Попробуйте прочитать код из проектов, разработанных в рамках ООП-подхода.

2. Представьте, как будет выглядеть ваш код, если вы будете кодировать в качестве примера, который читаете.

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

4. Запомните правило KISS, все части будут соответствовать, поскольку вы все еще кодируете, следуя принципам ООП.

5. Будь наказан. Легко поддаться старому, но не сдаваться.

Помните слова Диджры: ... когда ты делаешь что-то быстрое и грязное, ты вдруг представляешь, что я смотрю через твои плечи и говорю себе: «Дейкстре это бы не понравилось», что ж, этого было бы достаточно для меня.

Он живет внутри каждого из нас =). И вы сделали самое главное, вы действительно хотите узнать, как. Это главное препятствие для разработчиков VB6, когда они переходят на VB.NET.

• В VB6 это проще.
• В VB6 всегда работает быстрее.
• Это то же самое ... просто выглядит лучше.
• VB6 имеет намного больше функций.

выглядит знакомо?