Как мне лучше практиковаться в объектно-ориентированном программировании? [закрыто]

Я занимаюсь программированием на объектно-ориентированных языках уже много лет, но втайне смотрю на некоторые вещи, которые делают мои коллеги с завистью. У многих из них есть внутренний инстинкт объектно-ориентированного подхода, которого у меня нет - как бы я ни старался. Я прочитал все хорошие книги по объектно-ориентированному программированию, но все еще не могу взломать его. Я чувствую себя парнем, который выложился на 110%, чтобы стать профессиональным футболистом, но просто не обладал врожденным талантом для этого. Я в растерянности и думаю о смене карьеры - что мне делать?

Я бы сказал, меньше сосредотачивайтесь на ОО-программировании и больше сосредотачивайтесь на ОО- дизайне . Возьмите бумагу и карандаш (или, может быть, инструмент моделирования UML) и отойдите от экрана.

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

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

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

Самый простой способ - изучить такие концепции, как SOLID, DRY, FIT, DDD, TDD, MVC и т. Д. Когда вы будете искать эти сокращения, они приведут вас к множеству других кроличьих нор, и как только вы закончите чтение, вы получите хорошее понимание того, что такое объектно-ориентированное программирование лучше!

SOLID подкасты: http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163

Разбивка ТВЕРДЫХ: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

СУХОЙ: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

ПОМЕСТИТЬСЯ: http://www.netwellness.org/question.cfm/38221.htm

DDD: http://dddcommunity.org/

DDD требуется чтение: http://www.infoq.com/minibooks/domain-driven-design-quickly

TDD: http://en.wikipedia.org/wiki/Test-driven_development

MVC: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

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

Слишком много людей думают о кодировании в первую очередь, о объектах - в последнюю очередь.

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

1. Вот несколько методов, которые мне помогли: Когда вы находитесь вдали от работы и открыты для восприятия, вы можете практиковаться, рассматривая все как объект . Не смотрите на эти объекты и не задавайтесь вопросом, как вы собираетесь их программировать, смотрите на них только как на свойства и функции и как они связаны друг с другом или наследуются друг от друга. Например, когда вы видите человека, он является объектом и, следовательно, представляет класс. У них есть такие свойства, как цвет волос, оттенок кожи, рост и т. Д. Они также выполняют определенные функции. Они ходят, разговаривают, спят и т. Д. Некоторые функции, выполняемые этими людьми, возвращают результаты. Например, их рабочая функция возвращает сумму в долларах. Вы можете делать это со всем, что видите, потому что все является объектом. Велосипед, автомобиль, звезда и т. Д.

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

3. Когда все это будет сделано, беспокойтесь о том, как работает класс.

Я предлагаю научиться чему-то другому.

Изучите функциональное программирование и примените полученные знания в ООП. Если вы знаете C ++, поиграйте с общим программированием.

Изучайте не объектно-ориентированные языки.

Не только потому, что вы тоже должны использовать все эти вещи (вы должны), или потому, что они должны полностью заменить ООП (они, вероятно, не должны), но потому, что вы можете применить полученные уроки и к ООП.

Секрет ООП в том, что его не всегда имеет смысл использовать . Не все классно. Не все отношения или поведение следует моделировать как класс.

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

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

Во многих областях наступает момент «эврики», когда все сходится воедино.

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

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

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

Учите другой язык! Большинство разработчиков, использующих только Java (в качестве примера), имеют лишь ограниченное понимание объектно-ориентированного программирования, потому что они не могут разделить языковые функции и концепции. Если вы еще этого не знаете, взгляните на python. Если вы знаете Python, изучите Ruby. Или выберите один из функциональных языков.

Ответ в вашем вопросе;)

Практика, практика, практика.

Просмотрите свой собственный код и учитесь на ошибках.

TDD больше всего помог мне в улучшении моих общих навыков, включая ООП.

Чем больше кода вы напишете, тем больше вы будете замечать подводные камни определенных практик программирования. По прошествии достаточного времени и достаточного количества кода вы сможете определить предупреждающие знаки этих ловушек и сможете их избежать. Иногда, когда я пишу код, у меня в глубине души возникает зуд, говорящий мне, что может быть лучший способ сделать это, даже если он делает то, что мне нужно. Одна из моих величайших слабостей в программировании - это настолько "чрезмерный анализ", что это начинает резко замедлять время разработки. Я пытаюсь предотвратить этот «зуд», уделяя немного больше времени дизайну, что обычно приводит к гораздо меньшему времени написания кода.

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

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

Разработчики языков интерпретировали «объектно-ориентированное программирование» по-разному. Например, посмотрите, как Алан Кей, человек, который первым использовал термин ООП, определил его:

ООП для меня означает только обмен сообщениями, локальное сохранение, защиту и сокрытие состояния-процесса и крайнее позднее связывание всех вещей. Это можно сделать в Smalltalk и LISP. Возможно, существуют другие системы, в которых это возможно, но я о них не знаю.

(Цитируется по http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en ).

Может показаться странным, что он не рассматривает ООП-языки Java и C ++! Но как разработчик одного из первых и лучших языков ООП (Smalltalk) у него есть свои веские причины для этого. Почему Алан Кей считал Лисп объектно-ориентированным языком, а не Java? Этот вопрос требует серьезного рассмотрения любого, кто утверждает, что понимает ООП.

В Erlang совершенно другая реализация ООП, в Scheme - другая. Стоит рассмотреть все эти альтернативные взгляды. Если возможно, выучите все эти языки! Это даст вам более широкий кругозор, даст вам новые мощные инструменты и сделает вас лучшим программистом.

