دس آبجیکٹ اورینٹڈ ڈیزائن کے اصول جاوا پروگرامر کو جاننا چاہیے۔

آبجیکٹ اورینٹڈ ڈیزائن (OOD) اصول جاوا آبجیکٹ اورینٹڈ پروگرامنگ (OOP) کا بنیادی حصہ ہیں، لیکن میں دیکھتا ہوں کہ زیادہ تر جاوا پروگرامرز سنگلٹن اور ڈیکوریٹر پیٹرن کے ساتھ کام کرتے ہیں ۔ ڈیزائن بلاشبہ، OOP کی بنیادی باتیں سیکھنا ضروری ہے: تجرید، انکیپسولیشن، پولیمورفزم اور وراثت، لیکن ساتھ ہی، اچھی ساخت اور قابل فہم مصنوعات بنانے کے لیے ڈیزائن کے اصولوں کو جاننا بھی اتنا ہی ضروری ہے۔ میں مسلسل پروگرامرز، مختلف سطحوں کے ڈویلپرز کا مشاہدہ کرتا ہوں جنہوں نے یا تو SOLID OOD اصولوں کے بارے میں نہیں سنا ہے، یا صرف ان فوائد کے بارے میں نہیں جانتے جو یہ یا وہ ڈیزائن اصول فراہم کرتا ہے، یا اسے کوڈ میں کیسے لاگو کرنا ہے۔ پایان لائن، ہمیشہ اپنے حل میں کوڈ کی ہم آہنگی اور اچھے ڈیزائن کے لیے کوشش کریں۔ جاوا اور OOD سیکھنے کے لیے بہترین مثالیں اوپن سورس اپاچی اور سن ہیں۔ وہ یہ ظاہر کرتے ہیں کہ جاوا پروگراموں میں کوڈ لکھنے میں OOD اصولوں کو کس طرح استعمال کیا جانا چاہیے۔ JDK میں پیٹرن کے استعمال کی مثال: فیکٹری، بارڈر فیکٹری کلاس میں "فیکٹری" پیٹرن ، فیکٹری ڈیزائن پیٹرن کیا ہے... ، سنگلٹن پیٹرن، "سنگلٹن"، رن ٹائم رن ٹائم کلاس میں ، ڈیکوریٹر پیٹرن، "ڈیکوریٹر"، مختلف java.io کلاسوں میں۔ ویسے، اگر آپ جاوا کوڈ پر عمل کرنے میں دلچسپی رکھتے ہیں، تو Effective Java، Joshua Bloch (مثال کے طور پر Effective Java کا روسی میں ترجمہ کیا گیا )، جاوا API کے مصنف کا ایک شاہکار پڑھیں۔ OOD اور پیٹرن کے موضوع پر بھی، میں ہیڈ فرسٹ ڈیزائن پیٹرن کے ساتھ ساتھ ہیڈ فرسٹ آبجیکٹ اورینٹڈ تجزیہ اور ڈیزائن کی سفارش کرتا ہوں۔ یہ کتابیں 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 کتابوں میں موجود ہے۔ وفد کا اصول ہر کام خود نہ کریں، مناسب کلاس کو کام تفویض کریں۔ ڈیلیگیشن کے اصول کو لاگو کرنے کی ایک درسی کتاب کی مثال equals() اور hashCode() طریقوں کا استعمال ہے۔ دو اشیاء کا موازنہ کرنے کے لیے، ہم کلاس کو خود کام کرنے دیتے ہیں، بجائے اس کے کہ چیکنگ کو کلائنٹ کلاس پر چھوڑ دیں۔ اس اصول کا فائدہ یہ ہے کہ یہ ڈبل کوڈنگ سے بچتا ہے اور رویے کو تبدیل کرنا آسان بناتا ہے۔ آبجیکٹ اورینٹڈ ڈیزائن کے مندرجہ بالا تمام اصول آپ کو لچکدار اور بہتر کوڈ، مربوط، لیکن غیر ضروری کنکشن کے بغیر لکھنے میں مدد کریں گے۔ نظریہ پہلا قدم ہے۔ سب سے اہم بات یہ ہے کہ یہ تجزیہ کرنے کی صلاحیت پیدا کی جائے کہ یہ OOD اصول کہاں لاگو ہوتے ہیں۔ یہ دیکھنے کے لیے دیکھیں کہ آیا آپ اپنے کوڈ کی لچک کو خطرے میں ڈال کر کسی اصول کی خلاف ورزی کر رہے ہیں۔ ایک ہی وقت میں، کچھ بھی کامل نہیں ہے؛ پروگرامنگ میں OOD اصولوں کو لاگو کرکے ہمیشہ مسائل کو حل کرنا ناممکن ہے۔ وہ کارپوریٹ حل اور طویل تکنیکی سپورٹ سائیکل والے منصوبوں کے لیے، زیادہ تر حصے کے لیے اہم ہیں۔