কোনও ক্লাস বা ফাংশনে আবৃত না করে লম্বা কিন্তু সোজা কোডটি অনুলিপি করে পেস্ট করা কি গ্রহণযোগ্য?


29

ধরুন আমার কাছে ইন্টারনেটের সাথে সংযোগ স্থাপন করার মতো কোডের একটি বিভাগ রয়েছে এবং এর মতো সংযোগের ফলাফলগুলি দেখানো:

HttpRequest* httpRequest=new HttpRequest();
httpRequest->setUrl("(some domain .com)");
httpRequest->setRequestType(HttpRequest::Type::POST);
httpRequest->setRequestData("(something like name=?&age=30&...)");
httpRequest->setResponseCallback([=](HttpClient* client, HttpResponse* response){
    string responseString=response->getResponseDataString();
        if(response->getErrorCode()!=200){
            if(response->getErrorCode()==404){
                Alert* alert=new Alert();
                alert->setFontSize(30);
                alert->setFontColor(255,255,255);
                alert->setPosition(Screen.MIDDLE);
                alert->show("Connection Error","Not Found");
            }else if((some other different cases)){
                (some other alert)
            }else
                Alert* alert=new Alert();
                alert->setFontSize(30);
                alert->setPosition(Screen.MIDDLE);
                alert->setFontColor(255,255,255);
                alert->show("Connection Error","unknown error");
            }
        }else{
            (other handle methods depend on different URL)
        }
}

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

আমার প্রশ্নটি হ'ল কোডের নির্ভরতা হ্রাস করার জন্য কোনও ফাংশনে আবদ্ধ করার পরিবর্তে দীর্ঘ কিন্তু সোজা কোডটি অনুলিপি করে পেস্ট করা কি গ্রহণযোগ্য?


89
সেই কোডটিতে আপনার কোনও বাগ রয়েছে, যেমন আপনার বরাদ্দ করা অবজেক্টগুলি নিখরচায়িত করা না। (আপনার ফ্রেমওয়ার্কটি Alertকী অবজেক্টগুলিকে মুক্ত করে ?) এখন কল্পনা করুন আপনি বাগটি ঠিক করতে এই কোডটির প্রতিটি অনুলিপি পাওয়া উচিত find এখন কল্পনা করুন যে এটি করতে হবে তা আপনি নন, তবে একজন পাগল কুঠার খুনি যিনি জানেন যে আপনিই এই কপিগুলি প্রথম স্থানে তৈরি করেছিলেন।
সেবাস্তিয়ান রেডল

8
এবং বিটিডাব্লু, এক জায়গায় নেটওয়ার্কিং এবং ত্রুটি প্রদর্শনের মিশ্রণ ইতোমধ্যে আইএমএইচও, একটি বড় নম্বর।
sleske

11
কখনো না. পুরোপুরি অগ্রহণযোগ্য। আপনি যদি আমার প্রকল্পে থাকতেন তবে আপনি আর আমার প্রকল্পে থাকবেন না এবং আপনি কোনও প্রশিক্ষণ প্রোগ্রাম বা পিআইপি-তে থাকবেন।
nhgrif

10
এবং তদারকির সাথে দেখা যায় যে "আমার স্ক্রিনের মাঝামাঝি এই সতর্কতা বাক্সটি একটি চূড়ান্ত সন্ত্রাস। আমি বিড়াল জিআইএফগুলি দেখছি এবং পপ-আপ যতবার দেখায় ততবার আমার দৃষ্টিভঙ্গি আটকাচ্ছে Please দয়া করে এটিকে উপরের-ডানদিকে নিয়ে যান । " 3 সপ্তাহ পরে "তুমি কি করছ ?! আমি আর আমার বিড়াল জিফগুলি বন্ধ করতে পারি না কারণ আপনার পপ-আপটি উপরের ডানদিকে এক্সটি .েকে রাখছে, এটি ঠিক করুন"।
MonkeyZeus

11
আমি মনে করি এখানকার প্রত্যেকে মনে হয় এটি একটি খারাপ ধারণা। তবে প্রশ্নটি ঘুরিয়ে দেওয়ার জন্য, আপনি কেন এই কোডটি একটি পৃথক শ্রেণি বা ফাংশনে রাখবেন না?
কার্ল জিজারটেন

উত্তর:


87

আপনার পরিবর্তনের ব্যয়টি বিবেচনা করা উচিত। আপনি কীভাবে সংযোগ তৈরি হয় তা পরিবর্তন করতে চান? এটা কত সহজ হবে? আপনার যদি ডুপ্লিকেট কোডটি প্রচুর পরিমাণে থাকে তবে পরিবর্তনের জন্য প্রয়োজনীয় সমস্ত জায়গাগুলি সন্ধান করা যথেষ্ট সময়সাপেক্ষ এবং ত্রুটির প্রবণ হতে পারে।

আপনার স্বচ্ছতাও বিবেচনা করা উচিত। সম্ভবত, কোডের 30 টি লাইনের দিকে নজর রাখা "কানেক্টটইন্টারনেট" ফাংশনে একটি একক কল হিসাবে বোঝা তত সহজ হবে না। যখন নতুন কার্যকারিতা যুক্ত করা দরকার তখন কোডটি বোঝার চেষ্টা করে কত সময় নষ্ট হতে চলেছে?

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

Https://softwareengineering.stackexchange.com/a/103235/63172 এও দেখুন


