"আলগা মিলন" কী? উদাহরণ প্রদান করুন

172

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

কেউ দয়া করে কিছু "আগে" এবং "পরে" কোড (বা সিউডোকোড) দেখান যা এই ধারণাটি চিত্রিত করে?

oop  language-agnostic  loose-coupling 
— trebormf
সূত্র
আমি নিশ্চিত না যে কীভাবে এটি একটি নির্দিষ্ট ভাষা থেকে ডিভোর্স হতে পারে কারণ ধারণার অংশটি হ'ল কীভাবে কোনও ভাষা ব্যবহার করে কোড ইউনিটকে একে অপরের সাথে খুব বেশি জড়িয়ে যেতে না পারে। আমি আরও নোট করেছি যে উত্তরগুলির বেশ কয়েকটি ধারণাটি চিত্রিত করার জন্য কোড অবলম্বন করে।
— ওনোরিও ক্যাটেনাচি
11
সম্পূর্ণরূপে দ্বিমত করুন, কার্যকরীতাগুলি বিভিন্ন ভাষায় আলাদাভাবে চিত্রিত করা যেতে পারে এবং এটি গতিশীল বনাম সংকলিত ভাষাগুলিতে বিশেষত স্পষ্ট। তবে ধারণাটি উভয় দিক থেকেই একই।
— ওয়েন
লুজ বনাম টাইট এবং কাপলিং বনাম ডিকোপলিং । বরাবর ট্যাগিং না একটি ভাল জিনিস সবসময়, কখনও কখনও ভাল / মাঝে মাঝে না ভাল ... আমরা থাকা উচিত হিসাবে স্বাধীনতা আমাদের নিজস্ব, তাই ক্লাস না।
— BonCodigo

উত্তর:

180

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

শক্তভাবে দম্পতি উদাহরণ:

public class CartEntry
{
    public float Price;
    public int Quantity;
}

public class CartContents
{
    public CartEntry[] items;
}

public class Order
{
    private CartContents cart;
    private float salesTax;

    public Order(CartContents cart, float salesTax)
    {
        this.cart = cart;
        this.salesTax = salesTax;
    }

    public float OrderTotal()
    {
        float cartTotal = 0;
        for (int i = 0; i < cart.items.Length; i++)
        {
            cartTotal += cart.items[i].Price * cart.items[i].Quantity;
        }
        cartTotal += cartTotal*salesTax;
        return cartTotal;
    }
}

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

এখন একই জিনিসটি করার কিছুটা ভাল উপায়:

কম দম্পতি উদাহরণ:

public class CartEntry
{
    public float Price;
    public int Quantity;

    public float GetLineItemTotal()
    {
        return Price * Quantity;
    }
}

public class CartContents
{
    public CartEntry[] items;

    public float GetCartItemsTotal()
    {
        float cartTotal = 0;
        foreach (CartEntry item in items)
        {
            cartTotal += item.GetLineItemTotal();
        }
        return cartTotal;
    }
}

public class Order
{
    private CartContents cart;
    private float salesTax;

    public Order(CartContents cart, float salesTax)
    {
        this.cart = cart;
        this.salesTax = salesTax;
    }

    public float OrderTotal()
    {
        return cart.GetCartItemsTotal() * (1.0f + salesTax);
    }
}

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

— কীলক
সূত্র
নির্ভরতা ইনজেকশন দিয়ে আরও ডিকপলিংয়ের মাধ্যমে আপনি উত্তরটি প্রসারিত করতে পারবেন (যদিও নির্মাণকারী আদর্শ হওয়া উচিত)?
— BAD_SEED
4
@ ওয়েজ, আমি এ Orderসম্পর্কে কোনও জ্ঞান রাখার কোনও কারণ দেখতে পাচ্ছি না Cart। লাইভ শপিং এবং ফ্যাক্ট্যুরেশন দুটি পৃথক প্রসঙ্গ। যখন ক্লায়েন্ট অর্থ প্রদানের জন্য প্রস্তুত থাকে, তখন আপনার জন্য কার্টএন্ট্রিগুলি অনুবাদ করার জন্য দায়বদ্ধ একটি প্রক্রিয়া থাকতে পারে Order। এইভাবে Orderক্লাসটি ইনস্ট্যান্সিয়েটেড এবং একটি ছাড়াও ব্যবহৃত হবে Cart।
— প্লালেক্স
@ ওয়েজ আপনি আমার মন্তব্য প্রতিক্রিয়া করতে পারেন দয়া করে?
— প্ল্লেক্স
ভাল এবং সহজভাবে ব্যাখ্যা। আমি "..এটিতে আলো দেখতে শুরু করলাম কীভাবে অর্ডারটোটাল পদ্ধতি (এবং এভাবে অর্ডার ক্লাস) কার্টকন্টেন্টস এবং কার্টেন্ট্রি শ্রেণীর প্রয়োগের বিশদগুলির উপর নির্ভর করে .."
— ওকি_অনেক
এই উদাহরণটি স্পষ্টভাবে উপস্থাপন করা হয়েছে। তবে এই দিনগুলিতে, আরও বেশি স্থপতিরা সম্মত হন যে এই অতিরিক্ত মাত্রায়-ভিত্তিক স্টাইলটি খারাপ অভ্যাস। এর "বাস্তবায়ন" বিবরণ গোপন করার কোনো মানে নেই CartEntryএবং CartContents। যেহেতু এগুলির পুরোপুরি স্পষ্ট অর্থ রয়েছে, এগুলি কেবল ডেড ডেটা হিসাবে মডেল করা উচিত। ডাটাবেসের শর্তে, এখানে যা যা প্রয়োজন তা হ'ল একটি টেবিলCREATE TABLE entry (price INTEGER, quantity INTEGER)
— জো সো
160

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

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

