Dziesięć zasad projektowania obiektowego, które powinien znać programista Java

Zasady projektowania obiektowego (OOD) stanowią rdzeń programowania obiektowego w języku Java (OOP), ale widzę, że większość programistów Java pracuje ze wzorcami Singleton i Decorator lub „Observer” i nie zwraca wystarczającej uwagi na studiowanie analizy obiektowej i projekt. Oczywiście ważne jest poznanie podstaw OOP : abstrakcji, enkapsulacji, polimorfizmu i dziedziczenia, ale jednocześnie równie ważna jest znajomość zasad projektowania, aby tworzyć dobrze ustrukturyzowane i zrozumiałe produkty. Stale obserwuję programistów, programistów na różnym poziomie, którzy albo nie słyszeli o zasadach SOLID OOD , albo po prostu nie wiedzą o zaletach, jakie zapewnia ta czy inna zasada projektowania lub jak zastosować ją w kodzie. Podsumowując, zawsze staraj się zapewnić spójność kodu i dobry projekt swojego rozwiązania. Świetnymi przykładami nauki języka Java i OOD są Apache i Sun o otwartym kodzie źródłowym. Pokazują, jak należy stosować zasady OOD przy pisaniu kodu w programach Java. Ilustracja wykorzystania wzorców w JDK: Factory, wzorzec „factory” w klasie BorderFactory , Co to jest wzorzec projektowy Factory... , wzorzec Singleton, „singleton”, w klasie Runtime RunTime , wzorzec Decorator, „dekorator” w różnych klasach Java.io. Przy okazji, jeśli interesuje Cię praktyka kodowania w Javie, przeczytaj Efektywna Java, Joshua Bloch (na przykład Efektywna Java przetłumaczona na język rosyjski ), arcydzieło autora API Java. Również w temacie OOD i wzorców polecam Head First Design Pattern, a także Head First Object Oriented Analysis and Design. Książki te pomogą Ci napisać lepszy kod, korzystając z zasad OOD. Choć najlepszym sposobem na poznanie jakichkolwiek zasad jest praktyka i zrozumienie konsekwencji naruszenia tych właśnie zasad, tematem tego artykułu jest wprowadzenie do zasad OOD dla programistów Java, którzy jeszcze z nich nie korzystają lub dopiero uczą się języka. Uważam, że każda z podanych zasad OOD ( SOLID ) zasługuje na oddzielny artykuł ze szczegółowym wyjaśnieniem istoty i postaram się w przyszłości (napisać te artykuły - ok. tłum.), ale na razie przygotuj się, aby szybko to omówić. DRY (Не повторяйтесь) Первым принципом обозначим «не повторяйтесь», что значит, не пишите повторяющегося kodа, используйте принцип абстракции, обобщая простые вещи в одном месте. Если у вас присутствует один и тот же блок kodа более, чем в двух местах, подумайте об отдельном методе для него. Если есть константа для многоразового использования, создайте глобальную переменную с модификаторами public final. Большим преимуществом использования данного принципа является легкость дальнейшей технической поддержки. Важно также не злоупотреблять этим принципом, когда, к примеру, повторение kodа существует не для самого kodа, а для реализации функциональности. Например, когда вы проверяете OrderID и SSN, это не значит, что они идентичны Lub станут таковыми в будущем. Используя одинаковый kod для двух разных функций Lub элементов, вы связываете их тесно, и когда OrderID поменяет формат, kod проверки SSN перестанет работать. Имейте в виду такие связки и не комбинируйте все подряд, что использует схожий kod, но на самом деле, не является связанным. Инкапсулируйте то, что меняется Одна вещь постоянна в мире программного обеспечения — изменение. Инкапсулируйте kod, который в будущем будет меняться. Преимущество принципа в легкости тестирования и поддержки надлежащим образом инкапсулированного kodа. При написании программ на java следуйте, по умолчанию, правилу создания переменных и методов с модификатором доступа private, расширяя доступ шаг за шагом, от private к protected, но не public. Несколько принципов дизайна java используют инкапсуляцию, паттерн Factory — хороший пример, где kod создания obiektов инкапсулирован и достаточно гибок, чтобы позже создавать новые obiektы, но без воздействия на существующий kod. Открыто-закрытый принцип дизайна Классы, методы, функции должны быть открыты для расширения (новой функциональности) и закрыты для модификации. Это отличный принцип из набора SOLID, соответствующий букве «О», предотвращающий изменение протестированного и работающего kodа. Идеально, если вы добавляете новую функциональность только, когда ваш kod должен тестироваться, и в этом цель этого принципа ООД. Принцип уникальной ответственности (SRP) SRP соответствует букве S в SOLID и означает, что не должно существовать более 1 причины для изменения класса, иными словами, класс должен обладать уникальной функциональностью. Если один класс java реализует 2 набора функций, их сцепление создает ситуацию, при которой изменение одного нарушит имеющееся сочетание, что потребует нового раунда тестирования во избежание сюрпризов при использовании программ. Внедрение зависимостей (DI) Lub принцип инверсии управления (IOC) Не просите зависимости, фреймворк вам её обеспечит. Этот принцип отлично реализован в фреймворке Spring. Прелесть принципа в том, что любой класс с внедренной зависимостью (DI, часть фреймворка Spring), легко тестировать с помощью obiektа-муляжа и легко поддерживать, потому что kod, создающий obiekt, инкапсулирован в фреймворке, и не смешивается с клиентским kodом. Существует множество способов внедрять зависимости, например, используя инструментарий в bajt-kodе от фреймворков аспектно-ориентированного программирования типа AspectJ Lub используя прокси, Jak в Spring. Посмотрите этот пример использования принципа DI & IOC, представляющего букву D в аббревиатуре SOLID. Предпочитайте структуру наследованию Всегда ставьте на первое место структуру, композицию, если возможно. Кто-то может спорить с этим утверждением, но я нахожу, что приоритет композиции - гораздо более гибкий подход, чем реализация через наследование. Композиция позволяет изменить поведение класса во время исполнения, задавая свойства в текущем режиме. Использование интерфейсов для создания класса, применение полиморфизма, дает нам гибкость в улучшении реализации каждый раз. Даже в книге Effective Java говорится о преимуществе композиции над наследованием. Принцип подстановки Лисков (LSP) Согласно принципу LSP, буква L в SOLID, функции, которые используют ссылки на базовые классы, должны иметь возможность использовать obiektы производных классов, не зная об этом. LSP тесно связан с принципом уникальной ответственности и принципом разделения интерфейсов. Если у базового класса больше функциональности, чем у производного, такое соотношение нарушает принцип LSP. Coбы следовать этому принципу, производный класс Lub подкласс должен расширять функциональность, а не сужать её. Принцип разделения интерфейсов (ISP) Данный принцип гласит, что класс не должен внедрять интерфейс ( Co такое интерфейс в Java...) , если интерфейс не используется. В основном, такое происходит, когда интерфейс многофункциональный, а класс требует только одной функциональности. Разработка интерфейсов — сложная работа, реализовав интерфейс, трудно изменить его без изменения всей реализации. Другое преимущество использования принципа ISP заключается в том, что интерфейс внедряет методы до того, Jak Jakой-либо класс может их использовать, поэтому уникальная функциональность требует внедрения меньшего количества методов. Программирование для интерфейса, а не реализации «Всегда программируйте для интерфейса, а не реализации.» Следование этому принципу приведет вас к гибкому kodу, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, metody z wartością zwracaną lub metody z parametrami. Ta sama rada jest zawarta w książkach Skuteczna Java i OOD. Zasada delegowania Nie rób wszystkiego sam, przydziel pracę odpowiedniej klasie. Podręcznikowym przykładem zastosowania zasady delegowania jest zastosowanie metod równości() i hashCode(). Aby porównać dwa obiekty, pozwalamy klasie wykonać pracę samodzielnie, zamiast pozostawiać sprawdzenie klasie klienta. Zaletą tej zasady jest to, że pozwala uniknąć podwójnego kodowania i ułatwia zmianę zachowania. Wszystkie powyższe zasady projektowania obiektowego pomogą Ci napisać kod elastyczny i lepszy, spójny, ale bez zbędnych połączeń. Teoria to pierwszy krok. Najważniejsze jest rozwinięcie umiejętności analizowania, gdzie obowiązują te zasady OOD. Obserwuj, czy nie naruszasz którejś z zasad, zagrażając elastyczności swojego kodu. Jednocześnie nic nie jest idealne, nie da się zawsze rozwiązać problemów jedynie stosując zasady OOD w programowaniu. Są one w większości krytyczne dla rozwiązań korporacyjnych i projektów z długim cyklem wsparcia technicznego.