শর্তসাপেক্ষের এই ব্যবহারটি কি একটি বিরোধী-প্যাটার্ন?

Question

আমি কাজের ক্ষেত্রে আমাদের উত্তরাধিকার ব্যবস্থায় এটি অনেক কিছু দেখেছি - এমন ক্রিয়াকলাপগুলি:

bool todo = false;
if(cond1)
{
  ... // lots of code here
  if(cond2)
    todo = true;
  ... // some other code here
}

if(todo)
{
  ...
}

অন্য কথায়, ফাংশনটির দুটি অংশ রয়েছে। প্রথম অংশটি কিছু প্রক্রিয়াকরণ করে (সম্ভাব্যভাবে লুপগুলি, পার্শ্ব প্রতিক্রিয়াগুলি অন্তর্ভুক্ত ইত্যাদি) এবং সেই পথে এটি "টুডো" পতাকা সেট করতে পারে। "টুডু" পতাকাটি সেট করা থাকলে কেবল দ্বিতীয় অংশটি কার্যকর করা হয়।

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

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

Comments

আপনি কিভাবে এটি রিফ্যাক্টর?

— ট্যামস সেজেলি

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

— ব্যবহারকারী 281377

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

— ডোনাল ফেলো

@ ডোনাল ফেলো: কারণটির জন্য অনুসন্ধান করা যদি প্রয়োজনীয় হয় তবে আমি ভেরিয়েবলকে একটি তালিকাতে পরিণত করব; যতক্ষণ না এটি খালি, এটি "মিথ্যা"; পতাকা যেখানেই সেট করা আছে, তালিকায় একটি যুক্তি কোড যুক্ত করা হয়েছে। সুতরাং আপনি সম্ভবত একটি তালিকা দিয়ে শেষ হতে পারে ["blacklisted-domain","suspicious-characters","too-long"]যে বিভিন্ন কারণ প্রয়োগ করা।

— ব্যবহারকারী 281377

আমি মনে করি এটি একটি বিরোধী-নিদর্শন নয়, তবে এটি অবশ্যই গন্ধযুক্ত

— বাইনারি ওয়ারিয়ার

Answer 1

আমি অ্যান্টি-প্যাটার্ন সম্পর্কে জানি না, তবে আমি এগুলি থেকে তিনটি পদ্ধতি বের করব।

প্রথমটি কিছু কাজ সম্পাদন করবে এবং একটি বুলিয়ান মান প্রদান করবে।

দ্বিতীয়টি "অন্য কোনও কোড" দ্বারা সম্পাদিত যা কিছু কাজ সম্পাদন করবে

তৃতীয়টি বুলিয়ান সত্য হলে এটি সহায়ক কাজ সম্পাদন করবে।

নিষ্ক্রিয় পদ্ধতিগুলি সম্ভবত ব্যক্তিগত হবে যদি প্রথম পদ্ধতিটি সত্য হয় তবে দ্বিতীয়টি (এবং সর্বদা) বলা উচিত।

পদ্ধতিগুলির নামকরণের মাধ্যমে, আমি আশা করি এটি কোডটি আরও পরিষ্কার করে দেবে।

এটার মতো কিছু:

public void originalMethod() {
    bool furtherProcessingRequired = lotsOfCode();
    someOtherCode();
    if (furtherProcessingRequired) {
        doFurtherProcessing();
    }
    return;
}

private boolean lotsOfCode() {
    if (cond1) {
        ... // lots of code here
        if(cond2) {
            return true;
        }
    }
    return false;
}

private void someOtherCode() {
    ... // some other code here
}

private void doFurtherProcessing() {
    // Do whatever is needed
}

স্পষ্টতই প্রথম দিকের রিটার্ন গ্রহণযোগ্য কিনা তা নিয়ে বিতর্ক রয়েছে তবে এটি একটি বাস্তবায়ন বিশদ (কোড ফর্ম্যাটিং মান হিসাবে)।

পয়েন্ট হ'ল কোডের উদ্দেশ্যটি আরও পরিষ্কার হয়ে যায়, যা ভাল ...

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

Comments

