পদ্ধতিতে শৃঙ্খলা - কেন এটি একটি ভাল অনুশীলন, বা না?

151

মেথড শেইনিং হ'ল অবজেক্ট পদ্ধতির অনুশীলন যা অন্য কোনও পদ্ধতির জন্য ফলাফল আহ্বানের জন্য যাতে বস্তুটি নিজেই ফিরে আসে। এটার মত:

participant.addSchedule(events[1]).addSchedule(events[2]).setStatus('attending').save()

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

participant.getSchedule('monday').saveTo('monnday.file')

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

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

participant.attend(event).setNotifications('silent').getSocialStream('twitter').postStatus('Joining '+event.name).follow(event.getSocialId('twitter'))

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

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

সিডিনোট: আমি বুঝতে পারি এই প্রশ্নটি একটি প্রশ্ন হিসাবে মুখোশযুক্ত মতামতের বিবৃতি হিসাবে পড়া যেতে পারে। এটি তবে তা নয় - শৃঙ্খলাভাবকে কেন ভাল অনুশীলন হিসাবে বিবেচনা করা হয় তা আমি সত্যই বুঝতে চাই এবং এটি অন্তর্নিহিত বস্তু-ভিত্তিক স্বরলিপিটি ভেঙে ভাবার ক্ষেত্রে আমি কোথায় ভুল করব।

oop  fluent-interface  method-chaining 
— ইলারি কাজস্তে
সূত্র
মনে হচ্ছে যে পদ্ধতিটিতে শৃঙ্খলাবদ্ধতা জাভাতে স্মার্ট কোড লেখার কমপক্ষে একটি উপায়। এমনকি যদি প্রত্যেকে একমত না হয় ..
— মারসার ট্রিয়েস্ট
তারা এই "সাবলীল" পদ্ধতি বা একটি "সাবলীল" ইন্টারফেসও বলে। আপনি এই পদটি ব্যবহার করতে আপনার শিরোনাম আপডেট করতে চাইতে পারেন।
— এস। লট
4
অন্য একটি আলোচনায় এটি বলা হয়েছিল যে সাবলীল ইন্টারফেসটি একটি বৃহত্তর ধারণা যা কোডের পাঠযোগ্যতার সাথে করতে হয় এবং পদ্ধতি শৃঙ্খলা কেবল এই দিকে লক্ষ্য করার একটাই উপায়। এগুলি নিবিড়ভাবে সম্পর্কিত, সুতরাং, আমি ট্যাগটি যুক্ত করেছি এবং পাঠ্যে প্রবাহিত সাফ ইন্টারফেসগুলি যুক্ত করেছি - আমি মনে করি এগুলি যথেষ্ট।
— ইলারি কাজস্তে
14
আমি যেভাবে এটি ভাবতে এসেছি, তা হল যে পদ্ধতিটির শৃঙ্খলাটি আসলে, ভাষার বাক্য গঠনের জন্য একটি অনুপস্থিত বৈশিষ্ট্য পেতে হ্যাকারআউন্ড হয়। এটি কোনও প্রয়োজনই ছিল না যদি কোনও অভ্যন্তরীণ বিকল্প স্বরলিপি থাকে .যা কোনও মেহতড ফেরতের মানগুলিকে উপেক্ষা করে এবং সর্বদা একই অবজেক্টটি ব্যবহার করে কোনও শৃঙ্খলিত পদ্ধতিতে প্রার্থনা করে।
— ইলারি কাজস্তে
এটি দুর্দান্ত কোডিং আইডিয়াম, তবে দুর্দান্ত সরঞ্জামগুলির মতো এটিরও অপব্যবহার হয়।
— মার্টিন স্প্যামার

উত্তর:

74

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

MyObject.Start()
    .SpecifySomeParameter(asdasd)
    .SpecifySomeOtherParameter(asdasd)
    .Execute();

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

মুল বক্তব্যটি হল - 99% ক্ষেত্রে আপনি সম্ভবত পদ্ধতি বাজানো ছাড়াই আরও ভাল বা আরও ভাল করতে পারেন। তবে 1% আছে যেখানে এটি সর্বোত্তম পন্থা।

