ব্রিজ ডিজাইনের ধরণটি বোঝা

Question

আমি "ব্রিজ" ডিজাইন প্যাটার্নটি মোটেই বুঝতে পারি না। আমি বিভিন্ন ওয়েব সাইট দিয়েছি, কিন্তু তারা সাহায্য করেনি।

এটি বুঝতে কেউ আমাকে সহায়তা করতে পারে?

Comments

আমি তাও বুঝতে পারি না। উত্তরগুলি দেখার অপেক্ষায় :)

— ভায়োলেট জিরাফ

ডিজাইনের নিদর্শনগুলি বর্ণনা করার জন্য প্রচুর ওয়েবসাইট এবং বই রয়েছে। ইতিমধ্যে যা লেখা হয়েছে তার পুনরাবৃত্তি করার কোনও মূল্য আছে বলে আমি মনে করি না, সম্ভবত আপনি একটি নির্দিষ্ট প্রশ্ন জিজ্ঞাসা করতে পারেন। এটি বিভিন্ন উত্স এবং উদাহরণগুলির মধ্যে স্যুইচিং চালিয়ে যেতে আমার এটি বুঝতে কিছুটা সময় লেগেছে।

— হেলেনা

Answer 1

ওওপিতে আমরা বহুকর্ম ব্যবহার করি যাতে বিমূর্তিতে একাধিক বাস্তবায়ন হতে পারে। আসুন নীচের উদাহরণটি দেখুন:

//trains abstraction
public interface Train
{ 
    move();
}
public class MonoRail:Train
{
    public override move()
    {
        //use one track;
    }
}
public class Rail:Train
{
    public override move()
    {
        //use two tracks;
    }
}

একটি নতুন প্রয়োজনীয়তা প্রবর্তিত হয়েছে এবং ট্রেনগুলির ত্বরণের দৃষ্টিকোণটি আনতে হবে, সুতরাং নীচের মতো কোডটি পরিবর্তন করুন।

    public interface Train
    { 
        void move();
    }
    public class MonoRail:Train
    {
        public override void move()
        {
            //use one track;
        }
    }
    public class ElectricMonoRail:MonoRail
    {
        public override void move()
        {
            //use electric engine on one track.
        }
    }
    public class DieselMonoRail: MonoRail
    {
        public override void move()
        {
            //use diesel engine on one track.
        }
    }
    public class Rail:Train
    {
        public override void move()
        {
            //use two tracks;
        }
    }
    public class ElectricRail:Rail
    {
        public override void move()
        {
            //use electric engine on two tracks.
        }
    }
    public class DieselRail: Rail
    {
        public override void move()
        {
            //use diesel engine on two tracks.
        }
    }

উপরের কোডটি সংরক্ষণযোগ্য নয় এবং পুনরায় ব্যবহারযোগ্যতার অভাব রয়েছে (ধরে নিই আমরা একই ট্র্যাক প্ল্যাটফর্মের জন্য ত্বরণ প্রক্রিয়াটি পুনরায় ব্যবহার করতে পারি)। নিম্নলিখিত কোডটি সেতুর প্যাটার্ন প্রয়োগ করে এবং দুটি পৃথক বিমূর্ততা, ট্রেন পরিবহন এবং ত্বরণকে পৃথক করে ।

public interface Train
{ 
    void move(Accelerable engine);
}
public interface Accelerable
{
    public void accelerate();
}
public class MonoRail:Train
{
    public override void move(Accelerable engine)
    {
        //use one track;
        engine.accelerate(); //engine is pluggable (runtime dynamic)
    }
}
public class Rail:Train
{
    public override void move(Accelerable engine)
    {
        //use two tracks;
        engine.accelerate(); //engine is pluggable (runtime dynamic)
    }
}
public class ElectricEngine:Accelerable{/*implementation code for accelerable*/}
public class DieselEngine:Accelerable{/*implementation code for accelerable*/}

Comments

খুব সুন্দর উদাহরণ। আমি আমার দুটি সেন্ট যুক্ত করব: উত্তরাধিকারের

— তুলনায়