2 ফাংশনে বিভক্ত হওয়ার জন্য এখনও একটি todoপরিবর্তনশীল প্রয়োজন এবং এটি বোঝা আরও শক্ত হবে।

— পাব্বি

হ্যাঁ, আমি এটিও করতাম তবে আমার প্রশ্নটি "টুডু" পতাকাটির ব্যবহার সম্পর্কে আরও ছিল।

— ক্রিকেট

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

— স্টিভ 314

@ পাব্বি 8 তিনি বলেছেন "এটি থেকে 2 টি পদ্ধতি বের করুন" যার ফলস্বরূপ 3 টি পদ্ধতি। প্রকৃত প্রক্রিয়াজাতকরণ করার 2 টি পদ্ধতি এবং ওয়ার্কফ্লো সমন্বয় করার মূল পদ্ধতি। এটি একটি অনেক ক্লিনার ডিজাইন হবে।

— ম্যাটড্যাভি

এটি ... // some other code hereপ্রারম্ভিক রিটার্নের ক্ষেত্রে বাদ দেয়

— কালেথ

Answer 2

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

সুতরাং আপনি যদি @ বিলের পরামর্শ অনুসারে কোডের বেশিরভাগ নিম্ন স্তরের পদ্ধতিতে উত্তোলন করেন তবে বাকিগুলি পরিষ্কার হয়ে যায় (আমার পক্ষে কমপক্ষে)। যেমন

bool registrationNeeded = installSoftware(...);
if (registrationNeeded) {
  registerUser(...)
}

অথবা আপনি দ্বিতীয় পদ্ধতিতে পতাকা চেকটি গোপন করে এবং এর মতো কোনও ফর্ম ব্যবহার করে স্থানীয় পতাকা থেকে সম্পূর্ণ মুক্তি পেতে পারেন

calculateTaxRefund(isTaxRefundable(...), ...)

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

Answer 3

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

ধরা যাক যে ফাংশনের দ্বিতীয় অংশটি একটি তালিকা সাজায়, প্রথম অংশ দ্বারা নির্মিত। এটি আরও বেশি পঠনযোগ্য হওয়া উচিত:

bool requiresSorting = false;
if(cond1)
{
    ... // lots of code here
    if(cond2)
        requiresSorting = true;
    ... // some other code here
}

if(requiresSorting)
{
    ...
}

তবে বিলের পরামর্শও সঠিক। এটি এখনও আরও পঠনযোগ্য:

bool requiresSorting = BuildList(list);
if (requiresSorting)
    SortList(list);

Comments

কেন শুধু আরও একধাপ এগিয়ে যান না: যদি (বিল্ডলিস্ট (তালিকা)) সোর্টলিস্ট (তালিকা);

— ফিল এন ডিব্ল্যাঙ্ক

Answer 4

রাষ্ট্রযন্ত্রের প্যাটার্নটি আমার কাছে দুর্দান্ত দেখাচ্ছে। সেখানে থাকা বিরোধী নিদর্শনগুলিতে "টুডো" (খারাপ নাম) এবং "প্রচুর কোড" রয়েছে।

Comments

আমি নিশ্চিত যে এটি কেবল উদাহরণের জন্য।

— লরেন পেচটেল

একমত। আমি যেটা জানাতে চাইছিলাম তা হ'ল ভাল নিদর্শনগুলিকে কোডের মানের জন্য দোষ দেওয়া উচিত নয়।

— ptyx

Answer 5

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

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

Comments

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

— লোরেন পেচটেল

Answer 6

এখানে বেশিরভাগ উত্তরের একটি জটিলতা যাচাই করে যেতে সমস্যা হবে, কিছু লোক> 10 দেখেছেন।

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

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

Answer 7

উপরের পিডির উদাহরণ ব্যবহার করে, এটি একটি দুর্দান্ত উদাহরণ হিসাবে, আমি আরও এক ধাপ এগিয়ে যাব।

তার ছিল:

bool requiresSorting = BuildList(list);
if (requiresSorting)
    SortList(list);

সুতরাং আমি বুঝতে পেরেছি যে নিম্নলিখিতগুলি কাজ করবে:

if(BuildList(list)) 
    SortList(list)

তবে তেমন পরিষ্কার নয়।

তাই মূল প্রশ্নে, কেন নেই:

