Sepuluh Prinsip Desain Berorientasi Objek sing Kudu Dingerteni Programmer Jawa

Prinsip Desain Berorientasi Objek (OOD) minangka inti saka Java Object Oriented Programming (OOP), nanging aku weruh umume programer Java nggarap pola Singleton lan Decorator . desain. Mesthine, penting kanggo sinau dasar-dasar OOP : abstraksi, enkapsulasi, polimorfisme lan warisan, nanging ing wektu sing padha, penting kanggo ngerti prinsip desain supaya bisa nggawe produk sing terstruktur lan bisa dingerteni. Aku terus-terusan mirsani programer, pangembang saka macem-macem tingkat sing salah siji durung krungu bab prinsip SOLID OOD , utawa mung ora ngerti bab kaluwihan sing iki utawa prinsip desain nyedhiyani, utawa carane aplikasi ing kode. Ing ngisor iki, tansah ngupayakake koherensi kode lan desain sing apik ing solusi sampeyan. Conto apik kanggo sinau Jawa lan OOD yaiku open source Apache lan Sun. Padha nduduhake carane prinsip OOD kudu digunakake ing nulis kode ing program Jawa. Ilustrasi panggunaan pola ing JDK: Pabrik, pola "pabrik" ing kelas BorderFactory , Apa pola desain Pabrik ... , pola Singleton, "singleton", ing kelas Runtime RunTime , pola Decorator, "dekorator", ing macem-macem kelas java.io. Miturut cara, yen sampeyan kasengsem ing laku kode java, maca Jawa Efektif, Joshua Bloch (contone, Jawa Efektif diterjemahake menyang Rusian ), masterpiece saka penulis Java API. Uga ing topik OOD lan pola, aku nyaranake Head First Design Pattern, uga Head First Object Oriented Analysis and Design. Buku iki bakal mbantu sampeyan nulis kode sing luwih apik kanthi nggunakake prinsip OOD. Sanajan cara paling apik kanggo sinau prinsip apa wae yaiku praktek lan ngerti akibat saka nglanggar prinsip kasebut, topik artikel iki minangka pambuka kanggo prinsip OOD kanggo programer Jawa sing durung nggunakake utawa mung sinau basa. Aku percaya yen saben prinsip OOD ( SOLID ) sing wis kasebut pantes kanggo artikel sing kapisah kanthi panjelasan rinci babagan inti, lan aku bakal nyoba ing mangsa ngarep (kanggo nulis artikel kasebut - kira-kira transl.), nanging saiki, siyap-siyap mung cepet liwat. 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, metode kanthi nilai bali, utawa metode kanthi paramèter. Pitutur sing padha ana ing buku Jawa Efektif lan OOD. Prinsip Delegasi Aja nindakake kabeh dhewe, tugasake tugas menyang kelas sing cocog. Conto buku teks kanggo ngetrapake prinsip delegasi yaiku nggunakake metode sing padha () lan kode hash (). Kanggo mbandhingaké loro obyek, kita supaya kelas nindakake karya dhewe, tinimbang ninggalake mriksa kanggo kelas klien. Kauntungan saka prinsip iki yaiku ngindhari kodhe ganda lan gampang ngganti prilaku. Kabeh prinsip desain berorientasi obyek ing ndhuwur bakal mbantu sampeyan nulis kode sing fleksibel lan luwih apik, koheren, nanging tanpa sambungan sing ora perlu. Teori minangka langkah pisanan. Sing paling penting yaiku ngembangake kemampuan kanggo nganalisa ing endi prinsip OOD kasebut ditrapake. Nonton kanggo ndeleng yen sampeyan nglanggar salah sawijining prinsip, mbebayani keluwesan kode sampeyan. Ing wektu sing padha, ora ana sing sampurna; ora mungkin kanggo ngatasi masalah mung kanthi ngetrapake prinsip OOD ing pemrograman. Dheweke kritis, umume, kanggo solusi lan proyek perusahaan kanthi siklus dhukungan teknis sing dawa.