এটির মূল্যের জন্য, আমি মনে করি এটি হওয়া উচিত Monorailকারণ এটি দুটি শব্দ নয়, এটি একটি একক (যৌগিক) শব্দ। একটি মনোরেল হ'ল রেলের কিছু ধরণের সাবক্লাসের পরিবর্তে বিভিন্ন ধরণের রেলের (যা এটি)। ঠিক যেমন আমরা ব্যবহার করব না SunShineবা CupCake, সেগুলি হবে SunshineএবংCupcake

— এরিক

এই লাইনটি "দুটি পৃথক বিমূর্ততা, ট্রেন পরিবহন এবং ত্বরণ" সহায়তা করে, দুটি শ্রেণিবিন্যাস কী এবং আমরা কী সমাধান করার চেষ্টা করি তা তাদের স্বাধীনভাবে পরিবর্তিত করা point

— wangdq

Answer 2

বেশিরভাগ ডিজাইনের নিদর্শনগুলিতে সহায়ক নাম থাকলেও আমি "ব্রিজ" নামটি এটি কী করে তা বিবেচনায় অ-স্বজ্ঞাত বলে মনে করি।

ধারণামূলকভাবে, আপনি শ্রেণি শ্রেণিবিন্যাসের দ্বারা ব্যবহৃত বাস্তবায়নের বিবরণটিকে অন্য কোনও বস্তুর মধ্যে ধাক্কা দেন, সাধারণত তার নিজস্ব শ্রেণিবিন্যাস সহ। এটি করার মাধ্যমে আপনি সেইগুলি প্রয়োগের বিশদগুলির উপর একটি দৃ tight় নির্ভরতা সরিয়ে দিচ্ছেন এবং সেই প্রয়োগের বিশদটি পরিবর্তনের অনুমতি দিচ্ছেন।

আপনি যদি একটি নতুন আচরণে প্লাগ করতে পারেন তেমন একটি ছোট স্কেলে, আমি এটিকে কৌশল প্যাটার্নের ব্যবহারের সাথে তুলনা করি। তবে প্রায়শই একটি কৌশল হিসাবে দেখা যায় কেবল একটি অ্যালগরিদম মোড়ানোর পরিবর্তে বাস্তবায়ন বস্তুটি সাধারণত আরও বৈশিষ্ট্য পূর্ণ হয়। এবং আপনি যখন ধারণাটি পুরো শ্রেণির শ্রেণিবিন্যাসে প্রয়োগ করেন তখন বৃহত্তর প্যাটার্নটি একটি সেতুতে পরিণত হয়। (আবার নামটি ঘৃণা করুন)।

আপনি যে প্রতিদিন ব্যবহার করবেন এটি এমন কোনও প্যাটার্ন নয়, তবে ক্লাসগুলির সম্ভাব্য বিস্ফোরণ পরিচালনা করার সময় আমি এটি সহায়ক বলে মনে করেছি যখন আপনার একাধিক উত্তরাধিকারের প্রয়োজন (স্পষ্ট) প্রয়োজন।

এখানে একটি বাস্তব বিশ্বের উদাহরণ:

আমার কাছে একটি র‌্যাড সরঞ্জাম রয়েছে যা আপনাকে কোনও ডিজাইনের পৃষ্ঠের উপর নিয়ন্ত্রণগুলি ড্রপ এবং কনফিগার করতে দেয়, সুতরাং আমার কাছে এই জাতীয় একটি মডেল রয়েছে:

Widget // base class with design surface plumbing
+ Top
+ Left
+ Width
+ Height
+ Name
+ SendToBack
+ BringToFront
+ OnPropertyEdit
+ OnSelect
+ Validate
+ ShowEditor
+ Paint
+ Etc

TextboxWidget : Widget // text box specific
+ Text
+ MaxLength
+ Font
+ ShowEditor // override base to show a property editor form specific to a Textbox
+ Paint // override to render a textbox onto the surface    
+ Etc

ListWidget : Widget // list specific
+ Items
+ SelectedItem
+ ShowEditor // override base to show a property editor form specific to a List
+ Paint // override to render a list onto the surface
+ Etc

এবং এভাবেই সম্ভবত এক ডজন নিয়ন্ত্রণ রয়েছে।