— Vilx-
সূত্র
4
আইএমও, এই দৃশ্যে পদ্ধতিতে শৃঙ্খলা ব্যবহারের সর্বোত্তম উপায় হ'ল ফাংশনে যাওয়ার মতো একটি প্যারামিটার অবজেক্ট তৈরি করা P = MyObject.GetParamsObj().SomeParameter(asdasd).SomeOtherParameter(asdasd); Obj = MyObject.Start(); MyObject.Execute(P);। অন্যান্য কলগুলিতে এই পরামিতি অবজেক্টটি পুনরায় ব্যবহার করতে সক্ষম হওয়ার সুবিধা আপনার রয়েছে, যা একটি প্লাস!
— পেড্রোমোনেল
20
নিদর্শনগুলি সম্পর্কে আমার অবদানের মাত্র শতাংশ, কারখানা পদ্ধতিতে সাধারণত কেবল একটি সৃষ্টি পয়েন্ট থাকে এবং পণ্যগুলি কারখানার পদ্ধতির পরামিতিগুলির উপর ভিত্তি করে স্থিতিকর পছন্দ হয়। চেইন সৃষ্টি কোনও বিল্ডার প্যাটার্নকে আরও বেশি দেখায় যেখানে আপনি ফলাফল অর্জনের জন্য বিভিন্ন পদ্ধতি কল করেন, পদ্ধতিগুলি চেইনের মতো পদ্ধতিগুলি optionচ্ছিক হতে পারে , আমাদের এখানেPizzaBuilder.AddSauce().AddDough().AddTopping() আরও উল্লেখের মতো কিছু থাকতে পারে
— মার্কো মেড্রানো
3
পদ্ধতি শৃঙ্খলাবদ্ধকরণ (মূল প্রশ্নে ডাকা হিসাবে) এটি ডেমিটারের আইন লঙ্ঘন করলে খারাপ বলে বিবেচিত হয় । দেখুন: ifaceferencests.net/2006/03/07/… এখানে প্রদত্ত উত্তর আসলে আইনটিকে "বিল্ডার প্যাটার্ন" হিসাবে অনুসরণ করে।
— অ্যাঞ্জেল ও'স্পিয়ার
2
@ মারকো মাদারানো পিজ্জাবিল্ডার উদাহরণটি আমাকে সর্বদা জাগিয়ে তোলে যেহেতু আমি বহু বছর আগে জাভাওয়ার্ল্ডে পড়েছিলাম। আমার মনে হয় আমার রান্নায় আমার পিজ্জে সস যুক্ত করা উচিত।
— ব্র্যান্ডান ডালটন
1
আমি জানি তুমি কী বোঝাতে চেয়েছ, ভিলাক্স। কিন্তু এখনো যখন আমি পড়তে list.add(someItem), আমি পড়তে যে হিসাবে "এই কোড যুক্ত করা হয় someItemকরার listবস্তু"। সুতরাং যখন আমি পড়ি PizzaBuilder.AddSauce(), তখন আমি এটিকে স্বাভাবিকভাবে পড়ি "এই কোডটি PizzaBuilderবস্তুটিতে সস যুক্ত করছে "। অন্য কথায়, আমি অর্কেস্ট্রেটারকে (যিনি যুক্ত করছেন তিনি) সেই পদ্ধতি হিসাবে কোড list.add(someItem)বা PizzaBuilder.addSauce()এমবেড থাকা হিসাবে দেখি। তবে আমি কেবল মনে করি পিজ্জাবিল্ডারের উদাহরণটি কিছুটা কৃত্রিম। আপনার উদাহরণ MyObject.SpecifySomeParameter(asdasd)আমার জন্য ভাল কাজ করে।
— ব্র্যান্ডান ডালটন
78

শুধু আমার 2 সেন্ট;

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

আমি মনে করি সর্বদা খুব সংক্ষিপ্ত এবং সংক্ষিপ্ত রেখাগুলি লেখার পক্ষে এটি ভাল অভ্যাস। প্রতিটি লাইনে কেবল একটি পদ্ধতি কল করা উচিত। দীর্ঘ লাইনে আরও লাইন পছন্দ করুন fer

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

— রশ্মি
সূত্র
4
স্বতন্ত্র চেইনিং নিউলাইন এবং পদ্ধতি ব্যবহার না? আপনি @ ভিলাক্স-উত্তর অনুসারে একটি নতুন লাইনে প্রতিটি কলের সাথে চেইন করতে পারেন এবং আপনি সাধারণত একই লাইনে একাধিক পৃথক স্টেটমেন্ট রাখতে পারেন (যেমন জাভাতে অর্ধিকোলন ব্যবহার করে)।
— ব্র্যাবস্টার
2
এই উত্তরটি সম্পূর্ণরূপে ন্যায়সঙ্গত, তবে এটি কেবল আমার জানা সমস্ত ডিবাগারগুলিতে উপস্থিত একটি দুর্বলতা দেখায় এবং বিশেষত প্রশ্নের সাথে সম্পর্কিত নয়।
— মাস্টারেক্সিলো
1
@Brabster। তারা নির্দিষ্ট ডিবাগারদের জন্য পৃথক হতে পারে, তবে, মাঝারি ভেরিয়েবলগুলির সাথে পৃথক কল করার পরেও আপনি বাগগুলি অনুসন্ধান করার সময় আপনাকে আরও বৃহত্তর তথ্য সরবরাহ করতে পারে।
— RAY
4
+1, সময়ে কোনও বিন্দুতে আপনি কি জানেন না যে কোনও পদ্ধতি শৃঙ্খলা ধাপে-ডিবাগ করার সময় প্রতিটি পদ্ধতি কী ফিরে আসে। মেথড চেইন প্যাটার্ন হ্যাক। এটি একটি রক্ষণাবেক্ষণ প্রোগ্রামারের সবচেয়ে খারাপ দুঃস্বপ্ন।
— লি কোয়ালকভস্কি
1
আমি হয় শৃঙ্খলাকৃতির খুব বড় ভক্ত নই তবে কেন কেবল পদ্ধতি সংজ্ঞাগুলির মধ্যে ব্রেকআপপয়েন্ট রাখি না?
— পঙ্কজ শর্মা
39

ব্যক্তিগতভাবে, আমি শৃঙ্খলাবদ্ধ পদ্ধতিগুলি পছন্দ করি যা কেবলমাত্র মূল বস্তুতে কাজ করে, যেমন একাধিক বৈশিষ্ট্য নির্ধারণ করা বা ইউটিলিটি-ধরণের পদ্ধতিগুলি কল করা।