— কনরাড রুডল্ফ
সূত্র
আলগা বা টাইট মিলন ভাল? কিভাবে আলগা সংযোগ বা আঁট সংযোগ বাস্তবায়নের বিষয়ে সিদ্ধান্ত নেবেন?
— শ্রীকান্ত করুণাঘাট
2
এই মহান উদাহরণ জন্য ধন্যবাদ। আমি অন্যান্য উত্তরগুলিতে অনেক সময় ব্যয় করেছি তবে এর মতো মূল্যহীন
— আলামিন
1
শ্রীকান্ত করুণাঘাট, আপনি কি কেবল ব্যাটারির জন্য কম অর্থ ব্যয় করবেন এবং আবার একটি ওয়ার্কিং আইপড পাবেন বা আপনি পুরো আইপডের জন্য প্রচুর অর্থ ব্যয় করতে পছন্দ করবেন?
— কোশেরা
1
@ শ্রীকণথ কারুমানঘাট সাধারণত আলগা সংযোগগুলি আরও ভাল কারণ এটি পরিমিতি প্রচার করে এবং এভাবে কোড বজায় রাখা সহজ করে তোলে। আপনি যদি নিজের ক্লাস / লাইব্রেরি / কোডটি দৃly়ভাবে জুটি করেন, তবে আপনি একটি শ্রেণিতে যে কোনও ছোট পরিবর্তন করেন এটি ব্যবহার করে এমন সমস্ত ক্লাসে প্রয়োগ করতে হবে।
— কেনি ওয়ার্ডেন
56

আমি উদাহরণ হিসাবে জাভা ব্যবহার করব। ধরা যাক আমাদের এমন একটি ক্লাস রয়েছে যা দেখতে এরকম দেখাচ্ছে:

public class ABC
{
   public void doDiskAccess() {...}
}

আমি যখন ক্লাসটি কল করি তখন আমাকে এরকম কিছু করতে হবে:

ABC abc = new ABC();

abc. doDiskAccess();

এ পর্যন্ত সব ঠিকই. এখন বলি যে আমার কাছে আরও একটি ক্লাস রয়েছে যা দেখতে এরকম দেখাচ্ছে:

public class XYZ
{
   public void doNetworkAccess() {...}
}

এটি দেখতে এবিসি-র মতো দেখতে একই রকম, তবে ধরা যাক এটি ডিস্কের পরিবর্তে নেটওয়ার্কে কাজ করে। সুতরাং এখন এর মত একটি প্রোগ্রাম লিখুন:

if(config.isNetwork()) new XYZ().doNetworkAccess();
else new ABC().doDiskAccess();

এটি কাজ করে, তবে এটি কিছুটা অস্বাস্থ্যকর। আমি এটির মতো ইন্টারফেস দিয়ে এটিকে সহজ করতে পারি:

public interface Runnable
{
    public void run();
}

public class ABC implements Runnable
{
   public void run() {...}
}

public class XYZ implements Runnable
{
   public void run() {...}
}

এখন আমার কোডটি এর মতো দেখতে পাওয়া যাবে:

Runnable obj = config.isNetwork() ? new XYZ() : new ABC();

obj.run();

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

তবে যদি আমাদের দুজনের মধ্যে যোগাযোগের দরকার হয়? ঠিক আছে, তারপরে আমরা আপনার তৈরি করা API গুলিগুলির সাথে প্যারেন্ট কোডটি কখনও জুড়তে হবে না তা নিশ্চিত করতে ইভেন্ট মডেলের মতো আরও বিমূর্ততা ব্যবহার করতে পারি ।

— 64BitBob
সূত্র
2
এই উদাহরণটিতে এখনও বেশ কয়েকটি উচ্চ স্তরের মিলন রয়েছে। এখনই কেবল একটি একক শ্রেণিতে যোগদানের পরিবর্তে দুটি থেকে বেছে নেওয়া উচিত। এই উদাহরণটি ধরে নিয়েছে যে কেবল দুটি "চলমান" বাস্তবায়ন উপলব্ধ থাকবে। কোন ক্ষেত্রে একটি ইন্টারফেস এমনকি প্রয়োজন হয় না।
— ওয়েন
এই রান * এবং কর * নামের পদ্ধতিগুলি আমার কাছে একটি বিশাল কোড গন্ধ। আপনি আইহ্যান্ডল স্টাফ বা আইফ্রোবনেটথিংগুলি ব্যবহার করে এটির পাশাপাশি চুল্লিও করতে পারেন। এই ক্ষেত্রে চলমান চলনযোগ্য, খুব বেশি সাধারণ শব্দ।
— ওয়েজ
8
ওভেন, বাচ্চা আমার বন্ধুকে পা দেয়। যদি সে মিলন বোঝে না, তবে তিনি কীভাবে বুঝতে পারবেন যে কোনও কারখানার নকশা তাকে কেনে? এই কোড উদাহরণটি তাকে সঠিক পথে রাখে। অভিপ্রায়টি হ'ল তিনি সমস্যাটি আরও ভালভাবে বুঝতে পারবেন এবং বুঝতে পারবেন কীভাবে কীভাবে অবজেক্টগুলি তৈরি করতে পারে তার বিমূর্ততা।
— 64 বিটবো
6
এটি আরো পাঠযোগ্য হবে যদি এবিসি এবং XYZ ভালো কিছু নতুন নামকরণ করা হয়েছে DiskAccessorএবং NetworkAccessor? আমি কোন জাভা
— ডান্নো
এটি কি কারখানার নকশার ধরণটি ব্যবহার করে? কারণ আমরা প্রয়োজনের উপর নির্ভর করে নতুন এক্সওয়াইজেড বা এবিসি অবজেক্ট তৈরি করছি।
— মুনমুনব্ব
37

দুঃখিত, তবে "আলগা কাপলিং" কোডিং সমস্যা নয়, এটি একটি ডিজাইনের সমস্যা। "আলগা সংযোগ" শব্দটি ঘনিষ্ঠভাবে "উচ্চ সংহতি" এর আকাঙ্ক্ষিত অবস্থার সাথে সম্পর্কিত, বিপরীত হলেও পরিপূরক।

আলগা সংযোগের সহজ অর্থ হ'ল পৃথক নকশার উপাদানগুলি তৈরি করা উচিত যাতে অন্যান্য ডিজাইনের উপাদানগুলির বিষয়ে তাদের যে পরিমাণ অপ্রয়োজনীয় তথ্য জানা দরকার তা হ্রাস করা হয়।