BuildList(list)
SortList(list)

এবং এর জন্য বাছাই করা দরকার কিনা তা SortList কে সিদ্ধান্ত নিতে দিন?

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

Comments

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

— আইয়ান

এটি কোনও উত্তর নয়। আপনি কোডটির আচরণ পরিবর্তন করেছেন।

— D Drmmr

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

— ইয়ান

Answer 8

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

এছাড়াও সমৃদ্ধ ডোমেন মডেল, সেক্ষেত্রে কেবলমাত্র একটি লাইনার বস্তুর ভিতরে বড় কাজ করবে things

Answer 9

যদি পতাকাটি কেবল একবার সেট করা থাকে তবে
...
কোডটি সরাসরি
... ... // পরে অন্য কোনও কোডের
পরে সরিয়ে নিন তবে পতাকাটি বাদ দিন।

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

যেখানেই সম্ভব কোডটি পৃথক করুন
... // এখানে প্রচুর কোড
দুটি বা ততোধিক ফাংশন হিসাবে বিভক্ত করা হয়েছে , কেউ কেউ কিছু কাজ করে (যা একটি আদেশ) এবং অন্যরা হয় টোডো মান (যা একটি কোয়েরি) ফেরত দেয় বা এটি তৈরি করে খুব স্পষ্টত তারা এটিকে সংশোধন করছে (পার্শ্ব-প্রতিক্রিয়া ব্যবহার করে একটি কোয়েরি)

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

Comments

এই পোস্টটি কী যুক্ত করে যে বিদ্যমান উত্তরগুলি অনুপস্থিত রয়েছে?

— esoterik

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

— অ্যান্ড্রু পেট

Answer 10

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

// Check individual fields for proper input

if(fieldsValidated) {
  // Perform cross-checks to see if input contains values which exist in the database

  if(valuesExist) {
    try {
      // Attempt insertion
      trx.commit();
    } catch (DatabaseException dbe) {
      trx.rollback();
      throw dbe;
    }
  } else {
    closeConnection(db);
    throwException();
  }
} else {
  closeConnection(db);
  throwException();
}

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

boolean proceed = true;
// Check individual fields for proper input

if(fieldsValidated) {
  // Perform cross-checks to see if input contains values which exist in the database

  if(!valuesExist) {
    proceed = false;
  }
} else {
  proceed = false;
}

// The moment of truth
if(proceed) {
  try {
    // Attempt insertion
    trx.commit();
  } catch (DatabaseException dbe) {
    trx.rollback();
    throw dbe;
  }
} else {
  if(db.isOpen()) {
    closeConnection(db);
  }
  throwException();
}

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

Comments

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

— ক্রিটিকে

@ কেলসি রাইডার, এটি হ'ল পয়েন্ট। কার্যকরকরণ থেকে বৈধতা পৃথক করা আপনাকে প্রোগ্রামের সামগ্রিক যুক্তিটিকে যদি (isVmittedated ()) doOperation ()

— নীল

Answer 11

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

এখন, আপনার সুনির্দিষ্ট উদাহরণটি এ হিসাবে আবারও লেখা যেতে পারে:

if(cond1)
{
    ... // lots of code here
    ... // some other code here
    if (cond2)
    {
        ...
    }
}

এটি পড়া সহজ হতে পারে। হয়তো বা না. এটি আপনার বাদ দেওয়া কোডের উপর নির্ভর করে। এই কোডটি আরও সংহত করতে ফোকাস করুন।

Answer 12

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

অনেক ক্ষেত্রে, পতাকা ব্যবহার করে যে কোডগুলি ব্যবহার করা gotoহয় তার পরিবর্তে যে কোনও সম্ভাব্য বিকল্পের চেয়ে বেশি পরিষ্কার হবে তবে এটি সর্বদা সত্য নয়। কিছু ক্ষেত্রে, gotoকোডের একটি অংশ এড়িয়ে যাওয়া ব্যবহার করা পতাকা ব্যবহারের চেয়ে পরিষ্কার হতে পারে [যদিও কিছু লোকেরা এখানে একটি নির্দিষ্ট র‌্যাপার কার্টুন inোকাতে পারে]।

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