foo.setHeight(100).setWidth(50).setColor('#ffffff');
foo.moveTo(100,100).highlight();

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

বিভিন্ন বস্তুর শৃঙ্খলা অপ্রত্যাশিত নাল ত্রুটির দিকেও নিয়ে যেতে পারে। আমার উদাহরণগুলিতে, foo বৈধ বলে ধরে নেওয়া , সমস্ত পদ্ধতি কলগুলি "নিরাপদ" (যেমন, ফু এর জন্য কার্যকর)। ওপির উদাহরণে:

participant.getSchedule('monday').saveTo('monnday.file')

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

— ব্রায়ান মোসকাউ
সূত্র
যদি এমন Participantকোনও সম্ভাবনা থাকে যে কোনওটির বৈধ না থাকে Scheduleতবে getScheduleপদ্ধতিটি কোনও Maybe(of Schedule)প্রকারটি ফেরত দেওয়ার saveToজন্য তৈরি করা হয়েছে এবং কোনও Maybeপ্রকারটি গ্রহণ করার জন্য পদ্ধতিটি নকশা করা হয়েছে ।
— লাইটম্যান 13
24

মার্টিন ফওলারের এখানে ভাল আলোচনা হয়েছে:

পদ্ধতি চেইনিং

কখন এটি ব্যবহার করবেন

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

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

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

— ডার্ক ভোলমার
সূত্র
2
লিঙ্কটি মারা গেছে :(
— Qw3ry
ডিএসএল বলতে কী বোঝ? ডোমেন নির্দিষ্ট ভাষা
— সেরেন
@ সেরেন: ফওলার বলতে ডোমেন-নির্দিষ্ট ভাষাগুলি বোঝায়।
— ডার্ক ভোলমার
21

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

কিভাবে:

someList.addObject("str1").addObject("str2").addObject("str3")

এর থেকে আরও ভাল:

someList.addObject("str1")
someList.addObject("str2")
someList.addObject("str3")

ব্যতিক্রম হতে পারে যখন অ্যাডোবজেক্ট () কোনও নতুন অবজেক্ট ফেরত দেয়, সেক্ষেত্রে অপরিবর্তিত কোডটি আরও কিছুটা জটিল হতে পারে যেমন:

someList = someList.addObject("str1")
someList = someList.addObject("str2")
someList = someList.addObject("str3")
— টম ডালিং
সূত্র
9
এটি আরও সংক্ষিপ্ত, কারণ আপনি নিজের প্রথম উদাহরণে এমনকি 'কিছু তালিকা' দুটি অংশ এড়িয়ে যান এবং তিনটির পরিবর্তে একটি লাইন দিয়ে শেষ করেন। এখন যদি তা আসলে ভাল হয় বা খারাপ বিভিন্ন জিনিসের উপর নির্ভর করে এবং সম্ভবত এটি স্বাদের বিষয়।
— ফ্যাবিয়ান স্টেগ
26
কেবল একবার 'কিছু তালিকা' রাখার আসল সুবিধাটি হ'ল এটি দীর্ঘ, আরও বর্ণনামূলক নাম দেওয়া এত সহজ। যে কোনও সময় দ্রুত উত্তরাধিকারে একাধিকবার উপস্থিত হওয়ার দরকার পড়ে, এটি সংক্ষিপ্ত করার একটি প্রবণতা রয়েছে (পুনরাবৃত্তি হ্রাস করতে এবং পঠনযোগ্যতার উন্নতি করতে), যা এটি কম বর্ণনামূলক করে তোলে, পাঠযোগ্যতার ক্ষতি করে।
— ক্রিস ডড
পাঠযোগ্যতা এবং DRY নীতি সম্পর্কে ভাল বক্তব্য যে সতর্কতার সাথে পদ্ধতি-শৃঙ্খলা একটি প্রদত্ত পদ্ধতির প্রত্যাবর্তন মূল্যের অন্তর্মুখীতা রোধ করে এবং / অথবা শৃঙ্খলে প্রতিটি পদ্ধতি থেকে খালি তালিকা / সেট এবং অ-নাল মানগুলিকে অনুমান করে (একটি ভ্রান্তি সৃষ্টি করে) সিস্টেমে অনেকগুলি এনপিইগুলি আমাকে প্রায়শই ডিবাগ / ফিক্স করতে হয়)।
— ড্যারেল টিগু
@ ক্রিসডোড অটো সম্পন্ন হওয়ার কথা কখনও শুনেনি?
— inf3rno
1
"মানুষের মস্তিষ্কের পাঠ্য পুনরাবৃত্তি স্বীকৃতি দিতে খুব ভাল যদি এটির একই ইনডেন্টেশন থাকে" - এটি অবশ্যই পুনরাবৃত্তির ক্ষেত্রে সমস্যা: এটি মস্তিষ্ককে পুনরাবৃত্তি প্যাটার্নটিতে ফোকাস করার কারণ করে। সুতরাং আপনার কোডটি পড়ার জন্য এবং বোঝার জন্য আপনার মস্তিষ্ককে পুনরাবৃত্তি করার প্যাটার্নের পিছনে / পিছনে সন্ধান করতে বাধ্য করতে হবে যা সত্যই চলছে, যা আপনার মস্তিষ্কের চকচকে ঝুঁকির ঝুঁকির পুনরাবৃত্তি প্যাটার্নের মধ্যে রয়েছে। কোডটির পাঠযোগ্যতার জন্য এটি কেন পুনরাবৃত্তি এত খারাপ।
— ক্রিস ডড
7

