আমি কি এই স্থাপত্যের সাহায্যে ওওপি অনুশীলনটি ভাঙ্গছি?


23

আমার একটি ওয়েব অ্যাপ্লিকেশন রয়েছে। প্রযুক্তিটি গুরুত্বপূর্ণ বলে আমি বিশ্বাস করি না। কাঠামোটি একটি এন-টিয়ার অ্যাপ্লিকেশন, বাম দিকে চিত্রটিতে প্রদর্শিত হয়েছে। 3 স্তর আছে।

ইউআই (এমভিসি প্যাটার্ন), বিজনেস লজিক লেয়ার (বিএলএল) এবং ডেটা অ্যাক্সেস লেয়ার (ডাল)

আমার বিএলএল সমস্যাটি হ'ল বিশাল কারণ এতে অ্যাপ্লিকেশন ইভেন্টগুলির কলের মাধ্যমে যুক্তি এবং পথ রয়েছে।

অ্যাপ্লিকেশন মাধ্যমে একটি সাধারণ প্রবাহ হতে পারে:

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

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

এখানে চিত্র বর্ণনা লিখুন

ডান সংস্করণ আমার প্রচেষ্টা।

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

প্রবাহটি হতে পারে:

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

ভাগ করা যুক্তি এবং ইন্টারফেসগুলি যেখানে আমাদের অবিরাম ডেটা থাকতে পারে, যেমন ম্যাক্সনম্বারঅফ_ এক্স এবং টোটালএলওয়েড_ এক্স এবং সমস্ত ইন্টারফেস।

ভাগ করা যুক্তি / ইন্টারফেস এবং ডাল উভয়ই আর্কিটেকচারের "বেস"। এগুলি বাইরের পৃথিবী সম্পর্কে কিছুই জানে না।

ভাগ করা যুক্তি / ইন্টারফেস এবং ডএএল ব্যতীত পোকো সম্পর্কে সমস্ত কিছু জানে।

প্রবাহটি এখনও প্রথম উদাহরণের সাথে খুব সমান, তবে এটি প্রতিটি স্তরের 1 টি জিনিসের জন্য আরও বেশি দায়বদ্ধ করেছে (এটি রাষ্ট্র, প্রবাহ বা অন্য যে কোনও কিছু হোক) ... তবে আমি কি এই পদ্ধতির সাথে ওওপি ভেঙে দিচ্ছি?

লজিক এবং পোকো ডেমো উদাহরণস্বরূপ হতে পারে:

public class LogicClass
{
    private ICommandQueryObject cmdQuery;
    public PocoA Method1(PocoB pocoB) 
    { 
        return cmdQuery.Save(pocoB); 
    }

    /*This has no state objects, only ways to communicate with other 
    layers such as the cmdQuery. Everything else is just function 
    calls to allow flow via the program */
    public PocoA Method2(PocoB pocoB) 
    {         
        pocoB.UpdateState("world"); 
        return Method1(pocoB);
    }

}

public struct PocoX
{
     public string DataA {get;set;}
     public int DataB {get;set;}
     public int DataC {get;set;}

    /*This simply returns something that is part of this class. 
     Everything is self-contained to this class. It doesn't call 
     trying to directly communicate with databases etc*/
     public int GetValue()
     {

         return DataB * DataC; 
     }

     /*This simply sets something that is part of this class. 
     Everything is self-contained to this class. 
     It doesn't call trying to directly communicate with databases etc*/
     public void UpdateState(string input)
     {        
         DataA += input;  
     }
}

আপনি বর্তমানে এটি বর্ণনা করার সাথে সাথে আপনার আর্কিটেকচারের সাথে মৌলিকভাবে কোনও ভুল দেখতে পাচ্ছি না।
রবার্ট হার্ভে

19
আপনার পরবর্তী উদাহরণ অন্তর্ভুক্ত করার জন্য পর্যাপ্ত কার্যকরী বিশদ নেই। ফুবার উদাহরণগুলি খুব কমই যথেষ্ট চিত্র সরবরাহ করে।
রবার্ট হার্ভে

1
আপনার বিবেচনার জন্য জমা দেওয়া: বারুকো 2012: ফ্রেমওয়ার্কটি
ডিক্রাস্ট্রাকিং

4
আমরা এই প্রশ্নের জন্য একটি ভাল শিরোনাম খুঁজে পাওয়া যাচ্ছে না তাই এটি করতে অনলাইন আরও সহজে পাওয়া যাবে?
সোনার গনুল