তবে একাধিক থিমকে সমর্থন করার জন্য একটি নতুন প্রয়োজনীয়তা যুক্ত করা হয়েছে (চেহারা-এন-অনুভূতি)। ধরুন আমরা নিম্নলিখিত থিম আছে যাক: Win32, WinCE, WinPPC, WinMo50, WinMo65। প্রতিটি থিমের ডিফল্টফন্ট, ডিফল্টব্যাক কালার, বর্ডারউইথ, ড্র ফ্রেম, ড্রসক্রোলথম্ব ইত্যাদি রেন্ডারিং-সম্পর্কিত ক্রিয়াকলাপগুলির জন্য আলাদা মান বা বাস্তবায়ন থাকবে

আমি এই জাতীয় একটি বস্তু মডেল তৈরি করতে পারে:

Win32TextboxWidget : TextboxWidget

Win32ListWidget : ListWidget

ইত্যাদি, একটি নিয়ন্ত্রণ ধরণের জন্য

WinCETextboxWidget : TextboxWidget

WinCEListWidget : ListWidget

ইত্যাদি, একে অপরের নিয়ন্ত্রণের জন্য (আবার)

আপনি ধারণা পাবেন — আপনি থিমের # উইজেটের বারের একটি শ্রেণির বিস্ফোরণ পেতে পারেন। এটি প্রতিটি থিম সম্পর্কে সচেতন করে আরএডি ডিজাইনারকে জটিল করে তোলে। এছাড়াও, নতুন থিম যুক্ত করা RAD ডিজাইনারকে সংশোধন করতে বাধ্য করে। তদ্ব্যতীত, একটি থিমের মধ্যে প্রচুর প্রচলিত বাস্তবায়ন রয়েছে যা উত্তরাধিকার সূত্রে দুর্দান্ত হবে তবে নিয়ন্ত্রণগুলি ইতিমধ্যে একটি সাধারণ বেস ( Widget) থেকে উত্তরাধিকার সূত্রে প্রাপ্ত ।

সুতরাং পরিবর্তে আমি যা করেছি তা হল একটি পৃথক অবজেক্ট শ্রেণিবদ্ধতা যা থিমটি প্রয়োগ করে। প্রতিটি উইজেট অবজেক্টের একটি রেফারেন্স ধারণ করে যা রেন্ডারিং অপারেশনগুলি প্রয়োগ করে। অনেক পাঠ্যক্রমে, এই শ্রেণিটি একটি সহ্য করা হয়েছে Implতবে আমি সেই নামকরণ সম্মেলন থেকে বিচ্যুত হয়েছি।

সুতরাং এখন আমার TextboxWidgetচেহারা এই মত:

TextboxWidget : Widget // text box specific
+ Text
+ MaxLength
+ Font
+ ShowEditor
+ Painter // reference to the implementation of the widget rendering operations
+ Etc

এবং আমি আমার বিভিন্ন চিত্রকরকে আমার থিম-নির্দিষ্ট বেসের উত্তরাধিকারী করতে পারি, যা আমি আগে করতে পারিনি:

Win32WidgetPainter
+ DefaultFont
+ DefaultFontSize
+ DefaultColors
+ DrawFrame
+ Etc

Win32TextboxPainter : Win32WidgetPainter

Win32ListPainter : Win32WidgetPainter

একটি দুর্দান্ত জিনিস হ'ল আমি রান-টাইমে বাস্তবায়নগুলি গতিশীলভাবে লোড করতে পারি, মূল সফ্টওয়্যারটি পরিবর্তন না করে আমাকে যতগুলি থিম যোগ করতে দেয় তার অনুমতি দেয়। অন্য কথায় আমার "প্রয়োগটি বিমূর্ততার থেকে পৃথক হতে পারে"।

Comments

