Как практиковать объектно-ориентированное программирование? [закрыто]

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

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

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

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

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

Из-за этого, каков хороший способ практиковать объектную ориентацию?

Теперь в объектной ориентации у нас много дополнительных вещей.

Нет, ты не ...

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

Ничего из этого не нужно для практики объектно-ориентированного программирования.

Это было довольно легко, нужно было придумать алгоритм регистрации какого-либо пользователя, авторизации пользователя и добавления продуктов.

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

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

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

Хороший вопрос. Конечно, вы говорите, что практика ООП на самом деле означает практиковать все эти вещи (анализ требований, варианты использования, шаблоны проектирования и т. Д.), Что верно и на первый взгляд может показаться утомительным.

Мой совет - начать практические занятия, помня о двух вещах: разработка через тестирование и принцип единой ответственности .

Затем просто начните, как вы это делали с PHP / C: придумайте идею, подумайте, что вам нужно для этого, и реализуйте эти вещи один за другим. Однако имейте в виду, что вам нужно начинать с тестов (что вынуждает вас определять надлежащие интерфейсы, поскольку в противном случае тестируемость сразу же страдает) и что TDD подразумевает цикл красно-зеленого-рефакторинга. Другими словами, у вас есть чуть-чуть функциональности, и как только он заработает, вы реорганизуетесь, чтобы получить правильный ОО-дизайн, если вы не сделали его с самого начала (чего не будет).

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

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

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

Это поможет вам лучше понять отношения IS-A и HAS-A , которые, вероятно, являются наиболее важной классификацией в любом проекте ООП (и, несмотря на это, кажется, что многие опытные программисты на ООП по-прежнему сталкиваются с этим ). Если вы овладеете IS-A / HAS-A, вы также получите IS-IMPLEMENTED-IN-TERMS-OF (которую я также видел описанной как IS-KIND-OF-A: ^)

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

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

Что касается ООП, то все дело в практике и стремлении к улучшению. Редко кто-то понимает это с нуля. Таким образом, итерации происходят в течение всего жизненного цикла проекта.

Давайте добавим терминологию, объектно-ориентированный анализ и объектно-ориентированное проектирование , как это сделал Питер Коад в 1990-х годах.

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

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

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

«Ну, просто на практике, позвольте мне создать одно приложение с областью администрирования, где люди могут добавлять продукты». Это было довольно легко, нужно было придумать алгоритм регистрации какого-либо пользователя, авторизации пользователя и добавления продуктов.

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