উচ্চ সংহতি হ'ল ধরণের "টাইট কাপলিং" এর মতো, তবে উচ্চ সংহতি এমন একটি রাষ্ট্র যা যেখানে একে অপরের সম্পর্কে সত্যই জেনে রাখা প্রয়োজন এমন নকশার উপাদানগুলি এমনভাবে ডিজাইন করা হয়েছে যাতে তারা পরিষ্কার এবং মার্জিতভাবে একসাথে কাজ করে।

মুল বক্তব্যটি হ'ল কিছু ডিজাইনের উপাদানগুলির অন্যান্য ডিজাইনের উপাদানগুলি সম্পর্কে বিশদ জানতে হবে, সুতরাং সেগুলি সেভাবে ডিজাইন করা উচিত, এবং ঘটনাক্রমে নয়। অন্যান্য নকশার উপাদানগুলির অন্যান্য নকশার উপাদানগুলির বিশদ জানতে হবে না, সুতরাং এগুলি এলোমেলোভাবে পরিবর্তে উদ্দেশ্যমূলকভাবে ডিজাইন করা উচিত।

এটি প্রয়োগ করা পাঠকের জন্য অনুশীলন হিসাবে রেখে গেছে :)।

— ডেভিড এম কারার
সূত্র
33

শক্তভাবে সংযুক্ত কোডটি একটি কংক্রিট বাস্তবায়নের উপর নির্ভর করে। আমার কোডে আমার যদি স্ট্রিংগুলির একটি তালিকা প্রয়োজন এবং আমি এটি এটির মতো ঘোষণা করে (জাভাতে)

ArrayList<String> myList = new ArrayList<String>();

তারপরে আমি অ্যারেলিস্ট বাস্তবায়নের উপর নির্ভরশীল।

যদি আমি এটিকে আলগাভাবে সংযুক্ত কোডে পরিবর্তন করতে চাই তবে আমি আমার রেফারেন্সটিকে একটি ইন্টারফেস (বা অন্যান্য বিমূর্ত) প্রকারে পরিণত করি।

List<String> myList = new ArrayList<String>();

এটি আমাকে অ্যারেলিস্ট প্রয়োগের জন্য নির্দিষ্ট যে কোনও পদ্ধতিতে কল করতে বাধা দেয় myList। আমি কেবল তালিকা ইন্টারফেসে সংজ্ঞায়িত সেই পদ্ধতিগুলির মধ্যে সীমাবদ্ধ। যদি আমি পরে সিদ্ধান্ত নিই যে আমার সত্যিই একটি লিঙ্কডলিস্ট দরকার, তবে আমার কেবলমাত্র আমার কোডটি এক জায়গায় বদলাতে হবে, যেখানে আমি নতুন তালিকা তৈরি করেছি, এবং 100 টি জায়গায় নয় যেখানে আমি অ্যারেলিস্ট পদ্ধতিতে কল করেছি।

অবশ্যই, আপনি প্রথম ঘোষণাটি ব্যবহার করে একটি অ্যারেলিস্ট ইনস্ট্যান্ট করতে পারেন এবং তালিকা ইন্টারফেসের অংশ নয় এমন কোনও পদ্ধতি ব্যবহার না করা থেকে নিজেকে বিরত রাখতে পারেন, তবে দ্বিতীয় ঘোষণাপত্রটি ব্যবহার করে সংকলক আপনাকে সৎ রাখে।

— টিকটিকিকে বিল দাও
সূত্র
এই কমই কি "সংযোজন" আসলে সম্পর্কিত হয় । কিছু ভাল উত্তরের জন্য stackoverflow.com/questions/39946/coupling- এবং- cohesion দেখুন ।
— রোগরিও
@ রোজারিও: আমি মনে করি এটি সম্পর্কিত। হতে পারে আপনি "সংযুক্তকরণ" এর অন্যান্য সংজ্ঞা দ্বারা বিভ্রান্ত হয়ে পড়েছেন তবে আপনার লুজ কাপলিং পড়া উচিত । "দৃ coup় মিলন ঘটে যখন কোনও নির্ভরশীল শ্রেণিতে সরাসরি একটি কংক্রিট শ্রেণিতে একটি পয়েন্টার থাকে যা প্রয়োজনীয় আচরণ সরবরাহ করে ... আলগা সংযোগ ঘটে তখন নির্ভরশীল শ্রেণিটিতে কেবলমাত্র একটি ইন্টারফেসের পয়েন্টার থাকে, যা পরে এক বা অনেকগুলি কংক্রিট শ্রেণি দ্বারা প্রয়োগ করা যেতে পারে can । " আমার উদাহরণ হিসাবে, আমার কোডটি আলগাভাবে তালিকা ইন্টারফেসের মাধ্যমে একটি অ্যারেলিস্টে মিলিত হবে।
— বিল
@ বিল: লিঙ্কটির জন্য ধন্যবাদ, তবে এই নিবন্ধটি আমার কাছে পুরোপুরি জাল। এটি অন্য ডোমেন (সাংগঠনিক আচরণ) থেকে ধারণাগুলির "পুনরায় ব্যাখ্যা" বলে মনে হচ্ছে, ল্যারি কনস্ট্যান্টাইন দ্বারা মূল সফ্টওয়্যার-নির্দিষ্ট সংজ্ঞাটির বিরোধী : " এন.ইউইকিপিডিয়া.আর.উইকি / কৌপলিং_জেপ কম্পিউটার_সায়েন্স " এর সাথে সংজ্ঞা রাখে "লুজ কাপলিং" এর একটি সংজ্ঞা দেয় ।
— Rogério
@ রোজারিও: কনস্টান্টাইনের কাগজটি ১৯ 197৪ সালে লেখা হয়েছিল। বিগত ৩ 36 বছরে প্রচুর পুনরায় ব্যাখ্যা করা সম্ভব হয়েছে বলে আমি মনে করি, তবে উইকিপিডিয়া নিবন্ধটি এর উত্স বলে আমি মনে করি না। উদাহরণস্বরূপ, নির্ভরতা ইনজেকশন এর মতো নিদর্শনগুলি আমি আমার উত্তরে যেমন বর্ণনা করেছি ঠিক তেমন মিলনকে আলগা করতে ইন্টারফেসের উপর নির্ভর করে।
— বিল করুন
2
@ বিল: অবশ্যই, স্ট্রাকচার্ড ডিজাইনে কনস্টান্টাইনের কাজ পুরানো জিনিস, তবে আমি এটি বাতিল বা আমূলভাবে ব্যাখ্যা করার কোনও কারণ দেখতে ব্যর্থ হই। সংঘবদ্ধতা এবং মিলনের মূল ধারণাগুলি অবজেক্ট ওরিয়েন্টেড ডিজাইনের মূল অংশে রয়েছে ঠিক যেমন উত্তরাধিকার এবং পলিমারফিজম। ডিআই (আরও ভাল নিবন্ধটি মার্টিনফাউলর / আর্টিকেলস / ইনজেকশন হিটটিএমএল ) কেবল প্লাগইনগুলির বহিরাগত কনফিগারেশনের জন্য কৌশল (কনফিগারেশন কোডের মাধ্যমে রানটাইম এ নির্বাচিত প্রয়োগসমূহ সহ বিমূর্ত ইন্টারফেস); এই জাতীয় আর একটি কৌশল হ'ল পরিষেবা লোকেটার প্যাটার্ন। ডিআই এবং সংযুক্তি স্বতন্ত্র ধারণা।
— রোজারিও
27

