Научиться думать об объектно-ориентированном способе

Я программист, пытающийся научиться кодировать в объектно-ориентированной парадигме... Я в основном работаю с PHP, и я думал об изучении рамки zend... Итак, я почувствовал, что мне нужно научиться кодировать в OO PHP....

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

Также чувствовал, что, вероятно, я не единственный, кто сталкивается с этой проблемой с самого начала...

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

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

Спасибо, что поделились своими знаниями и опытом...

Ответ 1

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

Я бы порекомендовал использовать следующие методы, которые, если они применяются либерально, заставят вас использовать методы OO, даже если вы еще не знаете о них.

Не копируйте и не вставляйте код - никогда.
Создавайте классы, которые представляют то, о чем вы говорите, когда говорите о функциональности - например, система ввода заказов будет иметь Заказы, Клиенты, Учетные записи, OrderItems, InventoryItems и т.д.
При создании этих классов НЕ программируйте какой-либо общедоступный набор и получайте методы доступа к членам данных класса.
Добавьте методы к этим классам моделей домена, которые выполняют работу над объектом. Order.invoice(), account.close(), InventoryItem.decrement(). Отсутствие методов публичного доступа покажет вам правильное местоположение для кода (где данные - в соответствующем объекте домена). Помните, что объектом являются данные и код, который работает на нем - что-то не так, как обоим, не является объектом.
В конечном итоге вы обнаружите, что вам нужно добавить некоторые общедоступные методы получения для некоторых членов класса, и это нормально, просто держитесь, пока вы не будете вынуждены это делать. Неохотно добавьте общедоступные методы получения.
На уровне приложения почти каждая строка кода должна перемещать горы. Другими словами, большинство строк кода на уровне приложения должны вызывать методы модели домена.
Поместите всю функциональность в объекты модели домена, а затем продемонстрируйте эту функциональность в приложении, подключив ее к пользовательскому интерфейсу. Повторяю, добавьте функциональность в модель домена, а не в приложение.

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

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

Удачи!

Ответ 2

Читайте код других людей - люди, которые вы знаете, являются хорошими разработчиками.
Книги/статьи, которые учат "идоматическому использованию" языка
(Избегайте слов со словами "через 21 день" )

Ответ 3

Требуется время.

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

Узнайте о основах ООП и продолжайте ссылаться на них, чтобы начать с них.
Прочитайте код OO - там есть много проектов с открытым исходным кодом, которые вы могли бы попробовать.

Ответ 4

прочитайте одну из следующих книг

2015_Book_Object-OrientedAnalysisDesignA
Эрик Фриман и Элизабет Фриман Смолл "Head First Design Patterns"
Head First Объектно-ориентированный анализ и проектирование: Руководство для мозговых специалистов по OOA & D

наслаждаться

Ответ 5

ССЫЛКИ PDF

1) Руководитель первого объектно-ориентированного анализа и проектирования

Руководитель первого объектно-ориентированного анализа и дизайна .pdf

2) Шаблоны Head First Design

Head First Design Patterns.pdf