جاوا پروگرامر کي ڄاڻڻ گهرجي ڏهه آبجیکٹ آريئنٽيڊ ڊيزائن جا اصول

آبجیکٹ اورينٽيڊ ڊيزائن (OOD) اصول جاوا آبجیکٹ اورينٽيڊ پروگرامنگ (OOP) جا بنيادي آهن، پر مان ڏسان ٿو ته جاوا پروگرامر اڪثر سنگلٽن ۽ ڊيڪرائيٽر جي نمونن سان ڪم ڪري رهيا آهن . يا ”آبزرور“ ، ۽ اعتراض تي مبني تجزيي جي مطالعي تي ڪافي ڌيان نه ڏيندا آهن ۽ ڊيزائن. يقينن، اهو ضروري آهي ته OOP جي بنيادي ڳالهين کي سکڻ : تجزيه، انڪپسوليشن، پوليمورفيزم ۽ وراثت، پر ساڳئي وقت، اهو پڻ ضروري آهي ته ڊزائن جي اصولن کي ڄاڻڻ لاء چڱي طرح ٺهيل ۽ سمجھڻ واري مصنوعات ٺاهڻ لاء. مان مسلسل پروگرامرز، مختلف سطحن جي ڊولپرز جو مشاهدو ڪريان ٿو، جن يا ته SOLID OOD اصولن جي باري ۾ نه ٻڌو آهي، يا صرف انهن فائدن جي باري ۾ نه ڄاڻن ٿا جيڪي هي يا اهو ڊزائن اصول مهيا ڪري ٿو، يا ان کي ڪوڊ ۾ ڪيئن لاڳو ڪجي. هيٺئين لڪير، هميشه توهان جي حل ۾ ڪوڊ جي مطابقت ۽ سٺي ڊيزائن جي ڪوشش ڪريو. جاوا ۽ OOD سکڻ لاءِ عظيم مثال اوپن سورس اپاچي ۽ سن آهن. اهي ظاهر ڪن ٿا ته جاوا پروگرامن ۾ ڪوڊ لکڻ ۾ OOD اصولن کي ڪيئن استعمال ڪيو وڃي. JDK ۾ نمونن جي استعمال جو مثال: ڪارخانو، بارڊر فئڪٽري ڪلاس ۾ ”فيڪٽري“ جو نمونو ، فئڪٽري ڊيزائن جو نمونو ڇا آھي... ، سنگلٽن جو نمونو، ”سنگلٽن“، رن ٽائم رن ٽائم ڪلاس ۾ ، ڊيڪرائيندڙ نمونو، "سجائيندڙ"، مختلف java.io طبقن ۾. رستي جي ذريعي، جيڪڏهن توهان جاوا ڪوڊ تي عمل ڪرڻ ۾ دلچسپي رکو ٿا، پڙهو اثرائتو جاوا، جوشوا بلوچ (مثال طور، مؤثر جاوا ترجمو ڪيو روسي ۾ )، جاوا 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у, который сможет работать с любой новой реализацией интерфейса. Используйте переменные интерфейсного типа, طريقن سان موٽڻ جي قيمت سان، يا طريقا پيرا ميٽرن سان. ساڳي صلاح موثر جاوا ۽ OOD ڪتابن ۾ موجود آهي. وفد جو اصول سڀ ڪجھ پاڻ نه ڪريو، ڪم مناسب طبقي کي ڏيو. وفد جي اصول کي لاڳو ڪرڻ جو هڪ درسي ڪتاب مثال برابر () ۽ hashCode() طريقن جو استعمال آهي. ٻن شين جو مقابلو ڪرڻ لاءِ، اسان ڪلاس کي پاڻ ڪم ڪرڻ ڏيون ٿا، بجاءِ چيڪنگ کي ڪلائنٽ ڪلاس ڏانهن ڇڏڻ جي. هن اصول جو فائدو اهو آهي ته اهو ڊبل ڪوڊنگ کان پاسو ڪري ٿو ۽ رويي کي تبديل ڪرڻ آسان بڻائي ٿو. اعتراض تي مبني ڊيزائن جا مٿيان سڀئي اصول توهان کي لچڪدار ۽ بهتر ڪوڊ لکڻ ۾ مدد ڪندا، مربوط، پر غير ضروري ڪنيڪشن کان سواءِ. نظريو پهريون قدم آهي. سڀ کان اهم شيء اهو آهي ته تجزيو ڪرڻ جي صلاحيت پيدا ڪرڻ جتي اهي OOD اصول لاڳو ٿين ٿا. ڏسڻ لاءِ ڏسو ته ڇا توهان ڪنهن به اصول جي ڀڃڪڙي ڪري رهيا آهيو، توهان جي ڪوڊ جي لچڪ کي خطري ۾ وجهي رهيا آهيو. ساڳئي وقت، ڪا به شيءِ مڪمل ناهي؛ اهو ناممڪن آهي هميشه مسئلن کي حل ڪرڻ صرف پروگرامنگ ۾ OOD اصولن کي لاڳو ڪرڻ سان. اھي نازڪ آھن، گھڻي ڀاڱي، ڪارپوريٽ حلن ۽ منصوبن لاءِ ڊگھي ٽيڪنيڪل سپورٽ چڪر سان.