বুঝতে পারছি না এটি কীভাবে সেতুর প্যাটার্ন বলে মনে হচ্ছে? আপনি যখন উইজেট শ্রেণিবিন্যাসে একটি নতুন উপাদান যুক্ত করেন, আপনি সেই নতুন উইজেটটি সমস্ত চিত্রশিল্পীদের (Win32NewWidgetPainter, PPCNewWidgetPainter) যুক্ত করতে বাধ্য হন। এটি স্বাধীনভাবে ক্রমবর্ধমান দুটি শ্রেণিবিন্যাস নয়। যথাযথ ব্রিজ প্যাটার্নের জন্য, আপনি প্রতিটি উইজেটের জন্য প্ল্যাটফর্ম উইজেটপেন্টার শ্রেণি সাবক্লাস করবেন না, বরং এটি কোনও উইজেট "ড্র বর্ণনাকারী" পান receive

— মাজিয়ড

প্রতিক্রিয়ার জন্য ধন্যবাদ, আপনি ঠিক বলেছেন। এটা তোলে বছর আগে ছিল যে আমি এই পোস্ট, এবং এখন এটা পর্যালোচনার আমি বলতে হবে এটা ভাল সেতু বর্ণনা পর্যন্ত শেষ প্রান্তে আমি কোথায় উদ্ভূত Win32TextboxPainterএবং Win32ListPainter থেকে Win32WidgetPainter। আপনি করতে পারেন বাস্তবায়ন পাশ একটি উত্তরাধিকার গাছ আছে, কিন্তু এটি আরো জেনেরিক (সম্ভবত হওয়া উচিত StaticStyleControlPainter, EditStyleControlPainterএবং ButtonStyleControlPainterহিসাবে প্রয়োজন ওভাররাইড কোন প্রয়োজন আদিম অপারেশন সহ)। এটি আমি যে উদাহরণটিতে ভিত্তি করেছিলাম তার বাস্তব কোডের কাছাকাছি।

— tcarvin

Answer 3

ব্রিজটি তার কংক্রিট বাস্তবায়ন থেকে বিমূর্ততা ডিকুয়াল করতে চায় , যাতে উভয়ই স্বতন্ত্রভাবে পরিবর্তিত হতে পারে:

• সাবক্লাসিং সহ বিমূর্তিটি পরিমার্জন করুন
• বিমূর্ততা বা এর পরিশোধকগুলি না জেনেও সাবক্লাসিংয়ের মাধ্যমে বিভিন্ন বাস্তবায়ন সরবরাহ করুন।
• প্রয়োজনে রানটাইম বেছে নিন যা সবচেয়ে উপযুক্ত বাস্তবায়ন ।

সেতুটি রচনাটি ব্যবহার করে এটি অর্জন করে:

• বিমূর্তি একটি বাস্তবায়ন অবজেক্টকে (রেফারেন্স বা পয়েন্টার) বোঝায়
• বিমূর্ততা এবং এর পরিমার্জনগুলি কেবল বাস্তবায়ন ইন্টারফেস হিসাবে পরিচিত

প্রায়শই বিভ্রান্তির বিষয়ে অতিরিক্ত মন্তব্য

এই প্যাটার্নটি অ্যাডাপ্টারের প্যাটার্নের সাথে খুব মিল: বিমূর্ততা একটি বাস্তবায়নের জন্য আলাদা ইন্টারফেস দেয় এবং এটি করার জন্য রচনা ব্যবহার করে। কিন্তু:

1995 এর নকশাগুলির মধ্যে প্রধান পার্থক্য তাদের উদ্দেশ্যগুলির মধ্যে রয়েছে
- 1995 সালে " ডিজাইনের নিদর্শন, পুনরায় ব্যবহারযোগ্য ওও সফ্টওয়্যারটির উপাদান " , 1995

নকশার নিদর্শনগুলির বিষয়ে এই দুর্দান্ত সেমিনাল বইটিতে লেখকরা এটিও পর্যবেক্ষণ করেছেন:

• যখন একটি অসম্পূর্ণতা আবিষ্কার হয় এবং সংযোজন অপ্রত্যাশিত হয় তখন অ্যাডাপ্টারগুলি প্রায়শই ব্যবহৃত হয়
• সেতুগুলি নকশার শুরু থেকেই ব্যবহৃত হয়, যখন এটি প্রত্যাশিত হয় যে ক্লাসগুলি স্বাধীনভাবে বিকশিত হবে।