ব্যবসায়ের অবজেক্ট শ্রেণির নকশার এই "সম্পূর্ণ জনসাধারণ" মানসিকতার বিরুদ্ধে কীভাবে তর্ক করা যায়


9

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

একটি উদাহরণ বর্গ যা আমি ভক্ত নই:

public class Foo
{
    private string field1;
    private string field2;
    private string field3;
    private string field4;
    private string field5;

    public Foo() { }

    public Foo(string in1, string in2)
    {
        field1 = in1;
        field2 = in2;
    }

    public Foo(string in1, string in2, string in3, string in4)
    {
        field1 = in1;
        field2 = in2;
        field3 = in3;
    }

    public Prop1
    { get { return field1; } }
    { set { field1 = value; } }

    public Prop2
    { get { return field2; } }
    { set { field2 = value; } }

    public Prop3
    { get { return field3; } }
    { set { field3 = value; } }

    public Prop4
    { get { return field4; } }
    { set { field4 = value; } }

    public Prop5
    { get { return field5; } }
    { set { field5 = value; } }

}

"আসল" শ্রেণিতে এগুলি সমস্ত স্ট্রিং নয়, তবে কিছু ক্ষেত্রে সম্পূর্ণ জনসাধারণের সম্পত্তি হিসাবে আমাদের 30 টি ব্যাকিং ফিল্ড রয়েছে।

আমি এই শ্রেণিকে ঘৃণা করি এবং আমি জানি না আমি কেবল পিক হয়ে যাচ্ছি কিনা। নোটের কয়েকটি বিষয়:

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

আমি বাস্তবায়নকারী হিসাবে যেকোন সময়ে কোনও সময়ে অবজেক্টটি কী অবস্থায় রয়েছে তা সত্যিই জানতে আরও বেশি সমস্যা অনুভব করি Foo। যুক্তিটি তৈরি করা হয়েছিল " Prop5অবজেক্ট তৈরির সময় আমাদের কাছে প্রয়োজনীয় তথ্য নাও থাকতে পারে Ok ঠিক আছে, আমি অনুমান করি যে আমি এটি বুঝতে পারি, তবে যদি এটি হয় তবে কেবল Prop5সেটারটিকেই সর্বজনীন করুন, সবসময় কোনও শ্রেণীর 30 টি সম্পত্তি নয়।

আমি কি "সহজ লেখার (সর্বজনীন)" লেখার বিপরীতে "সহজেই ব্যবহারযোগ্য" এমন শ্রেণি চাইবার জন্য কি নিট-পিক এবং / বা পাগল হয়ে যাচ্ছি? উপরের মতো ক্লাসগুলি আমাকে চিৎকার করে, আমি জানি না এটি কীভাবে ব্যবহৃত হবে, তাই আমি কেবল সবকিছু ক্ষেত্রে সর্বজনীন করে তুলছি

যদি আমি ভয়ঙ্করভাবে পিক না হয়ে থাকি তবে এই ধরণের চিন্তাভাবনার বিরুদ্ধে লড়াই করার জন্য ভাল যুক্তিগুলি কী কী? আমি যুক্তিগুলি উচ্চারণে খুব ভাল নই, কারণ আমি আমার বক্তব্যটি জানতে ইচ্ছাকৃতভাবে হতাশ হয়ে পড়েছি (ইচ্ছাকৃতভাবে নয়)।



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

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

3
বৈশিষ্ট্যগুলিতে কোনও যুক্তিবিহীন ব্যক্তিগত ব্যাকিং ফিল্ডগুলির জন্য, আপনি অটো বৈশিষ্ট্যগুলি ব্যবহার করছেন না এমন কোনও কারণ আছে কি ?
কারসন 63000

2
@ ক্রিটনার অটো-প্রোপার্টিগুলির পুরো বিন্দুটি হ'ল যদি ভবিষ্যতে আপনার যদি সত্যিকারের যুক্তি প্রয়োজন হয় তবে আপনি এটি getset
নির্বিঘ্নে অটোটির

উত্তর:


10

সম্পূর্ণরূপে পাবলিক ক্লাসগুলির নির্দিষ্ট পরিস্থিতিতে, পাশাপাশি অন্যান্য চরম, শুধুমাত্র একটি জনসাধারণের পদ্ধতি (এবং সম্ভবত প্রচুর ব্যক্তিগত পদ্ধতি) সহ ক্লাসগুলির যৌক্তিকতা রয়েছে। এবং কিছু জনসাধারণের সাথে ক্লাস, কিছু ব্যক্তিগত পদ্ধতিও।

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

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

