বড় ইন্টারফেস বিভক্ত করুন

Question

আমি একটি ডাটাবেস অ্যাক্সেস করতে প্রায় 50 টি পদ্ধতি সহ একটি বৃহত ইন্টারফেস ব্যবহার করছি। ইন্টারফেসটি আমার এক সহকর্মী লিখেছেন। আমরা এটি নিয়ে আলোচনা করেছি:

আমি: 50 টি পদ্ধতি অনেক বেশি। এটি একটি কোড গন্ধ।
কলেজ: এ নিয়ে আমি কী করব? আপনি ডিবি অ্যাক্সেস চান - এটি আপনার কাছে রয়েছে।
আমি: হ্যাঁ, তবে এটি অস্পষ্ট এবং ভবিষ্যতে খুব কমই রক্ষণাবেক্ষণযোগ্য।
কলেজ: ঠিক আছে, আপনি ঠিক বলেছেন, ভালো লাগেনি। ইন্টারফেসটি দেখতে কেমন হবে?
আমি: কীভাবে 5 টি পদ্ধতি যা 10 টি পদ্ধতিতে অবজেক্টগুলিকে ফেরত দেয়?

মমমহ, তবে কি এই রকম হবে না? এটি কি আরও স্পষ্টতার দিকে নিয়ে যায়? এটি কি মূল্যবান?

প্রতিবার এবং পরে আমি এমন একটি পরিস্থিতিতে আছি যেখানে আমি একটি ইন্টারফেস চাই এবং প্রথম জিনিসটি যা মনে মনে আসে তা হ'ল একটি, বড় ইন্টারফেস। এর জন্য কি সাধারণ নকশার প্যাটার্ন রয়েছে?

---

আপডেট (এস জুয়ানের মন্তব্যের প্রতিক্রিয়া):

"ধরণের পদ্ধতি": এটি একটি ডাটাবেস থেকে ডেটা আনার জন্য একটি ইন্টারফেস। সমস্ত পদ্ধতির ফর্ম রয়েছে (সিউডোকোড)

List<Typename> createTablenameList()

পদ্ধতিগুলি এবং টেবিলগুলি 1-1-সম্পর্কের সাথে হুবহু নয়, আপনি সর্বদা কোনও ধরণের তালিকা পান যা একটি ডাটাবেস থেকে আসে তা জোর দেওয়া।

Comments

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

— এসজুয়ান Jun76

প্রকৃতপক্ষে কিছু টেবিল শব্দার্থগতভাবে "চক্র" গঠন করে অন্য টেবিলগুলির নিকটে রয়েছে। সুতরাং পদ্ধতিগুলি।

— টবিএমসিএনএমবি

কোডটি দেখা কি সম্ভব? আমি জানি এটি 4 বছর বয়সী এবং আপনি সম্ভবত এটি এখনই ঠিক করে দিয়েছেন: ডি তবে আমি এই সমস্যাটি সম্পর্কে ভাবতে চাই। আমি এর আগে এরকম কিছু সমাধান করেছি।

— clankill3r

@ clankill3r প্রকৃতপক্ষে নির্দিষ্ট ইন্টারফেসে আমার আর কোনও অ্যাক্সেস নেই যা আমাকে উপরের প্রশ্নটি পোস্ট করেছে। সমস্যা যদিও আরও সাধারণ। প্রায় 50 টি List<WeatherDataRecord> createWeatherDataTable() {db.open(); return db.select("*", "tbl_weatherData");}

— টেবিলযুক্ত

Answer 1

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

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

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

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

Comments

এই এবং utnapistim এর উত্তর সত্যিই দুর্দান্ত।

— টবিএমসিমনোবি

Answer 2

কলেজ: ঠিক আছে, আপনি ঠিক বলেছেন, ভালো লাগেনি। ইন্টারফেসটি দেখতে কেমন হবে?

আমি: কীভাবে 5 টি পদ্ধতি যা 10 টি পদ্ধতিতে অবজেক্টগুলিকে ফেরত দেয়?

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

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

মমমহ, তবে কি এই রকম হবে না? এটি কি আরও স্পষ্টতার দিকে নিয়ে যায়? এটি কি মূল্যবান?