উত্তরগুলির মধ্যে পার্থক্যের মাত্রাটি বোঝায় যে এটি কেন বুঝতে পারা কঠিন ধারণা হবে তবে আমি যতটা বর্ণনা করতে পারি ঠিক ততটুকু রেখে দেওয়া:

আমার জানতে যাতে আমি যদি আপনার কাছে একটি বল ছুঁড়ে ফেলি তবে আপনি এটি ধরতে পারেন আপনার বয়স কত তা আমার সত্যিই জানতে হবে না। আপনি প্রাতঃরাশের জন্য আপনি কী খেয়েছিলেন তা আমার জানতে হবে না এবং আপনার প্রথম ক্রাশটি কে সে বিষয়ে আমি সত্যিই যত্নশীল নই। আমার যা জানতে হবে তা হ'ল আপনি ধরতে পারবেন। আমি যদি এটি জানি তবে আমি আপনার বা আপনার ভাইয়ের কাছে একটি বল ছুড়ে দিচ্ছি কিনা সে বিষয়ে আমি চিন্তা করি না।

সি # বা জাভা ইত্যাদির মতো অ-গতিশীল ভাষার সাহায্যে আমরা ইন্টারফেসের মাধ্যমে এটি সম্পন্ন করি। সুতরাং আসুন আমরা আমাদের নীচের ইন্টারফেস আছে বলতে পারি:

public ICatcher
{
   public void Catch();
}

এবং এখন বলতে দিন যে আমাদের নিম্নলিখিত ক্লাস রয়েছে:

public CatcherA : ICatcher
{
   public void Catch()
   {
      console.writeline("You Caught it");
   }

}
public CatcherB : ICatcher
{
   public void Catch()
   {
      console.writeline("Your brother Caught it");
   }

}

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

public CatchService
{
   private CatcherA catcher = new CatcherA();

   public void CatchService()
   {
      catcher.Catch();
   }

}

সুতরাং ক্যাচ সার্ভিস ঠিক যা করতে পারে তা করতে পারে তবে এটি ক্যাচারএ ব্যবহার করে এবং সর্বদা ক্যাচারএ ব্যবহার করবে। এটি শক্তভাবে কোডিং হয়েছে, সুতরাং কেউ উপস্থিত না হওয়া এবং এটি পুনরুদ্ধার না করা পর্যন্ত এটি সেখানেই থাকে।

এখন আরেকটি বিকল্প গ্রহণ করা যাক, যার নাম নির্ভরতা ইনজেকশন:

public CatchService
{
   private ICatcher catcher;

   public void CatchService(ICatcher catcher)
   {
      this.catcher = catcher;
      catcher.Catch();
   }
}

সুতরাং ক্যাসস সার্ভিসকে ইনস্ট্যান্সেট করে এমন ক্যালস নিম্নলিখিতগুলি করতে পারে:

CatchService catchService = new CatchService(new CatcherA());

অথবা

CatchService catchService = new CatchService(new CatcherB());

এর অর্থ হ'ল ক্যাচ পরিষেবাটি ক্যাচারএ বা ক্যাচারবি এর সাথে শক্তভাবে মিলিত হয় না।

লসলি কাপলিং পরিষেবাদির জন্য যেমন আইওসি ফ্রেমওয়ার্কের ব্যবহার ইত্যাদির জন্য আরও বেশ কয়েকটি স্ট্রেরজি রয়েছে

— ওয়েন
সূত্র
1
এই উদাহরণটি আমি অন্যগুলির তুলনায় আরও ভাল পছন্দ করি, যেহেতু ব্যবসায় জগতে দিনে দিনে এই জাতীয় জিনিস ঘটে। ক্লাস পার্সন যদি চালায়, ক্লাস ক্যাট রান করে, ক্লাস কুকুর রান করে, ইত্যাদি ইত্যাদি যে ক্লাসগুলি চালিত হয় সেগুলির বিশদ বিবরণ দেওয়ার জন্য এটি একটি বিশাল প্রোগ্রাম হবে। তবে রান নামে পরিচিত একটি ইন্টারফেস ব্যবহার করে, যেখানে প্রতিটি শ্রেণি একই কাজ করে, আপনার প্রোগ্রামকে আরও নমনীয় এবং পরিচালনাযোগ্য করে তুলেছে। :)
— স্ক্যাসলজ
সত্যিই ভাল স্যার ব্যাখ্যা করেছেন, শেষ উদাহরণটি পরিষ্কার করার জন্য আপনি এটি নির্ভরতা ইনজেকশন দিয়ে করেছিলেন, এবং প্রথম উদাহরণটিও আলগাভাবে মিলিত হয়েছে?
— আলী সাজিদ
বাহ, পুরানো উত্তর মন্তব্য করেছে :)। সুতরাং উত্তরটি হ'ল না, প্রথম উদাহরণটির ক্যাচারএর উপর একটি নির্ভরশীলতা রয়েছে তাই তারা দৃ strongly়ভাবে মিলিত হয়েছে
— ওভেন
23

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

