Dieci principi di progettazione orientata agli oggetti che un programmatore Java dovrebbe conoscere

I principi della progettazione orientata agli oggetti (OOD) sono il nucleo della programmazione orientata agli oggetti Java (OOP), ma vedo la maggior parte dei programmatori Java lavorare con i modelli Singleton e Decorator o "Observer" e non prestare sufficiente attenzione allo studio dell'analisi orientata agli oggetti e progetto. Certo, è importante apprendere le basi dell'OOP : astrazione, incapsulamento, polimorfismo ed ereditarietà, ma allo stesso tempo è altrettanto importante conoscere i principi del design per creare prodotti ben strutturati e comprensibili. Osservo costantemente programmatori, sviluppatori di vari livelli che non hanno sentito parlare dei principi SOLID OOD o semplicemente non conoscono i vantaggi offerti da questo o quel principio di progettazione o come applicarlo nel codice. In conclusione, cerca sempre la coerenza del codice e una buona progettazione nella tua soluzione. Ottimi esempi per imparare Java e OOD sono Apache e Sun open source. Dimostrano come i principi OOD dovrebbero essere utilizzati nella scrittura del codice nei programmi Java. Illustrazione dell'uso dei pattern nel JDK: Factory, il pattern “factory” nella classe BorderFactory , Cos'è il design pattern Factory... , il pattern Singleton, “singleton”, nella classe Runtime RunTime , il pattern Decorator, “decoratore”, in varie classi java.io. A proposito, se sei interessato a praticare il codice Java, leggi Effective Java, Joshua Bloch (ad esempio, Effective Java tradotto in russo ), un capolavoro dell'autore dell'API Java. Sempre in tema di OOD e pattern, consiglio Head First Design Pattern, così come Head First Object Oriented Analysis and Design. Questi libri ti aiuteranno a scrivere codice migliore sfruttando i principi OOD. Sebbene il modo migliore per apprendere qualsiasi principio sia esercitarsi e comprendere le conseguenze della violazione di questi stessi principi, l'argomento di questo articolo è un'introduzione ai principi dell'OOD per i programmatori Java che non li utilizzano ancora o stanno appena imparando il linguaggio. Credo che ciascuno dei principi dichiarati di OOD ( SOLID ) meriti un articolo separato con una spiegazione dettagliata dell'essenza, e proverò in futuro (a scrivere questi articoli - trad. ca.), ma per ora, preparati a esaminarlo rapidamente. DRY (Не повторяйтесь) Первым принципом обозначим «не повторяйтесь», что значит, не пишите повторяющегося codeа, используйте принцип абстракции, обобщая простые вещи в одном месте. Если у вас присутствует один и тот же блок codeа более, чем в двух местах, подумайте об отдельном методе для него. Если есть константа для многоразового использования, создайте глобальную переменную с модификаторами public final. Большим преимуществом использования данного принципа является легкость дальнейшей технической поддержки. Важно также не злоупотреблять этим принципом, когда, к примеру, повторение codeа существует не для самого codeа, а для реализации функциональности. Например, когда вы проверяете OrderID и SSN, это не значит, что они идентичны or станут таковыми в будущем. Используя одинаковый code для двух разных функций or элементов, вы связываете их тесно, и когда OrderID поменяет формат, code проверки SSN перестанет работать. Имейте в виду такие связки и не комбинируйте все подряд, что использует схожий code, но на самом деле, не является связанным. Инкапсулируйте то, что меняется Одна вещь постоянна в мире программного обеспечения — изменение. Инкапсулируйте code, который в будущем будет меняться. Преимущество принципа в легкости тестирования и поддержки надлежащим образом инкапсулированного codeа. При написании программ на java следуйте, по умолчанию, правилу создания переменных и методов с модификатором доступа private, расширяя доступ шаг за шагом, от private к protected, но не public. Несколько принципов дизайна java используют инкапсуляцию, паттерн Factory — хороший пример, где code создания an objectов инкапсулирован и достаточно гибок, чтобы позже создавать новые an objectы, но без воздействия на существующий code. Открыто-закрытый принцип дизайна Классы, методы, функции должны быть открыты для расширения (новой функциональности) и закрыты для модификации. Это отличный принцип из набора SOLID, соответствующий букве «О», предотвращающий изменение протестированного и работающего codeа. Идеально, если вы добавляете новую функциональность только, когда ваш code должен тестироваться, и в этом цель этого принципа ООД. Принцип уникальной ответственности (SRP) SRP соответствует букве S в SOLID и означает, что не должно существовать более 1 причины для изменения класса, иными словами, класс должен обладать уникальной функциональностью. Если один класс java реализует 2 набора функций, их сцепление создает ситуацию, при которой изменение одного нарушит имеющееся сочетание, что потребует нового раунда тестирования во избежание сюрпризов при использовании программ. Внедрение зависимостей (DI) or принцип инверсии управления (IOC) Не просите зависимости, фреймворк вам её обеспечит. Этот принцип отлично реализован в фреймворке Spring. Прелесть принципа в том, что любой класс с внедренной зависимостью (DI, часть фреймворка Spring), легко тестировать с помощью an object-муляжа и легко поддерживать, потому что code, создающий an object, инкапсулирован в фреймворке, и не смешивается с клиентским codeом. Существует множество способов внедрять зависимости, например, используя инструментарий в byte-codeе от фреймворков аспектно-ориентированного программирования типа AspectJ or используя прокси, How в Spring. Посмотрите этот пример использования принципа DI & IOC, представляющего букву D в аббревиатуре SOLID. Предпочитайте структуру наследованию Всегда ставьте на первое место структуру, композицию, если возможно. Кто-то может спорить с этим утверждением, но я нахожу, что приоритет композиции - гораздо более гибкий подход, чем реализация через наследование. Композиция позволяет изменить поведение класса во время исполнения, задавая свойства в текущем режиме. Использование интерфейсов для создания класса, применение полиморфизма, дает нам гибкость в улучшении реализации каждый раз. Даже в книге Effective Java говорится о преимуществе композиции над наследованием. Принцип подстановки Лисков (LSP) Согласно принципу LSP, буква L в SOLID, функции, которые используют ссылки на базовые классы, должны иметь возможность использовать an objectы производных классов, не зная об этом. LSP тесно связан с принципом уникальной ответственности и принципом разделения интерфейсов. Если у базового класса больше функциональности, чем у производного, такое соотношение нарушает принцип LSP. Whatбы следовать этому принципу, производный класс or подкласс должен расширять функциональность, а не сужать её. Принцип разделения интерфейсов (ISP) Данный принцип гласит, что класс не должен внедрять интерфейс ( What такое интерфейс в Java...) , если интерфейс не используется. В основном, такое происходит, когда интерфейс многофункциональный, а класс требует только одной функциональности. Разработка интерфейсов — сложная работа, реализовав интерфейс, трудно изменить его без изменения всей реализации. Другое преимущество использования принципа ISP заключается в том, что интерфейс внедряет методы до того, How Howой-либо класс может их использовать, поэтому уникальная функциональность требует внедрения меньшего количества методов. Программирование для интерфейса, а не реализации «Всегда программируйте для интерфейса, а не реализации.» Следование этому принципу приведет вас к гибкому codeу, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, metodi con un valore restituito o metodi con parametri. Lo stesso consiglio è contenuto nei libri Effective Java e OOD. Principio della delega Non fare tutto da solo, assegna il lavoro alla classe appropriata. Un esempio da manuale di applicazione del principio di delega è l'uso dei metodi equals() e hashCode(). Per confrontare due oggetti, lasciamo che sia la classe a fare il lavoro da sola, invece di lasciare il controllo alla classe client. Il vantaggio di questo principio è che evita la doppia codifica e facilita il cambiamento del comportamento. Tutti i principi sopra menzionati della progettazione orientata agli oggetti ti aiuteranno a scrivere codice flessibile e migliore, coerente, ma senza connessioni inutili. La teoria è il primo passo. La cosa più importante è sviluppare la capacità di analizzare dove si applicano questi principi OOD. Controlla se stai violando qualcuno dei principi, mettendo a repentaglio la flessibilità del tuo codice. Allo stesso tempo, nulla è perfetto; è impossibile risolvere sempre i problemi solo applicando i principi OOD nella programmazione. Sono fondamentali, per la maggior parte, per soluzioni e progetti aziendali con un lungo ciclo di supporto tecnico.