19
... এবং কে জানে যে এই 30 টি লাইনগুলি সেই আগের মতোই একই ছিল যা আপনি আগে দেখেছেন বা যদি কোনও কারণেই তার অনুলিপিতে অন্য কোনও বন্দর বা আইপি ঠিকানায় স্যুইচ করে। অন্তর্নিহিত ধারণা যে " 30 টির সাথে কিছু লাইন শুরু হয়ে HttpRequestসমস্ত একই হয় " মিথ্যাচারটি করা সহজ is
নাল

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

54

না।

প্রকৃতপক্ষে, এমনকি আপনার "সাধারণ" কোডটি ছোট অংশে বিভক্ত করা উচিত। অন্তত দুটি.

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

তেমনি ত্রুটিগুলি পরিচালনা করার জন্য আরেকটি। উদাহরণস্বরূপ, আপনি যদি সতর্কতার রঙ বা ফন্টের আকার পরিবর্তন করেন। অথবা আপনার মাঝে মাঝে সংযোগ নিয়ে সমস্যা হচ্ছে এবং ত্রুটিগুলি লগ করতে চান।



আপনি এসআরপিকেও উদ্ধৃতি দিতে পারেন: একটি ব্লক রয়েছে যার একটিমাত্র উদ্দেশ্য রয়েছে তা বোঝা এবং বজায় রাখা এত সহজ করে তোলে ..
রোল্যান্ড টাপ

এটি এমন একটি ক্ষেত্রে যেখানে ডিআরওয়াই এবং এসআরপি আসলে সারিবদ্ধ হয়। কখনও কখনও তারা না।
user949300

18

এটি কি অনুলিপি এবং পেস্ট করা গ্রহণযোগ্য ...

না।

আমার পক্ষে সিদ্ধান্তের তর্কটি এটি:

... এটি সাধারণত ব্যবহৃত হয় ...

আপনি একটি কোড টুকরা ব্যবহার করেন তাহলে আরো তারপর একাধিক স্থান, যখন এটা পরিবর্তন, আপনি করতে হবে পরিবর্তন "বিজোড় জিনিস" ঘটতে শুরু (অর্থাত আপনি বাগ পরিচয় করিয়ে) - একাধিক স্থানে অথবা আপনি অসঙ্গতি পেতে শুরু।

এটা সোজা এবং জটিল নয় ...

এবং তাই একটি ফাংশন মধ্যে চুল্লী করা সহজ সব করা উচিত।

... এখানে url, ফন্টের আকারের মতো সেটিংগুলির বান্ডিল রয়েছে ...

এবং ব্যবহারকারীরা কি পরিবর্তন করতে পছন্দ করেন? হরফ, ফন্টের আকার, রঙ ইত্যাদি

এখন; সমস্ত একই রঙ / ফন্ট / আকার আবার পেতে আপনাকে সেই একই কোডের টুকরোটি কত জায়গায় পরিবর্তন করতে হবে? (প্রস্তাবিত উত্তর: মাত্র একটি )

... কোড বিভাগে শ্রেণীর মধ্যে সামান্য তফাত রয়েছে (যেমন: ইউআরএল, অনুরোধ ডেটা, ত্রুটি কোড হ্যান্ডেল কেস, সাধারণ হ্যান্ডেল কেস ...)

পার্থক্য => ফাংশন প্যারামিটার (গুলি)।


"এবং ব্যবহারকারীরা কী পরিবর্তন করতে পছন্দ করেন? হরফ, ফন্টের আকার, রঙ ইত্যাদি" এটি এতদিকটা কাজ করে। আপনি কি কয়েক ডজন জায়গায় সত্যই এটি পরিবর্তন করতে চান?
ড্যান

8

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

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

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


6

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

উদাহরণ স্বরূপ:

def add(a, b)
    return a + b
end

বোকা, শুধু একটি + বি করতে।

তবে আপনি যখন কিছুটা সামান্য, আরও কিছুটা জটিল হয়ে উঠবেন, তখন আপনি সাধারণত লাইনের উপর দিয়ে যান।

foo.a + foo.b

হয়ে উঠতে হবে

foo.total
def foo
    ...
    def total
        return self.a + self.b
    end
end

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

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

Web.Post(URI, Params, ResponseHandler);

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

এই কোড রাখে শুকনো এবং সাহায্য করে SRP


0

যে কোনও আকার / জটিলতার প্রকল্পে আমি নিম্নলিখিত প্রয়োজনগুলির জন্য যখন কোড প্রয়োজন তখন আমি তা সন্ধান করতে সক্ষম হতে চাই:

  1. এটি ভেঙে গেলে ঠিক করুন
  2. কার্যকারিতা পরিবর্তন করুন
  3. এটি পুনরায় ব্যবহার করুন।

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

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


0

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

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

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


-1

কোনও কোডটি নকল করে ফাংশনটিতে ডাবলিকেট করা উচিত কিনা যা দ্বিগুণ বলা হয় তা নির্ধারণের জন্য, কোনটি আরও সম্ভাব্য তা নির্ধারণের চেষ্টা করুন:

  1. কোডের উভয় ব্যবহারকে একইভাবে পরিবর্তন করা প্রয়োজন।

  2. কোডটির কমপক্ষে একটি ব্যবহারের পরিবর্তন করা প্রয়োজন যাতে তারা পৃথক হয়।

প্রথম ক্ষেত্রে, সম্ভবত একটি ফাংশন উভয় ব্যবহার হ্যান্ডেল করা ভাল; পরবর্তী ক্ষেত্রে, দুটি ব্যবহারের জন্য পৃথক কোড রাখাই ভাল।

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

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