Как создать Объектно-ориентированные Навыки? [закрытый]

Чтобы подсчитать ваши баллы - я считаю, что 2-6 - это здорово, и я думаю, что любой, кто пишет код, должен читать код полностью, даже если это не объектно-ориентированный подход. Но, к сожалению, кажется, что пункт 1 самый важный !!!

Я считаю, что это проблема нашей профессии. Мы учимся на работе, а не изучаем отличный код. Так что, по сути, каждый заново изобретает колесо с точки зрения обучения.

Вы должны сделать плохой ОО дизайн, прежде чем вы сможете сделать хороший ОО дизайн.

Фантастическим проектом было бы взять ваш конвертер валют и медленно перевести код на использование концепций ОО. ОО - это творческий процесс: нет неправильных ответов, но есть худшие и лучшие. В принципе, когда ваш код сохраняет функциональность и становится короче/проще для чтения, он лучше. Когда он приобретает гибкость без увеличения объема кода, это тоже лучше. Но это творческий процесс. Используйте систему контроля версий, такую как GIT, чтобы иметь возможность легко "отменять", пробовать материал и делать ошибки. Проектирование ОО - это процесс.

• Можно ли приобрести навыки проектирования с помощью опыта? можно приобрести?

Да.

• Можно ли научиться книги/блог/материалы в интернете и т.д. поможет?

Да.

• Необходимо ли знание области знание области приложения, которое разрабатываемого приложения?

Да, но я думаю, что слишком хорошее знание области может испортить хороший дизайн. Работая с программистами авиакомпании, я заметил, что известные, не вызывающие сомнений абстракции ("билет", "бронирование") препятствуют хорошему ОО-проектированию. Ваша ОО-модель - это не модель реального мира. Это модель для вашей программы.

• Знание паттернов проектирования, принципы?

Да, больше - лучше, всегда.

• Изучение книги 'Code Complete' книгу ?

Многие люди говорят, что это отличная книга. Но читали ли вы Итало Кальвино? Или Хорхе Луиса Борхеса? Всевозможные книги могут помочь.

• Нужно ли иметь навыки решения проблем? навыки?

Нет. Вы получаете навыки решения проблем, применяя ОО (или любую другую парадигму).

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

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

Я думаю, что вы подходите к этому несколько неправильно, потому что некоторые проблемы просто не нуждаются в объектно-ориентированном решении. Решение должно соответствовать проблеме, а не наоборот.

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

• Можно ли приобрести опыт дизайнерских навыков?

Опыт и врожденные способности – некоторые люди просто не могут этого сделать.

• Помогут ли учебные книги/блог/материалы через Интернет и т.д.?

Конечно. Но они не превратят вас в бога ОО.

• Нужно ли знать предметную область разрабатываемого приложения?

Либо вам нужно иметь его, либо вам нужен доступ к кому-то, кто это делает.

• Знание шаблонов проектирования, принципов?

Знание того, что такое шаблоны дизайна, было бы хорошим началом - это просто распространенные способы делать вещи - ничего волшебного.

• Изучаете книгу «Полный код»?

Однажды я пролистал его в книжном магазине.

• Нужно иметь навыки решения проблем?

Очевидно, да, я бы подумал.

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

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

Предлагаю вам изучить Smalltalk. ДА ... Я знаю, что это немного устарело, но я думаю, что это единственная среда, где можно поэкспериментировать, оценить и «повеселиться» с объектной ориентацией.

В Smalltalk все, что связано с IDE, является объектом. Вы можете думать об объектах, не тратя время на такие детали, как заголовочные / исходные файлы, компиляция и так далее.

Загрузите копию Squeak Smalltalk ( http://www.squeak.org/ ) и начните практиковаться