আপনার অন্যান্য বিষয়গুলি সম্বোধন করতে:

  • "সম্পত্তিগুলিতে কোনও যুক্তি ছাড়াই ব্যক্তিগত ব্যাকিং ফিল্ডস": হ্যাঁ, আপনি ঠিক বলেছেন, তুচ্ছ গিটার এবং সেটটারদের জন্য এটি কেবল অযৌক্তিক "গোলমাল"। এই জাতীয় "ফোলা" এড়াতে, সি # এর সম্পত্তি পেতে / সেট পদ্ধতিগুলির জন্য একটি শর্ট-কাট বাক্য গঠন রয়েছে:

পরিবর্তে তাই

   private string field1;
   public string Prop1
   { get { return field1; } }
   { set { field1 = value; } }

লেখার

   public string Prop1 { get;set;}

অথবা

   public string Prop1 { get;private set;}
  • "একাধিক নির্মাণকারী": এটি নিজেই কোনও সমস্যা নয়। যখন সেখানে অযথা কোডের সদৃশতা রয়েছে, যেমন আপনার উদাহরণে প্রদর্শিত বা কলিং শ্রেণিবিন্যাসকে বিশৃঙ্খলাবদ্ধ করা হয় তখন এটি একটি সমস্যা হয়। এটি সাধারণ অংশগুলিকে পৃথক ফাংশনে রিফ্যাক্ট করে এবং নির্দ্বিধায় কন্সট্রাক্টর চেইন সাজিয়ে সহজেই সমাধান করা যায়

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

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


ধন্যবাদ, হ্যাঁ আমি জানি পোকো / পোগোদের তাদের জায়গা আছে এবং আমার উদাহরণটি বেশ বিমূর্ত। আমি মনে করি না তবে আমি কোনও উপন্যাসে না গিয়ে আরও সুনির্দিষ্ট হয়ে উঠতে পারি।
ক্রিটনার

@ ক্রিটার: আমার সম্পাদনা দেখুন
ডক ব্রাউন

হ্যাঁ আমি যখন একেবারে নতুন ক্লাস তৈরি করি তখন আমি অটো প্রপার্টি রুটে যাই। "কেবল কারণ" হিসাবে ব্যক্তিগত ব্যাকিং ফিল্ড থাকা অপরিশোধিত এবং এমনকি সমস্যা সৃষ্টি করে। যখন আপনার একটি ক্লাস এবং 100+ ক্লাসে 30 ডলার সম্পত্তি রয়েছে, তখন এটি বলার অপেক্ষা রাখে না যে এখানে কিছু সম্পত্তি সেট করা আছে বা ভুল ব্যাকিং ফিল্ড থেকে পাওয়া যাচ্ছে ... বাস্তবে আমাদের রিফ্যাক্টারে আমি ইতিমধ্যে বেশ কয়েকবার এর মুখোমুখি হয়েছি I've :)
ক্রিটনার

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

অনেকগুলি আনসেট বৈশিষ্ট্য ছাড়াও, এই শ্রেণীর মূল সমস্যাটি হ'ল এটির শূন্য যুক্তি (জেডআরপি) রয়েছে এবং এটি অ্যানমিক মডেলটির প্রত্নতাত্ত্বিক। এটির প্রয়োজন ছাড়াই যা কথায় কথায় প্রকাশ করা যায়, যেমন একটি ডিটিও, এটি একটি দুর্বল নকশা।
user949300

2
  1. "সম্পত্তিগুলিতে কোনও যুক্তিবিহীন ব্যক্তিগত ব্যাকিং ফিল্ডগুলি অপ্রয়োজনীয় বলে মনে হয় এবং ক্লাসটি ব্লাট করে" বলে আপনার ইতিমধ্যে একটি শালীন যুক্তি রয়েছে।

  2. একাধিক কনস্ট্রাক্টররা এখানে সমস্যা বলে মনে হচ্ছে না।

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

  4. আমি মনে করি আপনি যখন "আচরণের পরীক্ষা করা কঠিন" বলবেন তখন যুক্তিটি নিজের পক্ষে কথা বলে। আপনার পরীক্ষায় এটি নাল নয় বা এর মতো কিছু আছে কিনা (প্রতিটি জায়গা যেখানে সম্পত্তি ব্যবহৃত হয়) তা পরীক্ষা করতে পারে। আমি সত্যিই জানি না কারণ আপনার পরীক্ষা / অ্যাপ্লিকেশন কেমন লাগে তা আমি জানি না।

  5. আপনি সঠিকভাবে অনেকগুলি সম্পত্তি, আপনি কি উত্তরাধিকার ব্যবহারের চেষ্টা করতে পারেন (যদি সম্পত্তিগুলি যথেষ্ট পরিমাণে সমান হয়) এবং তারপরে জেনেরিকগুলি ব্যবহার করে একটি তালিকা / অ্যারে রয়েছে? তারপরে আপনি তথ্যগুলি অ্যাক্সেস করতে getters / setters লিখতে পারবেন এবং আপনি যেভাবে সমস্ত বৈশিষ্ট্যটি ব্যবহার করবেন সেভাবে সহজতর করবেন।