1
কেবল পেডেন্টিক হতে: একটি স্তর এবং স্তর একই জিনিস নয়। একটি "স্তর" যুক্তি সম্পর্কে কথা বলে, যুক্তি সম্পর্কে একটি "স্তর"। আপনার ডেটা স্তর সার্ভার-সাইড-কোড- এবং ডাটাবেস-স্তর উভয়কে মোতায়েন করা হবে। আপনার ইউআই স্তরটি উভয় ওয়েব-ক্লায়েন্ট- এবং সার্ভার-সাইড-কোড-স্তরগুলিতে স্থাপন করা হবে। আপনার প্রদর্শিত আর্কিটেকচারটি একটি 3-স্তরের আর্কিটেকচার। আপনার স্তরগুলি হ'ল "ওয়েব ক্লায়েন্ট", "সার্ভারের সাইড কোড" এবং "ডেটাবেস"।
লরেন্ট এলএ রিজ্জা

উত্তর:


54

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

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

অবশ্যই সর্বদা ব্যতিক্রম রয়েছে, তবে এই নকশাটি এই জিনিসগুলিকে একটি নিয়ম হিসাবে লঙ্ঘন করে।

আবার, আমি চাপ দিতে চাই "OOP লঙ্ঘন"! = "ভুল", সুতরাং এটি অগত্যা একটি মূল্য রায় নয়। এটি সমস্ত আপনার আর্কিটেকচার সীমাবদ্ধতা, রক্ষণাবেক্ষণের ব্যবহারের ক্ষেত্রে, প্রয়োজনীয়তা ইত্যাদির উপর নির্ভর করে


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

