Как развить навыки ООП *реальной* жизни?
https://stackoverflow.com/questions/276620
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я изучаю ООП уже довольно давно и хорошо разбираюсь в теории.Я прочитал Головой вперед книгу по ООП, и, хотя она подкрепила большую часть теории, я нашел тематические исследования несколько тривиальными.
Я обнаружил, что применяю принципы ООП к своему коду каждый день, но не уверен, правильно ли я их применяю.Мне нужно дойти до того момента, когда я смогу посмотреть на свой код и узнать, правильно ли я использую наследование, достаточно ли связен мой объект и т. д.
Есть ли у кого-нибудь хорошие рекомендации (книги, онлайн-руководства, блоги, пошаговые руководства и т. д.), как сделать следующий шаг в развитии прочных навыков ООП?
Я работаю в основном с .NET (Visual Basic), но приветствую предложения, включающие различные платформы.
Решение
Прочитайте Рефакторинг Мартина Фаулера и примените его к своей работе.
Он проведет вас через множество неприятных характеристик программного кода, которые описывают, как обнаруживать неправильно построенные классы, и, что еще более важно, как их исправлять.
Другие советы
Рассмотрите возможность изучения шаблонов проектирования.Хотя кажется, что они не часто используются в корпоративных приложениях (я видел, как они чаще используются в API и платформах, чем встраиваются в корпоративный код), их можно применять для упрощения или повышения надежности программного обеспечения во многих ситуациях, если только разработчики знали, как их применить.
Главное — сначала понять шаблоны проектирования, а затем, с опытом, вы научитесь их применять.
Eсть Книга Head First по шаблонам проектирования это довольно просто объясняет эту концепцию, хотя, если вам нужна книга, которая действительно подробно описывает шаблоны проектирования, ознакомьтесь с Книга шаблонов проектирования «Банда четырех», что, по сути, сделало шаблоны проектирования популярными и упоминается почти каждый раз, когда поднимается эта тема.
Шаблоны проектирования в той или иной степени могут применяться практически в любом объектно-ориентированном языке, хотя в некоторых случаях некоторые шаблоны могут быть излишними или чрезмерно инженерными.
РЕДАКТИРОВАТЬ:
Еще хочу добавить, вам стоит почитать книгу Код завершен 2.Это очень влиятельная книга в мире разработки программного обеспечения.Он охватывает множество различных концепций и теорий.Я узнаю что-то новое каждый раз, когда читаю.Это настолько хорошая книга, что, если я читаю ее каждые 6 месяцев или год, я смотрю на нее с другой точки зрения, что делает меня лучшим программистом, просто перечитывая ее.Неважно, как много вы думаете, что знаете, эта книга заставит вас осознать, насколько мало вы знаете на самом деле.Это действительно отличная книга.Я не могу не подчеркнуть, насколько вам должна принадлежать эта книга.
Если у вас уже есть основы, я верю, что только опыт поможет вам продвинуться дальше. Вы говорите, что не уверены, правильно ли вы применяете принципы, но единственного правильного пути не существует. Код, который вы пишете сегодня, вы будете смотреть через 6 месяцев и удивляться, почему вы написали его таким образом, и, вероятно, будете знать, как лучше и чище это делать. Я также гарантирую, что через 10 лет вы все равно будете изучать новые приемы и приемы. Не беспокойтесь об этом, оно придет, просто прочитайте как можно больше и попробуйте применить то, что вы прочитали, маленькими кусочками.
В настоящее время я на полпути к следующей книге:
http://www.amazon.com/Applying-UML-Patterns-Introduction -объект-Oriented / др / 0131489062
Я не могу рекомендовать эту книгу достаточно сильно с точки зрения изучения практического профессионального практического подхода к разработке и применению правильно сформированной и итеративной стратегии проектирования перед погружением в код.
Я тоже прочитал Head First " книга и почувствовал, что мне было намного лучше, прочитав ее.
После нескольких лет опыта работы в мире, я теперь просматриваю книгу Крейга Лармана, которую я рекомендую сделать идеальным "следующим шагом". для меня.
О наличии " UML " в названии этой книги:
Если у вас есть положительные или отрицательные чувства по поводу нотации UML, не позволяйте этому влиять на ваше решение купить книгу (ISBN 0131489062) в любом направлении.
Известность "UML" в названии вводит в заблуждение. Хотя автор использует и объясняет нотацию UML, эти объяснения чрезвычайно хорошо вплетены в соответствующие обсуждения дизайна, и эта книга никогда не читается как скучная спецификация UML.
На самом деле, вот цитата, взятая прямо из книги:
Важно знать, как мыслить и проектировать объекты, что является совершенно другим и гораздо более ценным навыком, чем знание нотации UML. При составлении диаграммы нам необходимо ответить на ключевые вопросы: каковы обязанности объекта? С кем он сотрудничает? Какие шаблоны дизайна следует применять? Гораздо важнее, чем знать разницу между UML 1.4 и 2.0!
Временами кажется, что эта книга "говорит с" ведущий архитектор или менеджер проекта. Под этим я хочу сказать, что предполагается, что читатель имеет значительный контроль над планированием и направлением программного проекта.
Тем не менее, даже если вы несете ответственность только за какой-то очень маленький фрагмент проектов и продуктов вашей компании, я все равно рекомендую эту книгу и рекомендую вам применить некоторые "уменьшенные" " модификация совета книги для вашего кусочка проекта.
Мое прозрение в ООП пришло давным-давно из книги Грэди Буча.Внезапно я понял почему объекты были хорошими.
Хотя полиморфизм — это круто, инкапсуляция — это 75% того, почему объекты круты.Это что-то вроде интерфейса:вы видите кнопки, но не проводку.До появления объектов только самые дисциплинированные программисты держали свои грязные пальцы подальше от внутренних частей чужих процедур (это называлось «структурным программированием»).
Объект позволяет легко поступать правильно.Наследование и полиморфизм — небольшие бонусы.
Один из способов узнать об объектах — это читать код других людей.Я многому научился, прочитав исходный код среды Delphi VCL.Даже простой просмотр документации по Java поможет вам понять, что должен делать отдельный класс объектов и как он предназначен для использования другими объектами.
Начните собственный проект и обратите внимание, когда захотите создать подклассы для своих собственных классов и обнаружите, что вам придется вернуться назад и разбить некоторые защищенные методы, чтобы можно было переопределить только одну часть процесса, а не заменять весь процесс.Посмотрите, как предки общаются с потомками, вызывая абстрактные функции.Другими словами, сделайте много ошибок и учитесь на них.
Наслаждаться!
Честно говоря, перечитывание старых статей Дэвида Парнаса о сокрытии информации помогает мне прийти в правильное состояние души. Тематические исследования могут быть неприменимы, но вы сможете извлечь из них некоторые полезные обобщения.
Мое прозрение произошло, когда я попытался реализовать очень сложную задачу (динамическое и рекурсивное построение операторов SQL) в VB6. Лучший способ понять полиморфизм или наследование - это нуждаться в нем и не иметь возможности его использовать.
Одна вещь, которая определенно вам поможет, - это работа над известным, уважаемым проектом с открытым исходным кодом. Либо покопайтесь в исходном коде и посмотрите, как все делается, либо попробуйте внести некоторые дополнения / модификации. Вы обнаружите, что для большинства задач не существует единого стиля или одного правильного ответа, но, взглянув на несколько проектов, вы сможете получить широкое представление о том, как все можно сделать. После этого вы начнете разрабатывать свой собственный стиль и, надеюсь, внесете свой вклад в процесс с открытым исходным кодом.
Я думаю, что вы должны попытаться и потерпеть неудачу при реализации ОО-решений. Вот так все и сделал. Под неудачей я подразумеваю, что вы в конечном итоге пишете вонючий код, в то же время успешно предлагая работающее решение. После того, как он написан, вы почувствуете, где что-то не так. У вас могут быть какие-то прозрения, и / или вы можете пойти и отыскать подходящее решение от других программистов. Несомненно, вы будете реализовывать некоторые вариации стандартных шаблонов проектирования случайно. Оглядываясь назад, свет нажимает (о, вот для чего нужен посетитель), и тогда понимание ускорится.
Как уже говорили другие, я думаю, что проработка некоторого хорошего открытого исходного кода - хорошая идея. Так работает с более опытными программистами, которые будут готовы критиковать вашу работу. Однако понимание приходит через действие.
Возможно, вы захотите какое-то время прочитать (и написать) Smalltalk. Squeak - это бесплатная реализация, которая может показать вам мощь полностью объектно-ориентированной среды (в отличие от java или .net). Весь исходный код библиотеки включен. Сам язык невероятно прост. Вы обнаружите, что java и c # постепенно добавляют функции, хорошо известные в Smalltalk с 1980 года.
Черепаха HG - это хорошо продуманный внешний вид. исходное программное обеспечение (написано на Python).
Если вы уже понимаете основы, создание чего-либо с нуля на полностью объектно-ориентированном языке будет хорошим шагом в полном понимании архитектуры программного обеспечения ООП. Если вы не знаете Python, Справочник по Python проведет вас через язык в полном объеме от нескольких дней до недели.
После того, как вы поймете язык, ознакомьтесь с приведенным выше программным обеспечением, и вы получите все виды прозрений.
Чтобы полностью понять что-либо, нужно иметь приличное знание хотя бы одного уровня абстракции выше и одного уровня ниже. В случае ОО другие упоминали шаблоны проектирования как слой над ОО. Это очень помогает показать, почему ОО полезен.
Что касается уровня ниже ОО, попробуйте поиграть с функциями более высокого порядка / поздним связыванием на некоторое время и почувствовать, как используются эти относительно простые конструкции. Кроме того, попытайтесь понять, как OO реализован внутри (vtables и т. Д.) И как это можно сделать на чистом C. Как только вы поймете ценность использования функций более высокого порядка и позднего связывания, вы быстро поймете, что OO просто удобный синтаксис для передачи набора связанных функций и данных, с которыми они работают.
