При чтении некоторых книг по программированию я замечаю, что авторы говорят, что в ООП у вас может быть некоторая путаница, понимая основную идею ООП.
И черт возьми! У меня была какая-то путаница. У вас было то же самое и что это путаница для программистов (даже опытных программистов)?!
И если бы у вас это было, как бы вы могли победить это?!
Спасибо
Троя Animal работает, когда объясняет это большинству людей.
Много путаницы при изучении ООП происходит от попытки выбрать правильную взаимосвязь между объектами и классами объектов, в частности:
Object содержит Some other Object (или Object1 имеет a Object2)Object является экземпляром ClassЕсли я могу придумать хороший пример, который показывает случай, когда любой из них может быть уместным, я добавлю его...
ООП использует "проблемный" подход к программированию, в отличие от традиционного подхода "машинный подход", используемого в таких языках, как C и Pascal. Изучение ООП может быть довольно жестким, если вы запрограммировали широко на процедурных/функциональных языках. Именно для этих программистов вещи, как правило, более сбивают с толку. Если вы новичок в программировании, вы, вероятно, найдете вещи намного менее запутанными, так как вы начинаете с нового ума.
Сказав это, я видел много программистов, которые много работали с такими языками, как Java, и утверждают, что они хорошие программисты ООП, когда они были на самом деле далеки от этого. Конечно, они используют функции языка Java, такие как интерфейсы, наследование и т.д., И создают объекты "которые являются экземплярами классов" и "отправляют сообщение объекту". Большинство людей используют много жаргонов ООП, потому что они подвергаются этому воздействию. Но когда дело доходит до написания простого приложения, их итоговый код раскрывает их слабое понимание.
Мой совет вам не попадает в использование жаргона в одиночку. Вопрос и усвоение основных понятий. У вас может быть ваша первая полунирвана (как и я), когда вы изучаете полиморфизм и преимущества, которые он приносит для повторного использования кода. Другая полунирвана, когда вы понимаете компромиссы между повторным использованием через наследование и повторное использование через композицию. В конце концов, вы узнаете, что хорошо поняли ООП, если у вас есть возможность хорошо спроектировать, а точнее, хороший дизайн OO - это просто хорошая оценка того, насколько хорошо вы понимаете ООП.
Если вы серьезно относитесь к ООП, вы должны прочитать первые две главы книги GOF по шаблонам проектирования. Это может быть немного тяжело для новых программистов, но это заставляет думать о ООП. Эта книга является важной ссылкой, которую должен иметь любой серьезный программист ООП. Если вы хорошо понимаете концепции этой книги, считайте себя хорошим программистом OO.
Да, сначала я испытал некоторую путаницу. Это было в тот день, когда ОО только начинало становиться мейнстримом, поэтому было много книг, которые его покрывали, но не объясняли это хорошо для людей, которые еще не знали, что это было. В результате я начал думать, что объект и класс в значительной степени взаимозаменяемы и определяют новый класс для каждого объекта, который я хотел создать.
Я, наконец, "получил", играя на LambdaMOO, MUD (думаю, World of Warcraft, но без графики) с объектно-ориентированным языком игры в игре. Как ни странно, MOOCode не делает различий между классами и объектами - объекты наследуются непосредственно от других объектов. (У него было соглашение об объектах, предназначенных для использования в качестве "базовых классов", которые должны быть названы "Generic Foo" как способ отличить их от конкретных ( "экземпляров" ) Foos, но это как близко к различию класса/объекта, так как оно не было.)
В самом деле, я думаю, что слишком много внимания уделяется концепции класса.
Самый большой скачок в моем понимании - это чтение о принципе "Скажи, не спрашивай".
Я только начинал "ощущать" ориентацию объекта, когда вы играли вокруг (и читали о) типизированных в утиных средах, таких как Ruby, JavaScript, Python и т.д.... после 8 лет счастливо создавали грузовики классов на С++.
Статично типизированные языки отлично подходят для производственного кода, но вы платите много накладных расходов, пытаясь получить представление об ориентации объекта.
Кроме того, рядом с обычно используемым термином ООП, часто один забывает, что сначала приходит OO A и OO D.
Я думаю, что особенно программисты, которые были опытны в разработке с функционально-ориентированными языками, не понимали концепций ООП. По крайней мере, это было действительно запутанно для меня, и я сделал целую кучу вещей, чтобы программировать функциональность, используя язык ООП (Java).
Но я также считаю, что подход ООП является отличным новичком, потому что этот подход очень "естественный".
У меня никогда не было путаницы, но я изучил программирование вдоль оси времени, в которой она развивалась. поэтому у меня была сборка, c, С++, java, С# и множество других, что здесь не актуально. То, что вы должны принять, состоит в том, что все должно быть выражено объектом, а объект содержит информацию, описывающую себя (свойства), и что они могут выполнять связанные с ними задачи (методы i.E.: Car.GetAllCars();).
Для наследования и полиморфизма, и все остальное рекомендую практику. практикуйте все, потому что практика делает совершенным. Попробуйте разработать примеры, приведенные во всех книгах.
Как только вы поймете основы оо, взгляните на шаблоны проектирования и принципы проектирования (например, прочитав Head First Design Patterns). Это научит вас, как вы должны использовать инструменты, которые вам дают. Хотя это не заменит практический опыт, это, безусловно, ускорит процесс обучения.
Спасибо за ваши ответы.
Я думаю, что примеры лучше всего работают, но не каждый раз, правильно?!
Я выслушал создателя С++, когда он сказал, это требует времени и терпения, и вы поймете это лучше, пытаясь.