এটি বিপজ্জনক কারণ আপনি প্রত্যাশার চেয়ে বেশি অবজেক্টের উপর নির্ভরশীল হতে পারেন, তারপরে আপনার কলটি অন্য শ্রেণির উদাহরণ দেয়:

আমি একটি উদাহরণ দেব:

ফুডস্টোর এমন একটি জিনিস যা আপনার নিজের মালিকানাধীন অনেকগুলি খাদ্য সামগ্রীর সমন্বয়ে গঠিত। Foodstore.getLocalStore () প্যারামিটারের নিকটতম স্টোরের তথ্য ধারণ করে এমন একটি বস্তু প্রদান করে। getPriceforPr Prodct (যে কোনও কিছু) হ'ল সেই বস্তুর একটি পদ্ধতি।

সুতরাং যখন আপনি ফুড স্টোর.গেটলোকল স্টোর (পরামিতি) কল করুন।

আপনি কেবল আপনার মতো খাবারের দোকানেই নয়, লোকালস্টোরের উপরও নির্ভর করছেন।

প্রাইসফোর্স প্রোডাক্ট (যে কোনও কিছু) কখনই পরিবর্তিত হওয়া উচিত, আপনাকে কেবল ফুডস্টোরই নয়, সেই ক্লাসও বদলাতে হবে যা শৃঙ্খলিত পদ্ধতি বলে।

আপনার সর্বদা ক্লাসের মধ্যে আলগা দম্পতির জন্য লক্ষ্য করা উচিত।

বলা হচ্ছে, রুবি প্রোগ্রামিং করার সময় আমি ব্যক্তিগতভাবে তাদের চেইন করতে পছন্দ করি।

— rprandi
সূত্র
7

অনেকে মনে করেন কোনও পাঠযোগ্যতার উদ্বেগ না রেখে সুবিধার ফর্ম হিসাবে শৃঙ্খলাবদ্ধ পদ্ধতি ব্যবহার করে। পদ্ধতিতে শৃঙ্খলা গ্রহণযোগ্য হয় যদি এতে একই বস্তুতে একই ক্রিয়া সম্পাদন করা জড়িত - তবে কেবলমাত্র এটি যদি পাঠযোগ্যতা বৃদ্ধি করে কেবলমাত্র কম কোড লেখার জন্য নয়।

দুর্ভাগ্যক্রমে অনেক প্রশ্নের পদ্ধতিতে উদাহরণ হিসাবে শৃঙ্খলাবদ্ধ ব্যবহার। যদিও তারা করতে এখনো পাঠযোগ্য তৈরি করা, তারা দুর্ভাগ্যবশত বহু শ্রেণীর মধ্যে উচ্চ কাপলিং ঘটাচ্ছে হয়, তাই এটি কাম্য নয়।

— aberrant80
সূত্র
6

এটি কিন্ডা বিষয়গত বলে মনে হচ্ছে।

পদ্ধতিতে শৃঙ্খলা অন্তরগতভাবে খারাপ বা ভাল ইমো এমন কিছু নয়।

পঠনযোগ্যতা সবচেয়ে গুরুত্বপূর্ণ জিনিস।

(আরও বিবেচনা করুন যে বিপুল সংখ্যক পদ্ধতিতে শৃঙ্খলাবদ্ধভাবে কিছু পরিবর্তন হলে জিনিসগুলি খুব ভঙ্গুর করে তুলবে)

— জন নিকোলাস
সূত্র
এটি প্রকৃতপক্ষে সাবজেক্টিভ হতে পারে, তাই সাবজেক্টিভ ট্যাগ। আমি আশা করি যে উত্তরগুলি আমার কাছে হাইলাইট করবে সে ক্ষেত্রে পদ্ধতি শৃঙ্খলাবদ্ধতা একটি ভাল ধারণা হবে - এখনই আমি খুব বেশি কিছু দেখতে পাচ্ছি না, তবে আমি মনে করি এটি ধারণার ভাল পয়েন্টগুলি বোঝার জন্য কেবল আমার ব্যর্থতা is শৃঙ্খলাবদ্ধতার মধ্যে অন্তর্নিহিত খারাপ কিছু।
— ইলারি কাজস্তে
উচ্চ সংশ্লেষের ফলে এটি কী সহজাতভাবে খারাপ হবে না? স্বতন্ত্র বিবৃতিতে শৃঙ্খলা ভঙ্গ করা পাঠযোগ্যতা হ্রাস করে না।
— aberrant80
1
আপনি কতটা কৌতূহলী হতে চান তার উপর নির্ভর করে। যদি এর ফলাফল আরও পাঠযোগ্য হয় তবে এটি অনেক পরিস্থিতিতে ভাল in এই পদ্ধতির সাথে আমার যে বড় সমস্যাটি হ'ল তা হ'ল কোনও বস্তুর বেশিরভাগ পদ্ধতিগুলি অবজেক্টের জন্যই রেফারেন্স ফিরিয়ে দেয় তবে প্রায়শই এই পদ্ধতিটি কোনও শিশু অবজেক্টের রেফারেন্স ফিরিয়ে দেয় যার উপর আপনি আরও পদ্ধতিগুলি শৃঙ্খলাবদ্ধ করতে পারেন। একবার আপনি এটি করা শুরু করলে অন্য কোডারের পক্ষে যা চলছে তা ছড়িয়ে ফেলা খুব কঠিন হয়ে পড়ে। এছাড়াও কোনও পদ্ধতির কার্যকারিতার কোনও পরিবর্তন কোনও বৃহত যৌগিক বিবৃতিতে ডিবাগ করার জন্য ব্যথা হতে চলেছে।
— জন নিকোলাস
6

