Mười nguyên tắc thiết kế hướng đối tượng mà một lập trình viên Java nên biết

Các nguyên tắc Thiết kế hướng đối tượng (OOD) là cốt lõi của Lập trình hướng đối tượng Java (OOP), nhưng tôi thấy hầu hết các lập trình viên Java làm việc với các mẫu Singleton và Decorator ... hoặc "Observer" , và không chú ý đầy đủ đến việc nghiên cứu phân tích hướng đối tượng và thiết kế. Tất nhiên, điều quan trọng là phải tìm hiểu những điều cơ bản về OOP : trừu tượng, đóng gói, đa hình và kế thừa, nhưng đồng thời, điều quan trọng không kém là phải biết các nguyên tắc thiết kế để tạo ra các sản phẩm có cấu trúc tốt và dễ hiểu. Tôi liên tục quan sát các lập trình viên, nhà phát triển ở nhiều cấp độ khác nhau, những người chưa nghe nói về nguyên tắc SOLID OOD hoặc đơn giản là không biết về những lợi thế mà nguyên tắc thiết kế này hoặc nguyên tắc thiết kế kia mang lại hoặc cách áp dụng nó trong mã. Tóm lại, hãy luôn cố gắng đạt được sự mạch lạc trong mã và thiết kế tốt trong giải pháp của bạn. Các ví dụ tuyệt vời để học Java và OOD là Apache và Sun mã nguồn mở. Chúng chứng minh cách sử dụng các nguyên tắc OOD khi viết mã trong các chương trình Java. Minh họa việc sử dụng các mẫu trong JDK: Factory, mẫu “factory” trong lớp BorderFactory , Mẫu thiết kế Factory là gì... , mẫu Singleton, “singleton”, trong lớp Runtime RunTime , mẫu Decorator, “trang trí”, trong các lớp java.io khác nhau. Nhân tiện, nếu bạn quan tâm đến việc thực hành mã java, hãy đọc Java hiệu quả, Joshua Bloch (ví dụ: Java hiệu quả được dịch sang tiếng Nga ), một kiệt tác của tác giả Java API. Ngoài ra, về chủ đề OOD và các mẫu, tôi khuyên dùng Mẫu thiết kế đầu tiên, cũng như Phân tích và thiết kế hướng đối tượng đầu tiên. Những cuốn sách này sẽ giúp bạn viết mã tốt hơn bằng cách tận dụng các nguyên tắc OOD. Mặc dù cách tốt nhất để học bất kỳ nguyên tắc nào là thực hành và hiểu hậu quả của việc vi phạm chính những nguyên tắc này, nhưng chủ đề của bài viết này là phần giới thiệu về các nguyên tắc của OOD dành cho các lập trình viên Java chưa sử dụng chúng hoặc chỉ mới học ngôn ngữ. Tôi tin rằng mỗi nguyên tắc đã nêu của OOD ( SOLID ) xứng đáng có một bài viết riêng với phần giải thích chi tiết về bản chất và tôi sẽ cố gắng trong tương lai (viết những bài viết này - khoảng. dịch), nhưng hiện tại, hãy sẵn sàng để nhanh chóng vượt qua nó. 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, các phương thức có giá trị trả về hoặc các phương thức có tham số. Lời khuyên tương tự có trong sách Java và OOD hiệu quả. Nguyên tắc ủy quyền Đừng tự mình làm mọi việc mà hãy giao công việc cho lớp phù hợp. Một ví dụ trong sách giáo khoa về việc áp dụng nguyên tắc ủy quyền là việc sử dụng các phương thức Equals() và hashCode(). Để so sánh hai đối tượng, chúng ta để lớp tự thực hiện công việc thay vì để lớp khách kiểm tra. Ưu điểm của nguyên tắc này là tránh mã hóa kép và dễ dàng thay đổi hành vi. Tất cả những nguyên tắc thiết kế hướng đối tượng nêu trên sẽ giúp bạn viết code linh hoạt và tốt hơn, mạch lạc nhưng không có những kết nối không cần thiết. Lý thuyết là bước đầu tiên. Điều quan trọng nhất là phát triển khả năng phân tích nơi áp dụng các nguyên tắc OOD này. Hãy theo dõi để biết liệu bạn có đang vi phạm bất kỳ nguyên tắc nào, gây nguy hiểm cho tính linh hoạt của mã hay không. Đồng thời, không có gì là hoàn hảo, không thể luôn giải quyết vấn đề chỉ bằng cách áp dụng nguyên tắc OOD trong lập trình. Phần lớn chúng rất quan trọng đối với các giải pháp và dự án của công ty có chu kỳ hỗ trợ kỹ thuật dài.