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

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

Удачи!

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые из интересных статей по Self - это Создание приложений на основе прототипов с использованием SELF 4.0 (the Самоучитель), Я: Сила простоты и Организация программ без классов . Кроме того, Я: Видео (Рэндалл Б. Смит; Дэйв Ангар) потрясающе, поскольку два разработчика языка объясняют идеи Я.

Это работает практически для любой концепции, по крайней мере, для мне:

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

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

(Цитата из http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en ).

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

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

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

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

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

Разбивка SOLID: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

DRY: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

FIT: http: / /www.netwellness.org/question.cfm/38221.htm

DDD: http://dddcommunity.org/

DDD требуется прочитать: http://www.infoq.com/ minibooks / domain-driven-design-quick

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTH

ура,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все методы автоматической регистрации зависят от кода времени загрузки и его способов избегайте статического фиаско, как функция, которая создает объект и возвращает его по запросу.

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

Все методы автоматической регистрации зависят от кода времени загрузки и его способов избегайте статического фиаско, как функция, которая создает объект и возвращает его по запросу.

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

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

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

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

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

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

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

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

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

       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.

        }
    }