1
ধন্যবাদ - # 1 এবং # 4 আমি অবশ্যই আমার যুক্তি তৈরির সাথে সবচেয়ে স্বাচ্ছন্দ্য বোধ করছি। আপনি # 3 এ কী বোঝাতে চাইছেন তা পুরোপুরি নিশ্চিত নয়। # 5 ক্লাসে থাকা বেশিরভাগ সম্পত্তি ডিবিতে প্রাথমিক কী তৈরি করে। আমরা প্রতিযোগিতামূলক কীগুলি ব্যবহার করি, কখনও কখনও 8 টি কলাম পর্যন্ত - তবে এটি অন্য সমস্যা। আমি সেই অংশগুলিকে নিজের শ্রেণি / কাঠামোর মধ্যে কী তৈরি করার চেষ্টা করার কথা ভাবছিলাম যা অনেকগুলি সম্পত্তি (কমপক্ষে এই শ্রেণীর মধ্যে) মুছে ফেলবে - তবে এটি একাধিক সহ কোডের হাজারো লাইনের একটি উত্তরাধিকার আবেদন কলারের। তাই আমি অনুমান আমি অনেক সম্পর্কে :) চিন্তা করতে হবে
Kritner

অঁ্যা। যদি শ্রেণিটি অপরিবর্তনীয় ছিল তবে শ্রেণীর অভ্যন্তরে কোনও সিঙ্ক্রোনাইজেশন কোড লেখার কোনও কারণ নেই।
রাবারডাক

@ রাবারডাক এই শ্রেণিটি কি অপরিবর্তনীয়? আপনি কি বোঝাতে চেয়েছেন?
স্নুপ

3
এটা স্পষ্টভাবে এর না অপরিবর্তনীয় @StevieV। সম্পত্তি সেটারের সাথে যে কোনও শ্রেণিই পরিবর্তনযোগ্য।
রাবারডাক

1
@ ক্রিটনার কীভাবে বৈশিষ্ট্যগুলি প্রাথমিক কী হিসাবে ব্যবহৃত হবে? সম্ভবত এটির জন্য কিছু যুক্তি (নাল চেক) বা নিয়ম প্রয়োজন (উদাহরণস্বরূপ NAME এজিইর চেয়ে বেশি অগ্রাধিকার নেয়)। ওওপি অনুসারে, এই কোডটি এই শ্রেণীর অন্তর্ভুক্ত। আপনি কি এটি একটি যুক্তি হিসাবে ব্যবহার করতে পারেন?
user949300

2

আপনি Fooযেমন আমাকে বলেছিলেন, এটি একটি ব্যবসায়িক বিষয়। এটি আপনার ডোমেন অনুসারে পদ্ধতিতে কিছু আচরণকে আবশ্যক এবং এর ডেটা যথাসম্ভব এনপ্যাপুলেটেড থাকতে হবে।

আপনি যে উদাহরণটি দেখান তাতে Fooআরও একটি ডিটিওর মতো লাগে এবং সমস্ত ওওপি নীতিগুলির বিরুদ্ধে যায় (দেখুন অ্যানিমিক ডোমেন মডেল )!

উন্নতি হিসাবে আমি সুপারিশ করবে:

এই মন্তব্যগুলির সাথে এটি একটি সম্ভাব্য রিফ্যাক্টর শ্রেণি হতে পারে:

public sealed class Foo
{
    private readonly string field1;
    private readonly string field2;
    private readonly string field3;
    private readonly string field4;

    public Foo() : this("default1", "default2")
    { }

    public Foo(string in1, string in2) : this(in1, in2, "default3", "default4")
    { }