— MusiGenesis
সূত্র
1
সুতরাং, "আলগাভাবে মিলিত" এর অর্থ কি কম নির্ভরতা? আমি কি সঠিক?
— ব্যবহারকারী314362
4
এটি একটি নির্দিষ্ট শ্রেণীর নির্ভরশীলতার মোট সংখ্যার সাথে সত্যিই সম্পর্কিত নয়। কাপলিং (টাইট বা আলগা) আসলে দুটি শ্রেণির সম্পর্কের সম্পত্তি। সুতরাং আপনার কাছে এমন একটি ক্লাস থাকতে পারে যা শিথিলভাবে 100 টি অন্যান্য ক্লাসে মিলিত হয় বা অন্য শ্রেণীর সাথে দৃ tight়ভাবে মিলিত হয় কেবল 2 অন্যান্য ক্লাসে (উদাহরণস্বরূপ)।
— মুসিজেনেসিস
2
খারাপ উদাহরণ, আমি বলব: আপনার যা যা কোড ডুপ্লিকেশন, টাইট কাপলিং নয়। এবং একটি ভাল রিফ্যাক্টরিং সরঞ্জাম সহ, এই জাতীয় সদৃশতা কয়েক সেকেন্ডের মধ্যে মুছে ফেলা হতে পারে।
— Rogério
@ রোজারিও: এটি সম্ভবত সেরা উদাহরণ নয়। আমি 64BitBobনিজের উত্তরটি আরও ভাল পছন্দ করি।
— MusiGenesis
12

সংজ্ঞা

মূলত, সংযুক্তি হ'ল কোনও প্রদত্ত বস্তু বা বস্তুর সেট তার কাজটি সম্পাদন করার জন্য অন্য কোনও বস্তু বা অন্য কোনও সামগ্রীর উপর কতটা নির্ভর করে।

উচ্চ মিলন

গাড়ি ভাবি। ইঞ্জিনটি শুরু করার জন্য, জ্বলন্ত জ্বালায় একটি কী প্রবেশ করানো উচিত, ঘুরিয়ে দেওয়া হবে, পেট্রল উপস্থিত থাকতে হবে, একটি স্পার্ক অবশ্যই হবে, পিস্টনগুলিকে গুলি চালাতে হবে এবং ইঞ্জিনটি জীবন্ত আসতে হবে। আপনি বলতে পারেন যে একটি গাড়ী ইঞ্জিন বেশ কয়েকটি অন্যান্য অবজেক্টের সাথে একত্রে মিশ্রিত। এটি উচ্চ মিলন, তবে এটি আসলে খারাপ জিনিস নয়।

আলগা সংযোজন

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

— টম
সূত্র
7

এটি একটি দুর্দান্ত সাধারণ ধারণা, তাই কোড উদাহরণগুলি পুরো ছবি দেয় না।

এখানে কর্মরত একজন লোক আমাকে বলেছিল, "নিদর্শনগুলি ফ্র্যাক্টালগুলির মতো, আপনি যখন সত্যই কাছাকাছি জুম করেন এবং আপনি যখন আর্কিটেকচার স্তরের দিকে জুম করেন তখন আপনি সেগুলি দেখতে পাবেন" "

সংক্ষিপ্ত উইকিপিডিয়া পৃষ্ঠাটি পড়লে আপনি এই সাধারণতার উপলব্ধি করতে পারেন:

http://en.wikipedia.org/wiki/Loose_coupling

একটি নির্দিষ্ট কোড উদাহরণ হিসাবে ...

মাইক্রোসফ্ট.প্র্যাকটিসস.কম্পোসাইটিউআই স্টাফ থেকে সাম্প্রতিক সময়ে আমি কাজ করেছি এমন একটি শিথিল দম্পতি এখানে।

    [ServiceDependency]
    public ICustomizableGridService CustomizableGridService
    {
        protected get { return _customizableGridService; }
        set { _customizableGridService = value; }
    }

এই কোডটি ঘোষণা করছে যে এই শ্রেণীর একটি কাস্টমাইজেবলগ্রিডসেবার উপর নির্ভরতা রয়েছে। কেবলমাত্র পরিষেবাটির সঠিক প্রয়োগের জন্য সরাসরি উল্লেখ করার পরিবর্তে এটি কেবলমাত্র বলে যে এটির সেই পরিষেবার কিছু বাস্তবায়ন প্রয়োজন। তারপরে রানটাইমে, সিস্টেমটি সেই নির্ভরতা সমাধান করে।

যদি এটি পরিষ্কার না হয় তবে আপনি এখানে আরও বিস্তারিত ব্যাখ্যা পড়তে পারেন:

http://en.wikipedia.org/wiki/Dependency_injection

কল্পনা করুন যে এবিসি কাস্টমাইজিবলগ্রিড সার্ভিস হ'ল আমি এখানে নকল করার ইচ্ছা করি।

যদি আমি এটি বেছে নিই তবে আমি এটিকে ঝাঁপিয়ে পড়ে XYZCustomizableGridService, বা StubCustomizableGridService এর সাথে ক্লাসে কোনও নির্ভরতা ছাড়াই এই নির্ভরতার সাথে পরিবর্তন করতে পারি।

আমি যদি সরাসরি ABCCustomizableGridService রেফারেন্স করে থাকি, তবে অন্য কোনও পরিষেবা বাস্তবায়নের জন্য অদলবদল করার জন্য আমার সেই / সেই রেফারেন্সগুলিতে পরিবর্তন করা দরকার।

— ধান
সূত্র
6

কাপলিংয়ের সাথে সিস্টেমের মধ্যে নির্ভরতা রয়েছে যা কোডের মডিউল (ফাংশন, ফাইল বা ক্লাস) হতে পারে, পাইপলাইনের সরঞ্জামগুলি, সার্ভার-ক্লায়েন্ট প্রক্রিয়াগুলি এবং আরও অনেক কিছু। নির্ভরতাগুলি যত কম সাধারণ হয়, তত বেশি "দৃ .়ভাবে মিলিত" হয়, যেহেতু একটি সিস্টেম পরিবর্তনের জন্য অন্যান্য সিস্টেমগুলি নির্ভর করে যা এটি নির্ভর করে। আদর্শ পরিস্থিতি হ'ল "লুজ কাপলিং" যেখানে একটি সিস্টেম পরিবর্তন করা যেতে পারে এবং এর উপর নির্ভরশীল সিস্টেমগুলি পরিবর্তন ছাড়াই কাজ চালিয়ে যাবে to