চেইনিং এর সুবিধাগুলি
, যেখানে আমি এটি ব্যবহার করতে পছন্দ করি

শৃঙ্খলাবদ্ধ হওয়ার একটি সুবিধা যা আমি উল্লেখ করি না তা হ'ল পরিবর্তনশীল দীক্ষার সময় এটি ব্যবহার করার দক্ষতা বা কোনও পদ্ধতিতে কোনও নতুন অবজেক্ট পাস করার পরে নিশ্চিত না যে এটি খারাপ অভ্যাস কিনা তা নিশ্চিত নয়।

আমি জানি এটি নিখুঁত উদাহরণ তবে বলুন যে আপনার নিম্নলিখিত ক্লাস রয়েছে

Public Class Location
   Private _x As Integer = 15
   Private _y As Integer = 421513

   Public Function X() As Integer
      Return _x
   End Function
   Public Function X(ByVal value As Integer) As Location
      _x = value
      Return Me
   End Function

   Public Function Y() As Integer
      Return _y
   End Function
   Public Function Y(ByVal value As Integer) As Location
      _y = value
      Return Me
   End Function

   Public Overrides Function toString() As String
      Return String.Format("{0},{1}", _x, _y)
   End Function
End Class

Public Class HomeLocation
   Inherits Location

   Public Overrides Function toString() As String
      Return String.Format("Home Is at: {0},{1}", X(), Y())
   End Function
End Class

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

  Dim loc As New HomeLocation()
  loc.X(1337)
  PrintLocation(loc)

তবে এটি পড়া খুব সহজ নয়:

  PrintLocation(New HomeLocation().X(1337))

বা, একটি শ্রেণীর সদস্য সম্পর্কে কি?

Public Class Dummy
   Private _locA As New Location()
   Public Sub New()
      _locA.X(1337)
   End Sub
End Class

বনাম

Public Class Dummy
   Private _locC As Location = New Location().X(1337)
End Class

এইভাবে আমি শৃঙ্খলা ব্যবহার করেছি এবং সাধারণত আমার পদ্ধতিগুলি কেবল কনফিগারেশনের জন্য, সুতরাং সেগুলি কেবলমাত্র 2 লাইন দীর্ঘ, একটি মান নির্ধারণ করে Return Me। আমাদের জন্য এটি কোডকে এক লাইনে পড়তে এবং বুঝতে খুব শক্ত রেখা পরিষ্কার করেছে যা বাক্যটির মতো পড়ে। কিছুটা এইরকম

New Dealer.CarPicker().Subaru.WRX.SixSpeed.TurboCharged.BlueExterior.GrayInterior.Leather.HeatedSeats

বনাম কিছু

New Dealer.CarPicker(Dealer.CarPicker.Makes.Subaru
                   , Dealer.CarPicker.Models.WRX
                   , Dealer.CarPicker.Transmissions.SixSpeed
                   , Dealer.CarPicker.Engine.Options.TurboCharged
                   , Dealer.CarPicker.Exterior.Color.Blue
                   , Dealer.CarPicker.Interior.Color.Gray
                   , Dealer.CarPicker.Interior.Options.Leather
                   , Dealer.CarPicker.Interior.Seats.Heated)

চেইনির ক্ষতিকারক
অর্থ, যেখানে আমি এটি ব্যবহার করতে পছন্দ করি না

রুটিনগুলিতে যাওয়ার জন্য অনেকগুলি পরামিতি থাকাকালীন আমি শৃঙ্খলা ব্যবহার করি না, মূলত কারণ লাইনগুলি দীর্ঘ হয় এবং ওপি যেমন উল্লেখ করেছে এটি বিভ্রান্ত হয়ে উঠতে পারে যখন আপনি অন্য ক্লাসের রুটিনগুলিকে একটিতে পাস করার জন্য কল করছেন calling শৃঙ্খল পদ্ধতি।

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

উপসংহার

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

আমি এই নিয়মগুলি অনুসরণ করার চেষ্টা করি।

  1. ক্লাসের মধ্যে শৃঙ্খলা না করার চেষ্টা করুন
  2. শৃঙ্খলার জন্য বিশেষভাবে রুটিনগুলি তৈরি করুন
  3. শৃঙ্খলাবদ্ধ রুটিনে কেবল একটি কাজ করুন
  4. পাঠযোগ্যতার উন্নতি হলে এটি ব্যবহার করুন
  5. কোডটি সহজ করে দিলে এটি ব্যবহার করুন