В этой статье я подытожил свои эксперименты с реализацией языка ООП на основе идей, заимствованных из Smalltalk, Scheme и Erlang .

       public void MasteryOfOOP() 
    { 
       while(true)

        /* My suggestion is: */
     DO: find a lot of well-written object oriented code and read it.  Then 
try to use the insights from it on your own coding.  Then do it again.  Then 
have a colleague who is a good OOP look at it and comment. Maybe post a chunk 
of your code on SO and ask for how it could be improved.

        Then read some more of those books.  Maybe they make a little more 
sense now...?

        Now go back to the top of this post, and do it again. 

        Repeat Forever.

        }
    }

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

Каждый из этих видов вещей, которые вы решаете отслеживать, становится классом.

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

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

Слишком много информации об объектах. Самое главное - освоить азы, и все станет легче.

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

Это абсолютная основа. Вы должны полностью освоить еще три концепции:

Наследование - это все о повторном использовании кода.

Инкапсуляция - это все о сокрытии реализации от интерфейса. Проще говоря, все должно быть конфиденциальным, пока не будет доказано обратное.

Полиморфизм - не имеет значения тип ссылочной переменной, но тип фактического экземпляра, чтобы знать, какое поведение (метод) вызывается. Java не позволяет легко представить эту концепцию, потому что по определению все полиморфно. .Net упрощает понимание, поскольку вы решаете, что полиморфно, а что нет, и, следовательно, замечаете разницу в поведении. Это достигается за счет комбинации виртуального и переопределения.

Если эти концепции очень хорошо поняты, все будет в порядке.

И последний совет: вы упоминаете лучшие книги. Вы читали « Мыслить на Java » Брюса Экеля? Я рекомендую эту книгу даже тем, кто только начинает работать с .Net, так как концепции ООП четко изложены.

Станьте более гибкими, изучите тестирование junit и изучите предметно-ориентированный дизайн. Я предлагаю книгу Domain-Driven Design: Tackling Complex in the Heart of Software, хотя в некоторых моментах это немного сложно.

Навыки ООП приходят со временем. Чтение 1, 2 ... 10 книг не помогает. Попрактикуйтесь в написании кода. Если вы работаете в среде программирования ... это может быть полезно. Если нет, попробуйте попасть в одну. Предложите разработать приложение (я) бесплатно. Вы должны запачкать руки. Помните ... ни одно приложение не может быть идеальным с нуля, поэтому существует рефакторинг.

Также ... не увлекайтесь ООП слишком сильно ... со временем это произойдет. Беспокойство о разработке полнофункциональных приложений.

Попробуйте программировать на Self , одном из самых чистых объектно-ориентированных языков. Настолько чисто, что в нем даже нет классов, только объекты. Также в нем нет переменных, полей, статики, атрибутов, только методы. Также интересен тот факт, что каждый объект в системе также является объектом на экране и наоборот.

Некоторые из интересных статей о себе - это создание приложений на основе прототипов с использованием SELF 4.0 (самоучитель), « Я: сила простоты» и « Организация программ без классов» . Кроме того, Self: The Video (Randall B. Smith; Dave Ungar) потрясающий, поскольку два разработчика языка объясняют идеи Self.

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

ОО наконец-то пришло мне в голову после того, как я попытался запрограммировать похожую на банк программу, которая обрабатывала транзакции, рассчитывала проценты и все это отслеживала. Я сделал это, когда изучал Java. Я бы посоветовал просто попробовать, завершить его, а затем, когда вы закончите, посмотрите на ХОРОШЕЕ решение и посмотрите, что вы могли бы сделать лучше.

Я также считаю, что навыки ООП укрепляются в основном с практикой. Подумайте о смене компании, если вы работаете в ней более 3 лет. Конечно, это справедливо не для всех профессий, но часто мужчина привыкает к проектам и практике в компании и со временем перестает продвигаться вперед.

Закатайте рукава и код!

Вы сами ответили: практикуйтесь. Лучшее решение для этого - разработать игру. Используйте концепции, которые вы узнали из книг.

Вы читали главу по объектно-ориентированному программированию из первого издания книги Скотта Мейерса «Эффективный C ++»? Это не вошло в более поздние выпуски, но это было отличное объяснение. Название было в основном «говори, что ты имеешь в виду, имей в виду то, что говоришь» о подходящих условностях.

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

HTH

ура,

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

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

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

Удачи!

пиво помогает. шутки в сторону. лягте на кушетку с блокнотом для рисования формата А3, ручкой и пивом. Заприте собаку, кошку и жену снаружи. И подумайте о проблеме в расслабленном состоянии. Даже не смейте рисовать на нем API!

Блок-схемы, карточки ответственности (CRC) и пиво (но не слишком много) имеют большое значение.

Самый простой способ рефакторинга кода - это вообще не делать этого.

http://misko.hevery.com/code-reviewers-guide/

Эти небольшие простые правила сделают вас лучше OO-программистом. Неукоснительно следуйте правилам при написании кода, и вы обнаружите, что ваш код лучше, чем он был бы в противном случае.

Вы также захотите изучить твердые принципы: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

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

Возможно, вы уже пишете код таким образом и не знаете этого - если так, отлично. Но если вам нужна цель, к которой нужно стремиться, это золотой стандарт.

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

Какой бы подход вы ни выбрали, язык Python должен быть приемлемым для практики.

Вы моя целевая аудитория. Посмотрите на формирование навыков в объектно-ориентированном дизайне

Возможно, это поможет.