আলগা সংযোগ অর্জনের সাধারণ উপায় হ'ল সংজ্ঞায়িত ইন্টারফেসের মাধ্যমে। যদি দুটি সিস্টেমের মধ্যে মিথস্ক্রিয়াটি ভালভাবে সংজ্ঞায়িত হয় এবং উভয় পক্ষের সাথে মেনে চলা হয়, তবে কনভেনশনগুলি ভঙ্গ না হওয়ার বিষয়টি নিশ্চিত করে একটি সিস্টেম পরিবর্তন করা সহজ হয়ে যায়। এটি সাধারণত অনুশীলনে দেখা যায় যে কোনও সু-সংজ্ঞায়িত ইন্টারফেস প্রতিষ্ঠিত হয়নি, ফলস্বরূপ একটি opালু নকশা এবং আঁটসাঁটো মিলন ঘটে।

কিছু উদাহরণ:

  • অ্যাপ্লিকেশন একটি গ্রন্থাগারের উপর নির্ভর করে। শক্ত সংযোগের অধীনে, অ্যাপ্লিকেশনটি লাইবের নতুন সংস্করণগুলিতে বিরতি দেয় on "ডিএলএল হেল" এর জন্য গুগল।

  • ক্লায়েন্ট অ্যাপ্লিকেশন কোনও সার্ভার থেকে ডেটা পড়ে। কড়া সংশ্লেষের অধীনে, সার্ভারে পরিবর্তনগুলি ক্লায়েন্টের পক্ষ থেকে সংশোধন করা দরকার।

  • দুটি শ্রেণি একটি অবজেক্ট-ওরিয়েন্টড হায়ারার্কিতে ইন্টারঅ্যাক্ট করে। কঠোর সংশ্লেষের অধীনে, এক শ্রেণিতে পরিবর্তনের জন্য অন্য শ্রেণীর সাথে তাল মিলিয়ে আপডেট করতে হবে।

  • একাধিক কমান্ড-লাইন সরঞ্জাম একটি পাইপে যোগাযোগ করে। যদি তারা দৃly়ভাবে মিলিত হয়, তবে একটি কমান্ড-লাইন সরঞ্জামের সংস্করণে পরিবর্তনগুলি এর আউটপুট পড়ার সরঞ্জামগুলিতে ত্রুটি ঘটায়।

— Parappa
সূত্র
5

কাপলিং বলতে বোঝায় যে কীভাবে শক্তিশালীভাবে বিভিন্ন ক্লাস একে অপরের সাথে সংযুক্ত রয়েছে। কড়া দম্পতিযুক্ত ক্লাসে আন্তঃসংযোগ এবং নির্ভরতা সংখ্যক থাকে contain

আলতোভাবে সংযুক্ত ক্লাসগুলি একে অপরের উপর নির্ভরশীলতা সর্বনিম্ন রাখা হয় এবং পরিবর্তে একে অপরের সুস্পষ্ট সংজ্ঞায়িত পাবলিক ইন্টারফেসের উপর নির্ভর করে তার বিপরীতে।

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

তথ্যসূত্র: https://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/

— user1263981
সূত্র
4

দুটি উপাদান হিজলি মিলিত হয় যখন তারা একে অপরের কংক্রিট বাস্তবায়নের উপর নির্ভর করে।

ধরুন আমার ক্লাসের কোনও পদ্ধতিতে আমার এই কোডটি রয়েছে:

this.some_object = new SomeObject();

এখন আমার ক্লাসটি সামোবজেক্টের উপর নির্ভর করে এবং তারা বেশ জোড়ায়। অন্যদিকে, ধরা যাক আমার কাছে একটি পদ্ধতি ইনজেক্টসোমজেক্ট রয়েছে:

void InjectSomeObject(ISomeObject so) { // note we require an interface, not concrete implementation
  this.some_object = so;
}

তারপরে প্রথম উদাহরণটি কেবল ইনজেক্টেড সামোরবজেক্ট ব্যবহার করতে পারে। এটি পরীক্ষার সময় দরকারী useful সাধারণ ক্রিয়াকলাপের সাহায্যে আপনি ভারী, ডাটাবেস-ব্যবহার, নেটওয়ার্ক-ব্যবহারের ক্লাস ইত্যাদি ব্যবহার করতে পারেন যখন হালকা ওজনের, মক প্রয়োগ বাস্তবায়নের পরীক্ষার জন্য।শক্তভাবে কাপল কোড সহ আপনি এটি করতে পারবেন না।

নির্ভরতা ইঞ্জেকশন পাত্রে ব্যবহার করে আপনি এই কাজের কিছু অংশকে সহজতর করতে পারেন। আপনি ডিআইডি সম্পর্কে আরও উইকিপিডিয়ায় পড়তে পারেন: http://en.wikedia.org/wiki/D dependency_inication ।

কখনও কখনও এটি খুব বেশি দূরে নেওয়া সহজ হয়। এক পর্যায়ে আপনাকে জিনিসগুলি কংক্রিট করতে হবে, বা আপনার প্রোগ্রামটি কম পাঠযোগ্য এবং বোধগম্য হবে। তাই মূলত উপাদানগুলির সীমানায় এই কৌশলগুলি ব্যবহার করুন এবং জেনে রাখুন আপনি কী করছেন। আপনি আলগা দম্পতির সুবিধা নিচ্ছেন তা নিশ্চিত করুন। যদি তা না হয় তবে আপনার সম্ভবত এটি দরকার নেই। ডিআই আপনার প্রোগ্রামটিকে আরও জটিল করে তুলতে পারে। আপনি একটি ভাল ট্রেড অফ করেছেন তা নিশ্চিত করুন। অন্য কথায়, ভাল ভারসাম্য বজায় রাখুন। সিস্টেম ডিজাইনিং করার সময় সর্বদা হিসাবে। শুভকামনা!

— পাওয়ে হাজদান
সূত্র
3