— Apeiron
সূত্র
6

পদ্ধতি শৃঙ্খলা সরাসরি জাভাতে উন্নত ডিএসএল ডিজাইনের জন্য অনুমতি দিতে পারে । সংক্ষেপে, আপনি কমপক্ষে এই ধরণের ডিএসএল বিধিগুলি মডেল করতে পারেন:

1. SINGLE-WORD
2. PARAMETERISED-WORD parameter
3. WORD1 [ OPTIONAL-WORD]
4. WORD2 { WORD-CHOICE-A | WORD-CHOICE-B }
5. WORD3 [ , WORD3 ... ]

এই ইন্টারফেস ব্যবহার করে এই বিধিগুলি প্রয়োগ করা যেতে পারে

// Initial interface, entry point of the DSL
interface Start {
  End singleWord();
  End parameterisedWord(String parameter);
  Intermediate1 word1();
  Intermediate2 word2();
  Intermediate3 word3();
}

// Terminating interface, might also contain methods like execute();
interface End {}

// Intermediate DSL "step" extending the interface that is returned
// by optionalWord(), to make that method "optional"
interface Intermediate1 extends End {
  End optionalWord();
}

// Intermediate DSL "step" providing several choices (similar to Start)
interface Intermediate2 {
  End wordChoiceA();
  End wordChoiceB();
}

// Intermediate interface returning itself on word3(), in order to allow for
// repetitions. Repetitions can be ended any time because this interface
// extends End
interface Intermediate3 extends End {
  Intermediate3 word3();
}

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

create().select(
    r1.ROUTINE_NAME,
    r1.SPECIFIC_NAME,
    decode()
        .when(exists(create()
            .selectOne()
            .from(PARAMETERS)
            .where(PARAMETERS.SPECIFIC_SCHEMA.equal(r1.SPECIFIC_SCHEMA))
            .and(PARAMETERS.SPECIFIC_NAME.equal(r1.SPECIFIC_NAME))
            .and(upper(PARAMETERS.PARAMETER_MODE).notEqual("IN"))),
                val("void"))
        .otherwise(r1.DATA_TYPE).as("data_type"),
    r1.NUMERIC_PRECISION,
    r1.NUMERIC_SCALE,
    r1.TYPE_UDT_NAME,
    decode().when(
    exists(
        create().selectOne()
            .from(r2)
            .where(r2.ROUTINE_SCHEMA.equal(getSchemaName()))
            .and(r2.ROUTINE_NAME.equal(r1.ROUTINE_NAME))
            .and(r2.SPECIFIC_NAME.notEqual(r1.SPECIFIC_NAME))),
        create().select(count())
            .from(r2)
            .where(r2.ROUTINE_SCHEMA.equal(getSchemaName()))
            .and(r2.ROUTINE_NAME.equal(r1.ROUTINE_NAME))
            .and(r2.SPECIFIC_NAME.lessOrEqual(r1.SPECIFIC_NAME)).asField())
    .as("overload"))
.from(r1)
.where(r1.ROUTINE_SCHEMA.equal(getSchemaName()))
.orderBy(r1.ROUTINE_NAME.asc())
.fetch()

আর একটি দুর্দান্ত উদাহরণ হ'ল জেআরটিএফ , সরাসরি জাভাতে আরটিএফ ডকুমেন্টগুলি সরেটিংয়ের জন্য ডিজাইন করা একটি সামান্য ডিএসএল। একটি উদাহরণ:

rtf()
  .header(
    color( 0xff, 0, 0 ).at( 0 ),
    color( 0, 0xff, 0 ).at( 1 ),
    color( 0, 0, 0xff ).at( 2 ),
    font( "Calibri" ).at( 0 ) )
  .section(
        p( font( 1, "Second paragraph" ) ),
        p( color( 1, "green" ) )
  )
).out( out );
— লুকাস ইদার
সূত্র
@ ইউজার 737373৩৯৯: হ্যাঁ, এটি কোনওরকম অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং ল্যাঙ্গুয়েজে ব্যবহার করা যেতে পারে যা ইন্টারফেস এবং সাব টাইপ পলিমॉर्फিজমের মতো কিছু জানে
— লুকাশ এডার
4

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

$this->db->select('something')->from('table')->where('id', $id);

এটি দেখতে অনেক ক্লিনার (এবং আমার মতে আরও বেশি অর্থবোধ করে) দেখায়:

$this->db->select('something');
$this->db->from('table');
$this->db->where('id', $id);

এটি সত্যই বিষয়গত; সবাই তাদের নিজস্ব মতামত আছে।

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

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

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

যখন অন্যেরা বলছেন এটি পাঠযোগ্যতার ক্ষতি করে তখন আমি কী বলতে চাই তা সত্যই বুঝতে পারি না। এটি আমি যে প্রোগ্রামিং ব্যবহার করেছি তার মধ্যে সবচেয়ে সংক্ষিপ্ত এবং একাত্মক রূপ।

এটিও:

। ConvertTextToVoice.LoadText ( "source.txt") ConvertToVoice ( "destination.wav");

আমি সাধারণত এটি ব্যবহার করব কিভাবে। প্যারামিটারের x সংখ্যার শৃঙ্খলে এটি ব্যবহার করে আমি সাধারণত এটি কীভাবে ব্যবহার করি তা নয়। আমি যদি কোনও পদ্ধতি কলে x সংখ্যক পরামিতি স্থাপন করতে চাইতাম তবে আমি প্যারাম সিনট্যাক্সটি ব্যবহার করব :

