Sepuluh Prinsip Desain Berorientasi Objek yang Harus Diketahui Pemrogram Java

Prinsip Desain Berorientasi Objek (OOD) adalah inti dari Pemrograman Berorientasi Objek Java (OOP), tetapi saya melihat sebagian besar pemrogram Java bekerja dengan pola Singleton dan Dekorator atau "Observer" , dan tidak cukup memperhatikan mempelajari analisis berorientasi objek dan desain. Tentu saja, penting untuk mempelajari dasar-dasar OOP : abstraksi, enkapsulasi, polimorfisme, dan pewarisan, namun pada saat yang sama, juga sama pentingnya untuk mengetahui prinsip-prinsip desain untuk menciptakan produk yang terstruktur dengan baik dan mudah dipahami. Saya terus-menerus mengamati programmer, pengembang dari berbagai tingkatan yang belum pernah mendengar tentang prinsip SOLID OOD , atau tidak tahu tentang keuntungan yang diberikan oleh prinsip desain ini atau itu, atau bagaimana menerapkannya dalam kode. Intinya, selalu upayakan koherensi kode dan desain yang baik dalam solusi Anda. Contoh bagus untuk mempelajari Java dan OOD adalah Apache dan Sun yang open source. Mereka menunjukkan bagaimana prinsip-prinsip OOD harus digunakan dalam menulis kode dalam program Java. Ilustrasi penggunaan pola di JDK: Factory, pola “pabrik” di kelas BorderFactory , Apa yang dimaksud dengan pola desain Pabrik... , pola Singleton, “singleton”, di kelas Runtime RunTime , pola Dekorator, "dekorator", di berbagai kelas Java.io. Omong-omong, jika Anda tertarik untuk mempraktikkan kode java, baca Java Efektif, Joshua Bloch (misalnya, Java Efektif diterjemahkan ke dalam bahasa Rusia ), sebuah mahakarya dari penulis Java API. Juga mengenai topik OOD dan pola, saya merekomendasikan Pola Desain Head First, serta Analisis dan Desain Berorientasi Objek Head First. Buku-buku ini akan membantu Anda menulis kode yang lebih baik dengan memanfaatkan prinsip-prinsip OOD. Meskipun cara terbaik untuk mempelajari prinsip apa pun adalah dengan mempraktikkan dan memahami konsekuensi dari pelanggaran prinsip-prinsip tersebut, topik artikel ini adalah pengenalan prinsip-prinsip OOD untuk pemrogram Java yang belum menggunakannya atau baru mempelajari bahasa tersebut. Saya percaya bahwa masing-masing prinsip OOD ( SOLID ) yang dinyatakan layak untuk artikel terpisah dengan penjelasan rinci tentang esensinya, dan saya akan mencoba di masa depan (untuk menulis artikel ini - kira-kira terjemahan), tetapi untuk saat ini, bersiap-siap untuk segera mengatasinya. 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 dengan nilai kembalian, atau metode dengan parameter. Nasihat yang sama terdapat dalam buku Java Efektif dan OOD. Prinsip Pendelegasian Jangan melakukan segala sesuatunya sendiri, tugaskan pekerjaan tersebut pada kelas yang sesuai. Contoh buku teks yang menerapkan prinsip delegasi adalah penggunaan metode sama dengan() dan kode hash(). Untuk membandingkan dua objek, kita membiarkan kelas melakukan pekerjaannya sendiri, daripada menyerahkan pengecekan ke kelas klien. Keuntungan dari prinsip ini adalah menghindari pengkodean ganda dan memudahkan perubahan perilaku. Semua prinsip desain berorientasi objek di atas akan membantu Anda menulis kode yang fleksibel dan lebih baik, koheren, tetapi tanpa koneksi yang tidak perlu. Teori adalah langkah pertama. Yang paling penting adalah mengembangkan kemampuan menganalisis di mana prinsip-prinsip OOD ini berlaku. Perhatikan apakah Anda melanggar salah satu prinsip, sehingga membahayakan fleksibilitas kode Anda. Pada saat yang sama, tidak ada yang sempurna; tidak mungkin selalu menyelesaikan masalah hanya dengan menerapkan prinsip OOD dalam pemrograman. Umumnya, hal ini penting untuk solusi dan proyek perusahaan dengan siklus dukungan teknis yang panjang.