ফর্মএ এবং ফর্মবি সহ একটি উইন্ডোজ অ্যাপ বিবেচনা করুন। ফর্মএ প্রাথমিক ফর্ম এবং এটি ফর্মবি প্রদর্শন করে। কল্পনা করুন যে ফর্মবাকে তার পিতামাতার কাছে ডেটা ফেরত দেওয়া দরকার।

আপনি যদি এটি করেন:

class FormA 
{
    FormB fb = new FormB( this );

    ...
    fb.Show();
}

class FormB 
{
    FormA parent;

    public FormB( FormA parent )
    {
        this.parent = parent;
    }     
}

ফরম্যাব শক্তিশালীভাবে ফর্মার সাথে মিলিত হয়। ফর্ম্যাবি টাইপ ফর্মার চেয়ে অন্য কোনও পিতামাতার থাকতে পারে।

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

RP

— RP।
সূত্র
3

কম্পিউটার বিজ্ঞানে "আলগা কাপলিং" এর আরেকটি অর্থ রয়েছে যা এখানে অন্য কেউ পোস্ট করেনি, তাই ... এখানে যায় - আশা করি আপনি আমাকে কিছু ভোট দেবেন যাতে এটি স্তূপের নীচে হারিয়ে যায় না! অবশ্যই আমার উত্তরের বিষয়টি প্রশ্নের যে কোনও ব্যাপক উত্তরের সাথে সম্পর্কিত ... বুদ্ধিমানের জন্য:

"লুজ কাপলিং" শব্দটি প্রথমে মাল্টি-সিপিইউ কনফিগারেশনে সিপিইউ আর্কিটেকচার সম্পর্কিত বিশেষণ হিসাবে ব্যবহৃত একটি শব্দ হিসাবে কম্পিউটারে প্রবেশ করেছিল। এর সমমর্যাদাপূর্ণ শব্দটি "টাইট কাপলিং"। লুজ কাপলিং তখন হয় যখন সিপিইউগুলি প্রচুর সংস্থান ভাগ করে না এবং টাইট কাপলিং যখন হয় তখন।

"সিস্টেম" শব্দটি এখানে বিভ্রান্তিকর হতে পারে তাই দয়া করে পরিস্থিতিটি সাবধানে বিশ্লেষণ করুন।

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

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

প্রথমত, যেহেতু এটিই প্রশ্নটি ছিল তাই লুজলি কাপলড সিস্টেমগুলির কয়েকটি উদাহরণ:

  • VaxClusters
  • লিনাক্স ক্লাস্টার্স

বিপরীতে, কিছু শক্তভাবে দম্পতি উদাহরণ:

  • সেমেট্রিকাল-মাল্টি-প্রসেসিং (এসএমপি) অপারেটিং সিস্টেম - যেমন ফেডোরা 9 ora
  • মাল্টি থ্রেডেড সিপিইউ
  • মাল্টি-কোর সিপিইউ

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

— রিচার্ড টি
সূত্র
3

সহজ ভাষায়, আলগাভাবে মিলিত হওয়ার অর্থ এটি ঘটে যাওয়া অন্যান্য ইভেন্টের উপর নির্ভর করে না। এটি স্বাধীনভাবে কার্যকর করে।

— রবীন্দ্র মিয়াণী
সূত্র
1
এটি সত্যিই সত্য নয় - যেমন অন্যান্য উদাহরণে উল্লেখ করা হয়েছে, সত্তার (মডিউল, শ্রেণি) মধ্যে সম্পর্ক আছে কি না তা নিয়ে এতটা জানা যায় না, তবে একই কার্যকারিতা বাস্তবায়নের জন্য অন্যান্য শ্রেণীর জন্য তাদের সহজেই সরিয়ে নেওয়া যায় কি না। উদাহরণস্বরূপ একটি ভিউমোডেল বিভিন্ন মডেলের সাথে কাজ করতে পারে তবে এটি অবশ্যই একটি ছাড়া কাজ করবে না
— ক্রকার
হ্যাঁ, খুব সহায়ক নয়
— brgs
2

কিছু দীর্ঘ উত্তর এখানে। নীতি যদিও খুব সহজ। আমি উইকিপিডিয়া থেকে উদ্বোধনী বিবৃতি জমা দিচ্ছি :

"আলগা সংযোগ দুটি বা ততোধিক সিস্টেম বা সংস্থার মধ্যে কিছু ধরণের বিনিময় সম্পর্কের মধ্যে একটি স্থিতিস্থাপক সম্পর্কের বর্ণনা দেয়।

লেনদেনের প্রতিটি প্রান্তটি তার প্রয়োজনীয়তাগুলি সুস্পষ্ট করে তোলে এবং অন্য প্রান্তটি সম্পর্কে কিছুটা অনুমান করে। "

— বেন অ্যাস্টন
সূত্র
1
যদি এটি এত সহজ ছিল, তবে আমাদের এই আলোচনা হবে না।
— brgs
2

আমি কোড কাপলিংয়ের একটি খুব সাধারণ টেস্টের প্রস্তাব করছি :

  1. পিস এ কোডের টুকরোটি দৃ tight়ভাবে কোড পিস বি-তে সংযুক্ত করা হয়েছে যদি পিস বি তে কোনও সম্ভাব্য সংশোধনী উপস্থিত থাকে যা সঠিকতা ধরে রাখতে পিস এ-তে পরিবর্তন আনতে বাধ্য করবে।

  2. পিস বি এর কোড পিস বি তে শক্তভাবে মিলিত হবে না যদি পিস বি তে কোনও সম্ভাবনা পরিবর্তন হয় যা পিস এটিতে পরিবর্তন আনতে পারে।

এটি আপনাকে আপনার কোডের টুকরাগুলির মধ্যে কতটা সংযুক্ত রয়েছে তা যাচাই করতে সহায়তা করবে। যে যুক্তি জন্য এই ব্লগ পোস্টে দেখুন: http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/

— মারেক ডিসেম্বর
সূত্র
2

আপনি যখন ব্যবহার করে কোনও শ্রেণীর অবজেক্ট তৈরি করেন new কীওয়ার্ড , আপনি আসলে কঠোর সংযুক্তি করছেন (খারাপ অভ্যাস) পরিবর্তে আপনার আলগা দম্পতি ব্যবহার করা উচিত যা একটি ভাল অনুশীলন is

