Как мне выйти из привычки процедурного программирования и в объектно-ориентированное программирование?

Я думаю, вы должны убедить себя, исследуя все недостатки процедурного программирования, например (некоторые умные слова следуют, следите): область действия, состояние ... практически вы сможете извлечь много терминов, просто читая примеры шаблонов проектирования (читай: общие примеры совместного использования объектов).

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

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

Из многих концепций в объектно-ориентированном программировании основной, которая будет держать вас как новичка, является инкапсуляция. Мой класс знает, как позаботиться о себе? Есть ли в моем классе поведение? Если этого не произойдет, то у вас нет класса, у вас есть структура, и вы, вероятно, будете писать множество процедур для изменения его состояния (как говорится, «вы вернулись к написание C на Java "). Разве мой класс только публично предоставляет методы, необходимые для его использования? Эти вопросы, возможно, не очень тщательно прорабатываются, но, возможно, следует учитывать этот мысленный эксперимент при разработке ваших классов: что, если каждый из классов вашего приложения должен разрабатываться и поддерживаться другим разработчиком в Интернете, и классы также должны взаимодействовать друг с другом через интернет. Согласится ли каждый разработчик с тем, что класс, который они пишут и поддерживают, соответствует принципу единой ответственности , и поэтому был бы рад, что они не поддерживают код, который должен быть кем-то еще?

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

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

Мышление ОО основано на принципах, лежащих на гораздо более базовом уровне, чем шаблоны проектирования. Шаблоны проектирования как-то модны в наши дни (и были на какое-то время), и они полезны , но это всего лишь еще один слой, который вы можете нанести на более простые вещи, которые вы обязательно должны изучить и мастер , если вы хотите сделать OO правильно. Другими словами: вы можете сделать ОО идеально без шаблонов дизайна. На самом деле, многие из нас сделали OO задолго до того, как появилась фраза «шаблоны проектирования»

Теперь есть вещи, без которых вы не можете обойтись. Я предлагаю вам начать с основ. Прочитайте и поймите «Построение объектно-ориентированного программного обеспечения», 2-е издание, Бертран Мейер . Вероятно, это лучшая книга о программировании ОО, как по ширине, так и по глубине. Это если вы заинтересованы в программировании .

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

"Put stuff together that changes together."

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

Это также известно как «Изменение скорости».

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

Фрагменты кода часто имеют одинаковые скорости изменения, если они получают доступ к общему представлению. Каждый раз, когда меняется представление, все части кода, которые его используют, должны меняться сразу. Это одна из причин, по которой мы используем объекты в качестве модулей для инкапсуляции представления. Отделение интерфейса от реализации также имеет смысл в этом руководстве - реализация меняется чаще и, следовательно, имеет более высокую скорость изменения.

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

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

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

Я сталкивался с этой концепцией в C2 wiki много лет назад , но с тех пор я редко видел, чтобы она использовалась. Я нахожу это очень полезным. Он выражает некоторую основополагающую мотивацию объектно-ориентированного дизайна. Конечно, поэтому это ослепительно очевидно.

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

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

PS: другой принцип, которому вы должны следовать, это «Закон Деметры», то есть объект должен говорить только со своими друзьями. Друзья: вы, переменные экземпляра, параметры, локальные объекты и члены дружественных коллекций, но не глобальные и статические переменные.

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

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

3. Процедура - правильный инструмент для некоторых работ. Не веди себя так, будто это неправильно. ИМХО все три основные парадигмы (процедурная, ОО, функциональные) ценны даже на мелкомасштабном уровне, в рамках одного модуля . Я предпочитаю:

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

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

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

Я думаю, что сначала важно изучить теорию. Так что чтение книги будет хорошим началом.

Изучите новый язык, тот, который помогает вы нежно к ООП. Java хороша, но немного раздута. Но его системная библиотека в основном объектно-ориентированная, поэтому вы вынуждены использовать объекты. Переход на другой язык также поможет вам , а не повторно использовать старый код: -)

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

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

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

Это отнимает очень много времени, и вам нужно сначала изучить основы ООП (у С.Лотта есть отличные ссылки в другом ответе). Постоянный рефакторинг и много "Doh!" моменты - это правило; но я нашел это отличным способом изучить модульное программирование, потому что все, что я делал, было сразу заметно при реализации одного из проектов.

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

Также чтение о шаблонах и моделировании данных даст вам больше идей о кодировании вашей логики в стиле ООП.

Я обнаружил, что одной из вещей, которые действительно помогли мне закрепить преимущества ООП, было написание модульных тестов с использованием фреймворка имитирующих объектов (например, EasyMock ). Как только вы начнете разрабатывать таким образом, вы увидите, как классы помогают изолировать модули за интерфейсами, а также упрощают тестирование.

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

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

Посмотрите, как это сработает для вас.

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

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

На самом деле ООП - это простой предмет, который становится чрезвычайно сложным. К сожалению, в C ++ много проблем, но важны действительно простые виртуальные методы. Чистые виртуальные базовые классы, используемые во многом так же, как объект интерфейса java, являются наиболее полезными, но также и простые виртуальные методы здесь и там пригодятся.

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

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

Когда вы будете готовы сделать следующий шаг, возьмите книгу Design Patterns и выучите некоторые термины ООП-дизайна. Это не является строго необходимым, но даст вам лучшее представление о некоторых типичных проблемах и решениях.

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

Изначально он был разработан. в качестве обучающего инструмента для объектно-ориентированной мысли и может сработать для вас. Исходный документ находится по адресу: http://c2.com/doc/oopsla89/paper.html

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

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

б) Раньше я преподавал в университете курс объектно-ориентированного программирования, используя Smalltalk, и студенты отлично доказали эту старую шутку о том, что «вы можете писать FORTRAN на любом языке».

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

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

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

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

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

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

Шаг 1. Прочтите хорошую книгу о шаблонах проектирования. http://www.oodesign.com/

Шаг 2. Выберите то, что вы уже знаете, и переработайте его с точки зрения объектно-ориентированного подхода. Это подход Code Dojo. Возьмите задачу, которую вы уже понимаете, и определите классы объектов.

Я сделал это - и записал, что я сделал.

См. http://homepage.mac.com/s_lott/books/ oodesign.html # book-oodesign

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