পাবলিক অকার্যকর foo (প্যারাম অবজেক্ট [] আইটেম)

এবং প্রকারের ভিত্তিতে অবজেক্টগুলি কাস্ট করুন বা আপনার ব্যবহারের ক্ষেত্রে নির্ভর করে কেবল একটি ডেটাটাইপ অ্যারে বা সংগ্রহ ব্যবহার করুন।

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

আমি সম্মত, আমি তারপরে আমার লাইব্রেরিতে একটি সাবলীল ইন্টারফেস প্রয়োগ করার পদ্ধতিটি পরিবর্তন করেছি।

আগে:

collection.orderBy("column").limit(10);

পরে:

collection = collection.orderBy("column").limit(10);

"পূর্বে" বাস্তবায়নে ফাংশনগুলি বস্তুটিকে সংশোধন করে শেষ করে return this। আমি একই ধরণের একটি নতুন অবজেক্ট ফিরিয়ে আনতে বাস্তবায়ন পরিবর্তন করেছি ।

এই পরিবর্তনের জন্য আমার যুক্তি :

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

  2. সিস্টেম লাইব্রেরিগুলিতে শৃঙ্খলাবদ্ধ পদ্ধতিও সেভাবে প্রয়োগ করে (যেমন লিনক বা স্ট্রিং):

    myText = myText.trim().toUpperCase();

  3. আসল অবজেক্টটি অক্ষত থাকে, এপিআই ব্যবহারকারীকে এটি দিয়ে কী করা যায় তা সিদ্ধান্ত নিতে দেয়। এটি এর জন্য অনুমতি দেয়:

    page1 = collection.limit(10);
page2 = collection.offset(10).limit(10);

  4. একটি কপি বাস্তবায়ন বস্তুর নির্মাণের জন্য ব্যবহার করা যেতে পারে:

    painting = canvas.withBackground('white').withPenSize(10);

    যেখানে setBackground(color)ফাংশনটি উদাহরণ পরিবর্তন করে এবং কিছুই দেয় না (যেমনটি মনে করা হয়) ।

  5. ফাংশনগুলির আচরণ আরও অনুমানযোগ্য (পয়েন্ট 1 এবং 2 দেখুন)।

  6. একটি সংক্ষিপ্ত পরিবর্তনশীল নাম ব্যবহার করে মডেলটিতে কোনও এপিআই চাপ না দিয়ে কোড-ক্লাটারকে হ্রাস করতে পারে।

    var p = participant; // create a reference
p.addSchedule(events[1]);p.addSchedule(events[2]);p.setStatus('attending');p.save()

উপসংহার:
আমার মতে একটি সাবলীল ইন্টারফেস যা একটি return thisবাস্তবায়ন ব্যবহার করে তা কেবল ভুল।

— বব ফ্যাঙ্গার
সূত্র
1
তবে প্রতিটি কলের জন্য কোনও নতুন উদাহরণ ফিরে না আসা কি বেশিরভাগ ওভারহেড তৈরি করবে, বিশেষত আপনি যদি বড় আইটেম ব্যবহার করছেন? কমপক্ষে অ-পরিচালিত ভাষার জন্য।
— এপিওরন
@ অপেরন পারফরম্যান্স অনুযায়ী এটি return thisপরিচালনা করা বা অন্যথায় অবশ্যই দ্রুততর । এটি আমার মতে এটি একটি "প্রাকৃতিক নয়" উপায়ে সাবলীল এপিআই লাভ করে। (যুক্ত যুক্তি 6: একটি অন-সাবলীল বিকল্প দেখাতে, যার ওভারহেড /
— অ্যাড
আমি আপনার সাথে একমত. কোনও ডিএসএলের অন্তর্নিহিত অবস্থাটি ছোঁয়া ছেড়ে দেওয়া এবং পরিবর্তে প্রতিটি পদ্ধতি কলটিতে নতুন অবজেক্টগুলি ফিরিয়ে দেওয়া ভাল ... আমি কৌতূহলী: আপনি যে লাইব্রেরিটি উল্লেখ করেছেন তা কী?
— লুকাস এদার
1

এখানে বিন্দু সম্পূর্ণভাবে মিস, যে পদ্ধতি chaining জন্য অনুমতি দেয় শুকনো । এটি "সহ" (যা কিছু ভাষায় খারাপভাবে প্রয়োগ করা হয় না) এর পক্ষে কার্যকর অবস্থান stand

A.method1().method2().method3(); // one A

A.method1();
A.method2();
A.method3(); // repeating A 3 times

এটি একই কারণে ডিআরওয়াই সর্বদা গুরুত্বপূর্ণ; যদি এটিকে একটি ত্রুটি হিসাবে দেখা দেয় এবং এই ক্রিয়াকলাপগুলি বিতে সম্পাদন করা দরকার হয় তবে আপনাকে কেবল 3 জায়গায় নয় 1 স্থানে আপডেট করতে হবে।

বাস্তবিকভাবে, সুবিধাটি এই ক্ষেত্রে ছোট। তবুও, একটু কম টাইপিং, একটি লিটল আরও দৃ rob় (ডিআরওয়াই), আমি এটি নেব।

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

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

1.)

