ده اصل طراحی شی گرا که یک برنامه نویس جاوا باید بداند

اصول طراحی شی گرا (OOD) هسته اصلی برنامه نویسی شی گرا جاوا (OOP) است، اما من می بینم که اکثر برنامه نویسان جاوا با الگوهای Singleton و Decorator یا "Observer" کار می کنند و به مطالعه تجزیه و تحلیل شی گرا و توجه کافی نمی کنند. طرح. البته، یادگیری اصول اولیه OOP : انتزاع، کپسوله سازی، چندشکلی و وراثت بسیار مهم است، اما در عین حال، دانستن اصول طراحی برای ایجاد محصولاتی با ساختار و قابل درک به همان اندازه مهم است. من دائماً برنامه نویسان، توسعه دهندگان سطوح مختلف را مشاهده می کنم که یا در مورد اصول SOLID OOD چیزی نشنیده اند ، یا به سادگی از مزایایی که این یا آن اصل طراحی ارائه می دهد، یا نحوه اعمال آن در کد را نمی دانند. خط پایین، همیشه برای هماهنگی کد و طراحی خوب در راه حل خود تلاش کنید. نمونه های عالی برای یادگیری جاوا و OOD، آپاچی و سان منبع باز هستند. آنها نشان می دهند که چگونه اصول OOD باید در نوشتن کد در برنامه های جاوا استفاده شود. تصویر استفاده از الگوها در JDK: Factory، الگوی "factory" در کلاس BorderFactory ، الگوی طراحی Factory چیست... ، الگوی Singleton، "singleton"، در کلاس Runtime RunTime ، الگوی Decorator، "دکوراتور"، در کلاس های مختلف java.io. به هر حال، اگر به تمرین کد جاوا علاقه دارید، جاوا موثر، جاشوا بلوخ (به عنوان مثال، جاوا موثر ترجمه شده به روسی )، شاهکاری از نویسنده Java API را بخوانید. همچنین در مورد موضوع OOD و الگوها، Head First Design Pattern و همچنین Head First Object Oriented Analysis and Design را پیشنهاد می کنم. این کتاب ها با بهره گیری از اصول OOD به شما کمک می کنند تا کد بهتری بنویسید. اگرچه بهترین راه برای یادگیری هر یک از اصول، تمرین و درک عواقب نقض همین اصول است، موضوع این مقاله مقدمه ای بر اصول OOD برای برنامه نویسان جاوا است که هنوز از آن استفاده نمی کنند یا تازه در حال یادگیری زبان هستند. من معتقدم که هر یک از اصول بیان شده OOD ( SOLID ) شایسته یک مقاله جداگانه با توضیح مفصل در مورد ماهیت است و در آینده تلاش خواهم کرد (برای نوشتن این مقالات - تقریباً ترجمه)، اما در حال حاضر، آماده شوید تا به سرعت از آن عبور کنید. 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа، متدهایی با مقدار بازگشتی یا متدهایی با پارامترها. همین توصیه در کتاب های Effective Java و OOD آمده است. اصل تفویض اختیار همه کارها را خودتان انجام ندهید، کار را به صنف مناسب محول کنید. یک نمونه کتاب درسی برای اعمال اصل تفویض، استفاده از متدهای ()quals و ()hashCode است. برای مقایسه دو شی، به جای اینکه بررسی را به کلاس کلاینت بسپاریم، به کلاس اجازه می دهیم خودش کار را انجام دهد. مزیت این اصل این است که از کدگذاری مضاعف جلوگیری می کند و تغییر رفتار را آسان می کند. تمام اصول فوق در طراحی شی گرا به شما کمک می کند تا کدی انعطاف پذیر و بهتر، منسجم، اما بدون اتصالات غیر ضروری بنویسید. تئوری اولین قدم است. مهمترین چیز توسعه توانایی تجزیه و تحلیل این اصول OOD است. تماشا کنید تا ببینید آیا شما هر یک از اصول را زیر پا می گذارید و انعطاف پذیری کد خود را به خطر می اندازد. در عین حال، هیچ چیز کامل نیست؛ حل مشکلات همیشه تنها با به کارگیری اصول OOD در برنامه نویسی غیرممکن است. آنها در بیشتر موارد برای راه حل های شرکتی و پروژه هایی با چرخه پشتیبانی فنی طولانی حیاتی هستند.