আপনি যদি সঠিক মানদণ্ডটি চয়ন করেন তবে অবশ্যই। আপনি না, অবশ্যই না :)।

কয়েকটি উদাহরণ:

• ওও আদিমগণের সরল উদাহরণের জন্য ADODB অবজেক্টগুলিকে দেখুন (আপনার ডিবি এপিআই সম্ভবত ইতিমধ্যে এটি সরবরাহ করে)

• উচ্চ স্তরের বিমূর্ততা সহ ডেটা মডেল আইডিয়াটির জন্য জ্যাঙ্গো ডেটা মডেল ( https://docs.djangoproject.com/en/dev/topics/db/models/ ) দেখুন (সি ++ এ আপনার সম্ভবত আরও কিছুটা বয়লার প্লেট লাগবে কোড, তবে এটি একটি দুর্দান্ত ধারণা)। এই বাস্তবায়ন এমভিসি ডিজাইন প্যাটার্নের মধ্যে মাথায় রেখে "মডেল" ভূমিকা নিয়ে ডিজাইন করা হয়েছে।

• কেবল কার্যক্ষম আদিম (সি এপিআই) সমন্বিত একটি ফ্ল্যাট এপিআই আইডিয়া ( http://www.sqlite.org/c3ref/funclist.html ) এর জন্য স্ক্লাইট এপিআই দেখুন ।

Answer 3

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

এটি একক নকশার অ্যান্টি-প্যাটার্ন যার নাম মনোলিথিক ক্লাস । ক্লাসে বা ইন্টারফেসে 50 টি পদ্ধতি থাকা এসআরপির সম্ভাব্য লঙ্ঘন । একচেটিয়া শ্রেণিটি আসে কারণ এটি সবার কাছে সবকিছু হওয়ার চেষ্টা করে।

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

কীভাবে 5 টি পদ্ধতি যা প্রতি 10 টি পদ্ধতিতে অবজেক্টগুলিকে ফেরত দেয়?

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

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

সম্পাদনা: এ সম্পর্কে আমার চিন্তাভাবনা কিছুটা বদলে গেছে। আমি একটি বিকল্প উত্তর প্রদান।

Answer 4

আমার কাছে মনে হচ্ছে অন্য প্রতিটি উত্তরের বিন্দুটি অনুপস্থিত। মুল বক্তব্যটি হ'ল একটি ইন্টারফেসের উচিত আচরণের একটি পারমাণবিক অংশকে আদর্শভাবে সংজ্ঞায়িত করা উচিত। যে কঠিন আমি নেই।

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

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

তবে এটি টেস্টিংয়ের ক্ষেত্রে, সাধারণ অনুশীলনটি হ'ল একটি ক্লাসে কেবল একটি ইন্টারফেসকে থাপ্পড় দেওয়া যা সম্পূর্ণ শ্রেণীর ইন্টারফেসের 1-থেকে-1 প্রতিলিপি। যদি পরীক্ষার জন্য আপনার যত্ন নেওয়া হয় তবে এটি একটি বৈধ পদ্ধতির হতে পারে। এটি আপনাকে মোটামুটি দ্রুত ডামি তৈরি করতে দেয়। তবে এটি নিঃসন্দেহে নিখুঁত এবং নিবেদিত উদ্দেশ্যে ইন্টারফেসের সত্যিই অপব্যবহার।

হ্যাঁ, 50 টি পদ্ধতি গন্ধযুক্ত তবে এটি খারাপ কিনা তা উদ্দেশ্য এবং উদ্দেশ্যটির উপর নির্ভর করে। এটি অবশ্যই আদর্শ নয়।

Answer 5

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

Comments

পদ্ধতি বা বৈশিষ্ট্য?

— জেফো

Answer 6

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

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

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

বস্তু এবং পদ্ধতির দিক দিয়ে চিন্তা করার পরিবর্তে বিমূর্ততা এবং চুক্তির ক্ষেত্রে চিন্তাভাবনা শুরু করুন এবং কোনও প্রসঙ্গে কোন বিষয় কী ভূমিকা পালন করে তা বিবেচনা করুন।