2
@ দ্য গেটস হুইসার: আধুনিক এন্টারপ্রাইজ আর্কিটেকচারগুলি ওওপি পুরোপুরি ফেলে দেয় না, কেবল বেছে বেছে (যেমন ডিটিও'র জন্য)।
রবার্ট হার্ভে

@ রবার্টহারভে সম্মত হয়েছে, আমি বোঝাতে চাইছি যদি আপনি নিজের নকশার জায়গায় কোথাও
ওওপি

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

@ অরেঞ্জস্যান্ডলেমোনস আমি নিশ্চিত যে এখানে প্রচুর পরিমাণে আরও ভাল সমর্থিত ভাষা রয়েছে ...
থেটিক্সহিস্পেরার

31

ফাংশনাল প্রোগ্রামিং এর অন্যতম মূল নীতি হ'ল খাঁটি ফাংশন।

অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের অন্যতম মূল নীতি হল তারা কাজ করা ডেটার সাথে ফাংশনগুলি একত্রিত করে।

আপনার অ্যাপ্লিকেশনটি যখন বাইরের বিশ্বের সাথে যোগাযোগ করতে হয় তখন এই দুটি মূল নীতিই হ্রাস পায়। প্রকৃতপক্ষে আপনি কেবলমাত্র আপনার সিস্টেমে বিশেষভাবে প্রস্তুত স্থানে এই আদর্শগুলির প্রতি সত্য হতে পারেন। আপনার কোডের প্রতিটি লাইন অবশ্যই এই আদর্শগুলির সাথে মেলে না। তবে যদি আপনার কোডের কোনও লাইন এই আদর্শগুলির সাথে মেলে না তবে আপনি সত্যই OOP বা FP ব্যবহার করার দাবি করতে পারবেন না।

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

আপনি যে এটি করতে হবে না। ওওপি সব লোকের কাছে সব কিছু নয়। এটা কি হয়। কখনই ওওপি অনুসরণ করে এমন কিছু দাবি করবেন না যখন তা হয় না বা আপনি আপনার কোড বজায় রাখার চেষ্টা করছেন এমন লোকদের বিভ্রান্ত করতে চলেছেন।

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

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

আমি গেটার বা সেটটার সরবরাহ করি না। আমি বলুন অনুসরণ করুন , জিজ্ঞাসা করবেন না । আপনি আমার পদ্ধতিগুলি কল করুন এবং তারা যা করতে হবে তা করে। তারা সম্ভবত তারা কী করেছে তা আপনাকে জানায় না। তারা কেবল এটি করে।

এখন অবশেষে কিছু, কোথাও অন্য সীমানায় চলে যেতে চলেছে এবং এই সব আবার বিচ্ছিন্ন হয়ে পড়ে। সেটা ঠিক আছে. অন্য একটি ডিটিও স্পিন করুন এবং প্রাচীরের উপরে টস করুন।

এটি বন্দর এবং অ্যাডাপ্টার আর্কিটেকচার সম্পর্কে যা আছে তার সারাংশ। আমি এটি সম্পর্কে কার্যকরী দৃষ্টিকোণ থেকে পড়ছি । সম্ভবত এটি আপনারও আগ্রহী হবে।


5
" getters এবং setters প্রকৃত encapsulation সরবরাহ করে না " - হ্যাঁ!
বোরিস স্পাইডার

3
@ বোরিস্টস্পাইডার - গিটারস এবং সেটটারগুলি একেবারে এনক্যাপসুলেশন সরবরাহ করে, তারা কেবল আপনার এনক্যাপসুলেশনের সংকীর্ণ সংজ্ঞা ফিট করে না।
loদ্রো

4
@ ড্যাভেরুড্রালো: এগুলি মাঝে মাঝে কাজের মতো হিসাবে কার্যকর, তবে তাদের প্রকৃতির দ্বারা, গেটরস এবং সিটারগুলি এনক্যাপসুলেশনটি ভেঙে দেয়। কিছু অভ্যন্তরীণ ভেরিয়েবল পাওয়ার ও সেট করার একটি উপায় প্রদান করা আপনার নিজের রাষ্ট্রের জন্য দায়বদ্ধ হওয়ার এবং এটিতে অভিনয়ের বিপরীত।
সিএওও

5
@ সিএইচও - প্রাপ্তি কী তা আপনি বুঝতে পারেন না। এর অর্থ এমন কোনও পদ্ধতি নয় যা কোনও বস্তুর সম্পত্তির মান প্রদান করে। এটি একটি সাধারণ বাস্তবায়ন, তবে এটি একটি ডাটাবেস থেকে কোনও মান ফেরত দিতে পারে, HTTP- র মাধ্যমে এটির জন্য অনুরোধ করতে পারে, এটি ফ্লাইতে গণনা করুন, যাই হোক না কেন। যেমনটি আমি বলেছিলাম, গেটার্স এবং সেটাররা তখনই এনক্যাপসুলেশনটি ভেঙে দেয় যখন লোকেরা তাদের নিজস্ব সংকীর্ণ (এবং ভুল) সংজ্ঞা ব্যবহার করে।
avorড্রালো

4
@ সিএইচও - এনক্যাপসুলেশন মানে আপনি বাস্তবায়ন গোপন করছেন। এটিই এনক্যাপসুলেটেড হয়ে যায়। আপনার যদি স্কোয়ার শ্রেণিতে "getSurfaceArea ()" জেটর থাকে, আপনি জানেন না যে পৃষ্ঠের ক্ষেত্র ক্ষেত্র ক্ষেত্র কিনা, যদি এটি উড়ে (ফেরতের উচ্চতা * প্রস্থ) বা কোনও তৃতীয় পদ্ধতিতে গণনা করা হয়, তবে আপনি অভ্যন্তরীণ বাস্তবায়ন পরিবর্তন করতে পারবেন আপনি যে কোনও সময় পছন্দ করেন, কারণ এটি আবদ্ধ ulated
21

1

আমি যদি আপনার ব্যাখ্যাটি সঠিকভাবে পড়ি তবে আপনার অবজেক্টগুলি দেখতে কিছুটা এ জাতীয় দেখাচ্ছে: (প্রসঙ্গ ছাড়াই ছদ্মবেশী)

public class LogicClass
{
    private ICommandQueryObject cmdQuery;
    public PocoA Method(PocoB pocoB) { ... }
}

public class PocoX
{
     public string DataA {get;set;}
     public int DataB {get;set;}
     ... etc
}

এতে আপনার পোকো ক্লাসগুলিতে কেবলমাত্র ডেটা থাকে এবং আপনার লজিক ক্লাসগুলিতে সেই ডেটাগুলিতে কাজ করে এমন পদ্ধতিগুলি থাকে; হ্যাঁ, আপনি "ক্লাসিক ওওপি" এর নীতিগুলি ভঙ্গ করেছেন

আবার, আপনার সাধারণ বিবরণটি থেকে বলা শক্ত, তবে আমি ঝুঁকিপূর্ণ যে আপনি যা লিখেছেন তা অ্যানেমিক ডোমেন মডেল হিসাবে শ্রেণিবদ্ধ করা যেতে পারে।

আমি মনে করি না এটি একটি বিশেষভাবে খারাপ দৃষ্টিভঙ্গি, এবং আপনি যদি আপনার পোকোকে স্ট্রাক্ট হিসাবে বিবেচনা করেন তবে এটি আরও সুনির্দিষ্ট অর্থে ওওপি কে আক্ষেপ করে break এতে আপনার অবজেক্টস এখন লজিক ক্লাস। প্রকৃতপক্ষে আপনি যদি আপনার পোকোসকে পরিবর্তনযোগ্য করে তোলেন তবে নকশাটিকে বেশ কার্যকর হিসাবে বিবেচনা করা যেতে পারে।

যাইহোক, যখন আপনি ভাগযুক্ত যুক্তি উল্লেখ করেন, পোকস যা প্রায় তবে একই হয় না এবং স্ট্যাটিকগুলি আমি আপনার নকশার বিশদটি সম্পর্কে উদ্বিগ্ন হতে শুরু করি।


আমি আমার পোস্টে যুক্ত করেছি, মূলত আপনার উদাহরণটি অনুলিপি করছি। দুঃখিত টি সাথে শুরু করতে পরিষ্কার ছিল না
MyDaftQuestions

1
আমার অর্থ হ'ল, যদি আপনি আমাদের বলেন অ্যাপ্লিকেশনটি কী করে তবে উদাহরণ লিখতে আরও সহজ হবে। লজিকক্লাসের পরিবর্তে আপনার পেমেন্টপ্রোভাইডার বা যা কিছু থাকতে পারে
ইওয়ান

1

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

অ্যাক্সেস / আপডেট কোডটি সাধারণত সংগ্রহ করা হয় না যাতে আপনি সর্বত্র সদৃশ কার্যকারিতাটি শেষ করেন।

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

"আসল" অবজেক্টগুলিতে এবং এর বাইরে মানগুলি অনুলিপি করা এবং আপনার ডেটা অবজেক্টটি ফেলে দেওয়া ক্লান্তিকর (তবে আপনি যদি সেই পথে যেতে চান তবে একটি বৈধ সমাধান হতে পারে)।

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

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

অন্য সুবিধাটি হ'ল আপনি নিশ্চিত করতে পারেন যে আপনার ডেটা শ্রেণি সর্বদা বৈধ অবস্থায় রয়েছে। এখানে একটি দ্রুত psuedocode উদাহরণ:

// Data Class
Class User {
    String name;
    Date birthday;
}

Class UserHolder {
    final private User myUser // Cannot be null or invalid

    // Quickly wrap an object after getting it from the DB
    public UserHolder(User me)
    {
        if(me == null ||me.name == null || me.age < 0)
            throw Exception
        myUser=me
    }

    // Create a new instance in code
    public UserHolder(String name, Date birthday) {
        User me=new User()
        me.name=name
        me.birthday=birthday        
        this(me)
    }
    // Methods access attributes, they try not to return them directly.
    public boolean canDrink(State state) {
        return myUser.birthday.year < Date.yearsAgo(state.drinkingAge) 
    }
}

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

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

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


1

কখনই আপনার কোড পরিবর্তন করবেন না কারণ আপনি ভাবেন বা কেউ আপনাকে বলে যে এটি এটি না এটি নয়। আপনার কোডটি পরিবর্তন করুন যদি এটি আপনাকে সমস্যা দেয় এবং আপনি অন্যকে তৈরি না করেই এই সমস্যাগুলি এড়ানোর কোনও উপায় খুঁজে বের করেন।

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


0

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

এটি আপনার উদাহরণ হিসাবে বলেছিল:

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

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

এখানে কিছু অত্যন্ত গুরুত্বপূর্ণ বেস অনুমান আছে:

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

গুরুত্বপূর্ণ: ইউআইটি এমভিসির একটি অংশ । অন্য পথে নয় (যেমন আপনার চিত্রের মতো)। যদি আপনি এটি আলিঙ্গন করেন তবে ফ্যাট মডেলগুলি আসলে বেশ ভাল - তবে শর্ত থাকে যে তাদের সত্যিকারের জিনিসগুলি না রাখাই উচিত।

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

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.