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