participant
    .addSchedule(events[1])
    .addSchedule(events[2])
    .setStatus('attending')
    .save();

বনাম

participant.addSchedule(events[1]);
participant.addSchedule(events[2]);
participant.setStatus('attending');
participant.save()

2.)

participant
    .getSchedule('monday')
        .saveTo('monnday.file');

বনাম

mondaySchedule = participant.getSchedule('monday');
mondaySchedule.saveTo('monday.file');

3)

participant
    .attend(event)
    .setNotifications('silent')
    .getSocialStream('twitter')
        .postStatus('Joining '+event.name)
        .follow(event.getSocialId('twitter'));

বনাম

participant.attend(event);
participant.setNotifications('silent')
twitter = participant.getSocialStream('twitter')
twitter.postStatus('Joining '+event.name)
twitter.follow(event.getSocialId('twitter'));

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

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

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

— inf3rno
সূত্র
0

ভাল:

  1. এটি ক্ষতিকারক, তবুও আপনাকে মার্জিতভাবে একটি একক লাইনে আরও রাখার অনুমতি দেয়।
  2. আপনি কখনও কখনও কোনও ভেরিয়েবলের ব্যবহার এড়াতে পারেন যা মাঝে মধ্যে কার্যকর হতে পারে।
  3. এটি আরও ভাল পারফর্ম করতে পারে।

খারাপ জন:

  1. আপনি রিটার্ন বাস্তবায়ন করছেন, অবজেক্টগুলিতে পদ্ধতিগুলিতে মূলত কার্যকারিতা যুক্ত করছেন যা এই পদ্ধতিগুলি কী বোঝাতে চেয়েছে তা আসলে অংশ নয়। এটি এমন কিছু ফিরিয়ে দিচ্ছে যা ইতিমধ্যে কয়েকটি বাইট সংরক্ষণ করার জন্য আপনার কাছে ইতিমধ্যে রয়েছে।
  2. যখন একটি শৃঙ্খলে অন্য শৃঙ্খলে নিয়ে যায় তখন এটি প্রসঙ্গের সুইচগুলি আড়াল করে। প্রসঙ্গটি স্যুইচ করলে এটি পরিষ্কার the
  3. একাধিক লাইনের উপর শৃঙ্খলা কুরুচিপূর্ণ দেখায়, ইনডেন্টেশনের সাথে ভাল খেলেন না এবং কিছু অপারেটর হ্যান্ডলিং বিভ্রান্তি সৃষ্টি করতে পারে (বিশেষত এএসআই সহ ভাষাগুলিতে)।
  4. যদি আপনি শৃঙ্খলিত পদ্ধতির জন্য দরকারী এমন অন্য কোনও কিছু ফিরিয়ে দেওয়া শুরু করতে চান তবে আপনার সম্ভবত এটির সমাধানের জন্য আরও কঠিন সময় কাটাতে হবে বা এটির সাথে আরও সমস্যা হিট করতে হবে।
  5. আপনি এমন কোনও সত্তার নিয়ন্ত্রণ অফলোড করছেন যা আপনি সাধারণত নিখুঁতভাবে সুবিধার জন্য অফলোড করেন না, এমনকি এর কারণে কঠোরভাবে টাইপ করা ভাষায় ভুলগুলিও সর্বদা সনাক্ত করা যায় না।
  6. এটি আরও খারাপ পারফর্ম করতে পারে।

সাধারণ:

পরিস্থিতি তৈরি না হওয়া বা নির্দিষ্ট মডিউলগুলি বিশেষভাবে এটির পক্ষে উপযুক্ত না হওয়া পর্যন্ত সাধারণভাবে চেইন ব্যবহার না করা একটি ভাল পদ্ধতির।

চেইন কিছু ক্ষেত্রে পাঠের পক্ষে যথেষ্ট মারাত্মক ক্ষতি করতে পারে বিশেষত যখন পয়েন্ট 1 এবং 2 এর ওজন।

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

— jgmjgm
সূত্র
0

মতামত উত্তর

শৃঙ্খলাকৃতির সবচেয়ে বড় অসুবিধাটি হ'ল পাঠকের পক্ষে এটি বোঝা মুশকিল হতে পারে যে প্রতিটি পদ্ধতি কীভাবে মূল বস্তুকে প্রভাবিত করে যদি তা করে এবং কীভাবে প্রতিটি পদ্ধতি ফিরে আসে।

কিছু প্রশ্ন:

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

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

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

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

— এনেকো আলোনসো
সূত্র
0

টাইপ করা ভাষায় (যেটির অভাব autoবা সমতুল্য) এই প্রয়োগকারীকে মধ্যবর্তী ফলাফলের প্রকারগুলি ঘোষণা করা থেকে বাঁচায়।

import Participant
import Schedule

Participant participant = new Participant()
... snip...
Schedule s = participant.getSchedule(blah)
s.saveTo(filename)

দীর্ঘতর শৃঙ্খলার জন্য আপনি বেশ কয়েকটি বিভিন্ন অন্তর্বতী প্রকারের সাথে লেনদেন করছেন, আপনাকে সেগুলির প্রত্যেকটি ঘোষণা করতে হবে।

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

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