ООП концепции путаницы?

Question

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

И, черт возьми, да! У меня было некоторое замешательство. У вас было то же самое, и что делает эту путаницу с программистами (даже опытными программистами)?!

А если бы у тебя было это, как ты мог победить это?!

Спасибо

Answer 1

Тропа Animal работает при объяснении большинства людей.

(Другие полезные ссылки здесь и здесь )

Answer 2

ООП использует "проблемно-ориентированный" подход к программированию , в отличие от традиционного "машинно-ориентированного" подхода, используемого в таких языках, как C и Pascal. Изучение ООП может быть довольно сложным, если вы интенсивно программируете на процедурных / функциональных языках. Именно с этими программистами вещи, как правило, более запутаны. Если вы новичок в программировании, вы, вероятно, найдете вещи гораздо менее запутанными, поскольку начинаете со свежего ума.

Сказав это, я видел много программистов, которые много работали с такими языками, как Java, и утверждают, что они хорошие программисты ООП, хотя на самом деле они далеки от этого. Конечно, они используют функции языка Java, такие как интерфейсы, наследование и т. Д., И создают объекты «которые являются экземплярами классов» и «отправляют сообщение объекту». Большинство людей используют много жаргонного выражения, потому что они подвержены этому. Но когда дело доходит до написания простого приложения, их результирующий код демонстрирует их плохое понимание.

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

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

Answer 3

Большая путаница при изучении ООП возникает из-за попыток выбрать правильные отношения между объектами и классами объектов, особенно если:

• Object содержит Some other Object (или Object1 имеет и Object2)
• Object является экземпляром Class

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

Answer 4

Действительно, я думаю, что слишком большое внимание уделяется понятию «класс».

Самый большой скачок в моем понимании произошел, когда я прочитал о принципе «говори, не спрашивай».

Я только начал «чувствовать» объектную ориентацию, когда играл с (и читал) о средах типа утки, таких как Ruby, JavaScript, Python и т. Д., Спустя примерно 8 лет, успешно создавая загрузку классов в C ++.

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

Кроме того, рядом с обычно используемым термином ООП, часто забывают о том, что первым приходит ОО А и ОО D .

Answer 5

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

Я, наконец, «понял», поиграв в LambdaMOO, MUD (подумайте World of Warcraft, но без графики) с объектно-ориентированным языком программирования в игре. По иронии судьбы, MOOCode не делает различий между классами и объектами - объекты наследуются непосредственно от других объектов. (У него было соглашение об объектах, предназначенных для использования в качестве «базовых классов», которые должны называться «Generic Foo» как способ отличить их от конкретных («instance») Foos, но это настолько близко к различию класса / объекта, насколько не было.)

Answer 6

Когда вы поймете основы, взгляните на шаблоны проектирования и принципы проектирования (например, прочитав Head First Design Patterns ). Он научит вас, как на самом деле использовать инструменты, которые дает вам oo. Хотя это не заменяет практический опыт, оно, безусловно, может ускорить процесс обучения.

Answer 7

У меня никогда не было путаницы, но я изучал программирование по оси времени, в которой оно развивалось. поэтому у меня была сборка, c, c ++, java, c # и множество других, что здесь не актуально. Вы должны принять, что все должно быть выражено объектом, и объект содержит информацию, описывающую себя (свойства), и что они могут выполнять связанные с ними задачи (методы, т.е.

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

Answer 8

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

Но я также считаю, что подход ООП - это отличная вещь для начинающих, потому что этот подход очень "естественен".

Answer 9

Спасибо за ваши ответы.

Я думаю, что давать примеры лучше, но не каждый раз, верно?!

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