Sepuluh Prinsip Reka Bentuk Berorientasikan Objek Yang Patut Tahu Pengaturcara Java

Prinsip Reka Bentuk Berorientasikan Objek (OOD) ialah teras Pengaturcaraan Berorientasikan Objek Java (OOP), tetapi saya melihat kebanyakan pengaturcara Java bekerja dengan corak Singleton dan Decorator . atau "Pemerhati" , dan tidak memberi perhatian yang cukup untuk mengkaji analisis berorientasikan objek dan reka bentuk. Sudah tentu, adalah penting untuk mempelajari asas-asas OOP : abstraksi, enkapsulasi, polimorfisme dan pewarisan, tetapi pada masa yang sama, adalah sama penting untuk mengetahui prinsip reka bentuk untuk mencipta produk yang tersusun dan mudah difahami. Saya sentiasa memerhatikan pengaturcara, pembangun pelbagai peringkat yang sama ada tidak pernah mendengar tentang prinsip SOLID OOD , atau langsung tidak tahu tentang kelebihan yang diberikan oleh prinsip reka bentuk ini atau itu, atau cara menggunakannya dalam kod. Intinya, sentiasa berusaha untuk keselarasan kod dan reka bentuk yang baik dalam penyelesaian anda. Contoh hebat untuk mempelajari Java dan OOD ialah sumber terbuka Apache dan Sun. Mereka menunjukkan bagaimana prinsip OOD harus digunakan dalam menulis kod dalam program Java. Ilustrasi penggunaan corak dalam JDK: Kilang, corak "kilang" dalam kelas BorderFactory , Apakah corak reka bentuk Kilang... , corak Singleton, "singleton", dalam kelas Runtime RunTime , corak Decorator, "penghias", dalam pelbagai kelas java.io . Ngomong-ngomong, jika anda berminat untuk mempraktikkan kod java, baca Java Berkesan, Joshua Bloch (contohnya, Java Berkesan diterjemahkan ke dalam bahasa Rusia ), karya agung daripada pengarang API Java. Juga mengenai topik OOD dan corak, saya mengesyorkan Head First Design Pattern, serta Head First Object Oriented Analysis and Design. Buku ini akan membantu anda menulis kod yang lebih baik dengan memanfaatkan prinsip OOD. Walaupun cara terbaik untuk mempelajari mana-mana prinsip adalah dengan mengamalkan dan memahami akibat melanggar prinsip ini, topik artikel ini ialah pengenalan kepada prinsip OOD untuk pengaturcara Java yang belum menggunakannya atau baru belajar bahasa. Saya percaya bahawa setiap prinsip OOD ( SOLID ) yang dinyatakan adalah layak untuk artikel berasingan dengan penjelasan terperinci tentang intipati, dan saya akan cuba pada masa hadapan (untuk menulis artikel ini - lebih kurang transl.), tetapi buat masa ini, bersiap sedia untuk menyelesaikannya dengan cepat. 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, kaedah dengan nilai pulangan, atau kaedah dengan parameter. Nasihat yang sama terkandung dalam buku Java Efektif dan OOD. Prinsip Delegasi Jangan lakukan semuanya sendiri, serahkan kerja kepada kelas yang sesuai. Contoh buku teks untuk menggunakan prinsip delegasi ialah penggunaan kaedah equals() dan hashCode(). Untuk membandingkan dua objek, kami membiarkan kelas melakukan kerja itu sendiri, dan bukannya menyerahkan semakan kepada kelas pelanggan. Kelebihan prinsip ini ialah ia mengelakkan pengekodan berganda dan menjadikannya mudah untuk menukar tingkah laku. Semua prinsip reka bentuk berorientasikan objek di atas akan membantu anda menulis kod yang fleksibel dan lebih baik, koheren, tetapi tanpa sambungan yang tidak perlu. Teori adalah langkah pertama. Perkara yang paling penting ialah membangunkan keupayaan untuk menganalisis di mana prinsip OOD ini digunakan. Tonton untuk melihat sama ada anda melanggar mana-mana prinsip, menjejaskan fleksibiliti kod anda. Pada masa yang sama, tiada yang sempurna; adalah mustahil untuk sentiasa menyelesaikan masalah hanya dengan menggunakan prinsip OOD dalam pengaturcaraan. Mereka adalah kritikal, untuk sebahagian besar, untuk penyelesaian korporat dan projek dengan kitaran sokongan teknikal yang panjang.