    public Foo(string in1, string in2, string in3, string in4)
    {
        field1 = in1;
        field2 = in2;
        field3 = in3;
        field4 = in4;
    }

    //Methods with business logic

    //Really needed ?
    public Prop1
    { get; }

    //Really needed ?
    public Prop2
    { get; }

    //Really needed ?
    public Prop3
    { get; }

    //Really needed ?
    public Prop4
    { get; }

    //Really needed ?
    public Prop5
    { get; }
}

2

ব্যবসায়ের অবজেক্ট শ্রেণির নকশার এই "সম্পূর্ণ জনসাধারণ" মানসিকতার বিরুদ্ধে কীভাবে তর্ক করা যায়

  • "ক্লায়েন্ট ক্লাসে বিভিন্ন পদ্ধতি ছড়িয়ে ছিটিয়ে রয়েছে (যেমন) 'নিছক ডিটিও দায়িত্ব' ছাড়াও আরও কিছু করছেন doing তারা একত্রে অন্তর্ভুক্ত" "
  • "এটি একটি 'ডিটিও' হতে পারে তবে এটির ব্যবসায়িক পরিচয় রয়েছে - আমাদের সমান ওভাররাইড করা দরকার।"
  • "আমাদের এগুলি বাছাই করতে হবে - আমাদের আইকোম্যাপেবল প্রয়োগ করতে হবে"
  • "আমরা এই বৈশিষ্ট্যগুলির কয়েকটি একসাথে স্ট্রিং করছি Let's তোস্ট্রিংকে ওভাররাইড করুন যাতে প্রতিটি ক্লায়েন্টকে এই কোডটি লিখতে না হয়।"
  • "এই ক্লাসে আমাদের একাধিক ক্লায়েন্ট একই কাজ করছে We আমাদের কোডটি চালিয়ে নেওয়া দরকার" "
  • "ক্লায়েন্ট এই জিনিসগুলির একটি সংগ্রহকে পরিচালনা করছেন It's এটি কাস্টম সংগ্রহের শ্রেণি হওয়া সহজ obvious এবং পূর্ববর্তী অনেকগুলি বিষয় কাস্টম সংগ্রহটি বর্তমানের তুলনায় আরও কার্যকরী করে তুলবে।"
  • "সমস্ত ক্লান্তিকর, উদ্ভাসিত, স্ট্রিং ম্যানিপুলেশন দেখুন! ব্যবসায়ের সাথে সম্পর্কিত পদ্ধতিতে আমাদের কোডিং উত্পাদনশীলতা বাড়িয়ে দেবে" ap
  • "এই পদ্ধতিগুলিকে একসাথে ক্লাসে টানলে তা পরীক্ষামূলক হয়ে উঠবে কারণ আমাদের আরও জটিল ক্লায়েন্ট শ্রেণীর সাথে কাজ করতে হবে না।"
  • "আমরা এখন সেই রিফ্যাক্টর পদ্ধতিগুলি ইউনিট পরীক্ষা করতে পারি As যেমনটি হ'ল x, y, z কারণে ক্লায়েন্ট পরীক্ষাযোগ্য নয়।

  • উপরোক্ত যুক্তিগুলির যে কোনও পরিমাণে সামগ্রিকভাবে তৈরি করা যেতে পারে:

    • কার্যকারিতা পুনরায় ব্যবহারযোগ্য হয়ে যায়।
    • এটা DRY
    • এটি ক্লায়েন্টদের দ্বারা decoupled।
    • ক্লাসের বিরুদ্ধে কোডিং দ্রুত এবং কম ত্রুটির প্রবণ।
  • "একটি ভাল কাজ সম্পন্ন শ্রেণি রাষ্ট্রকে লুকিয়ে রাখে এবং কার্যকারিতা প্রকাশ করে O এটি ক্লাস ডিজাইনের জন্য প্রারম্ভিক প্রস্তাব" "
  • "চূড়ান্ত ফলাফলটি ব্যবসায়ের ডোমেন প্রকাশের চেয়ে আরও ভাল কাজ করে; স্বতন্ত্র সত্তা এবং তাদের সুস্পষ্ট মিথস্ক্রিয়া।"
  • "এই 'ওভারহেড' কার্যকারিতা (যেমন সুস্পষ্ট কার্যকরী প্রয়োজনীয়তা নয়, তবে এটি করা দরকার) পরিষ্কারভাবে দাঁড়ায় এবং একক দায়িত্বের নীতিটি মেনে চলে।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.