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