--- A.java ---

package interface_package.loose_coupling;

public class A {

void display(InterfaceClass obji)
{
    obji.display();
    System.out.println(obji.getVar());
}
}

--- B.java ---

package interface_package.loose_coupling;

public class B implements InterfaceClass{

private String var="variable Interface";

public String getVar() {
    return var;
}

public void setVar(String var) {
    this.var = var;
}

@Override
public void display() {
    // TODO Auto-generated method stub
    System.out.println("Display Method Called");
}
}

--- InterfaceClass ---

package interface_package.loose_coupling;

public interface InterfaceClass {

void display();
String getVar();
}

--- MainClass ---

package interface_package.loose_coupling;

public class MainClass {

public static void main(String[] args) {
    // TODO Auto-generated method stub

    A obja=new A();
    B objb=new B();
    obja.display(objb);     //Calling display of A class with object of B class 

}
}

ব্যাখ্যা:

উপরের উদাহরণে, আমাদের দুটি এবং ক ক্লাস রয়েছে

ক্লাস বি ইন্টারফেস অর্থাত্ ইন্টারফেসক্লাস প্রয়োগ করে।

ইন্টারফেসক্লাস বি শ্রেণীর জন্য একটি চুক্তি সংজ্ঞায়িত করে কারণ ইন্টারফেসক্লাসে বি শ্রেণীর বিমূর্ত পদ্ধতি রয়েছে যা অন্য কোনও শ্রেণীর দ্বারা অ্যাক্সেস হতে পারে উদাহরণস্বরূপ এ।

ক্লাস এ-তে আমাদের ডিসপ্লে পদ্ধতি রয়েছে যা ইন্টারফেসক্লাস প্রয়োগ করে এমন শ্রেণীর অবজেক্ট ছাড়া (আমাদের ক্ষেত্রে এটি বি শ্রেণি) থাকে। এবং ক্লাস A এর সেই অবজেক্টের পদ্ধতিতে ক্লাস বি এর প্রদর্শন () এবং getVar () কল করা হচ্ছে

মেইনক্লাসে আমরা ক্লাস এ এবং বি এর অবজেক্ট তৈরি করেছি এবং বি ক্লাসের অবজেক্টকে পাশ করে অ্যাজব দ্বারা ক এর ডিসপ্লে মেথড। A এর প্রদর্শন পদ্ধতিটি বি শ্রেণীর অবজেক্টের সাথে কল করা হবে called

এখন আলগা দম্পতি সম্পর্কে কথা বলছি। মনে করুন ভবিষ্যতে আপনার ক্লাস বি এর নামটি এবিসিতে পরিবর্তন করতে হবে তবে আপনাকে ক্লাস বি এর ডিসপ্লে পদ্ধতিতে এর নাম পরিবর্তন করতে হবে না, কেবল নতুন (এবিসি ক্লাস) এর অবজেক্ট তৈরি করুন এবং এটি মেলক্লাসে প্রদর্শন পদ্ধতিতে পাস করুন। ক্লাস এ তে আপনাকে কোনও পরিবর্তন করতে হবে না

রেফ: http://p3lang.com/2013/06/loose-coupling-example- using-interface/

— অভিষেক আগরওয়াল
সূত্র
0

"লুজ কাপলিং" এর জেনেরিক ধারণা সম্পর্কে আপনি আরও পড়তে পারেন ।

সংক্ষেপে, এটি দুটি শ্রেণীর মধ্যে সম্পর্কের বর্ণনা, যেখানে প্রতিটি শ্রেণি একে অপরের সম্পর্কে খুব কম জানে এবং প্রতিটি শ্রেণি সম্ভবত অন্যরকম উপস্থিত রয়েছে কিনা এবং অন্যটির নির্দিষ্ট বাস্তবায়নের উপর নির্ভরতা ছাড়াই ঠিকঠাক কাজ চালিয়ে যেতে পারে বর্গ।

— ফ্রেঞ্চি পেনভ
সূত্র
-8

লুজ কাপলিং, সাধারণভাবে, 2 জন অভিনেতা একই কাজের চাপে একে অপরের থেকে স্বতন্ত্রভাবে কাজ করছেন। সুতরাং যদি আপনার কাছে একই ব্যাক-এন্ড ডাটাবেস ব্যবহার করে 2 টি ওয়েব সার্ভার থাকে, তবে আপনি বলবেন যে সেই ওয়েব সার্ভারগুলি আলগাভাবে মিলিত। একটি ওয়েব সার্ভারে 2 জন প্রসেসর রেখে শক্ত কৃপণকরণের উদাহরণ দেওয়া হবে ... process প্রসেসরগুলি দৃ coup়ভাবে কাপলযুক্ত।

আশা করি এটি কিছুটা সহায়ক।

— স্টিভ
সূত্র
1
আপনি যা যাচ্ছেন তা আমি দেখতে পাচ্ছি, তবে এখনও দুটি 'জিনিস' একে অপরের উপর পরস্পরের উপর নির্ভরশীল যখন দুটি 'জিনিস' স্বতন্ত্রভাবে উপস্থিত থাকে - যেখানে একটি 'জিনিস' পারে অন্য 'জিনিসে' পরিবর্তন না করেই বদলে যেতে হবে ...
— ব্রায়ান রেহবেইন
স্টিভ, আপনি একদম ঠিক বলেছেন - ডাউন-ভোটের কোনওটিই আপনার প্রাপ্য নয়। এটি কেবলমাত্র আপনার শ্রোতা আপনার পরিভাষার জন্য প্রস্তুত ছিলেন না এবং এই সাইটের অনেকেরই তারা কী বোঝেন না বা অপরিচিত তা কী ভোট দেওয়ার অভ্যাস রয়েছে। -শ্রোগ-
— রিচার্ড টি
আমি মনে করি স্টিভ বিন্দুটি মিস করেছেন। আলগা সংযুক্তকরণ সর্বদা 2 জন অভিনেতা একই কাজের চাপে স্বতন্ত্রভাবে কাজ করে বোঝায় না।
— রব
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.