দীর্ঘ পদ্ধতির রিফ্যাক্টরিং: স্থানীয় ফাংশন ব্যবহার করে পদ্ধতিগুলিতে পৃথক করা বনাম হিসাবে ছেড়ে যাওয়া


9

ধরুন আমার কাছে দীর্ঘ পদ্ধতি রয়েছে:

public void SomeLongMethod()
{
    // Some task #1
    ...

    // Some task #2
    ...
}

এই পদ্ধতির কোনও পুনরাবৃত্ত অংশ নেই যা পৃথক পদ্ধতি বা স্থানীয় ফাংশনে স্থানান্তরিত করা উচিত।

অনেক লোক আছে (আমাকে সহ) যারা মনে করেন যে দীর্ঘ পদ্ধতিগুলি কোড গন্ধ। এছাড়াও আমি #regionএখানে (গুলি) ব্যবহারের ধারণা পছন্দ করি না এবং এটি কেন খারাপ তা ব্যাখ্যা করার জন্য একটি খুব জনপ্রিয় উত্তর রয়েছে


তবে যদি আমি এই কোডটি পদ্ধতিতে আলাদা করি

public void SomeLongMethod()
{
    Task1();

    Task2();
}

private void Task1()
{
    // Some task #1
    ...
}

private void Task2()
{
    // Some task #1
    ...
}

আমি নিম্নলিখিত বিষয়গুলি দেখতে পাচ্ছি:

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

  • দূষণকারী আইডিই স্বতঃসম্পূর্ণ (যেমন ইন্টেলিসেন্স) এমন একক SomeLongMethodপদ্ধতিতে যা একবারে ব্যবহৃত হত ।


সুতরাং যদি আমি স্থানীয় ফাংশন মধ্যে এই পদ্ধতি কোড পৃথক

public void SomeLongMethod()
{
    Task1();

    Task2();

    void Task1()
    {
        // Some task #1
        ...
    }

    void Task2()
    {
        // Some task #1
        ...
    }
}

তবে এর পৃথক পদ্ধতির ত্রুটিগুলি নেই তবে এটি মূল পদ্ধতির চেয়ে ভাল (কমপক্ষে আমার জন্য) দেখাচ্ছে না।


কোন সংস্করণ আপনার জন্য SomeLongMethodআরও রক্ষণাবেক্ষণযোগ্য এবং পাঠযোগ্য এবং কেন?



আমার প্রশ্ন @gnat জন্য নির্দিষ্ট C # , না জাভা । আমার মূল উদ্বেগটি ক্লাসিক পদ্ধতি বনাম স্থানীয় ফাংশন সম্পর্কে, কেবল পদ্ধতিগুলিতে আলাদা নয় বা নয়।
ভাদিম ওভচিনিকভ

@ গ্যাनेट এএফএইকি জাভা (সি # এর বিপরীতে) নেস্টেড ফাংশনগুলি সমর্থন করে না।
ভাদিম ওভচিনিকভ

1
ব্যক্তিগত কীওয়ার্ডটি অবশ্যই আপনার 'শ্রেণির সংজ্ঞা স্কোপ' রক্ষা করে?
ইভান

1
অপেক্ষা ...... আপনার ক্লাস কত বড়?
ইভান

উত্তর:


13

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

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

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


সুতরাং আপনি স্থানীয় ফাংশন নয়, পদ্ধতিগুলির জন্য হ্যাঁ?
ভাদিম ওভচিনিকভ

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

6

আমি উভয় পদ্ধতির পছন্দ করি না। আপনি কোনও বিস্তৃত প্রসঙ্গ সরবরাহ করেন নি তবে বেশিরভাগ সময় এরকম দেখাচ্ছে:

আপনার একটি ক্লাস রয়েছে যা একক ফলাফলের সাথে একাধিক পরিষেবাদির শক্তি একত্রিত করে কিছু কাজ করে।

class SomeClass
{
    private readonly Service1 _service1;
    private readonly Service2 _service2;

    public void SomeLongMethod()
    {
        _service1.Task1();
        _service2.Task2();       
    }
}

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

class Service1
{
    public void Task1()
    {
        // Some task #1
        ...
    }

    private void SomeHelperMethod() {}
}

class Service2
{
    void Task2()
    {
        // Some task #1
        ...
    }
}

মূল লাইনটি হ'ল: আপনি যদি গোর্প পদ্ধতিগুলির জন্য আপনার কোডে অঞ্চলগুলি তৈরি করা শুরু করেন তবে তাদের যুক্তিটিকে একটি নতুন পরিষেবা দিয়ে সজ্জিত করার বিষয়ে চিন্তাভাবনা শুরু করার সময় প্রায়।


2

পদ্ধতির মধ্যে ফাংশন তৈরি করতে সমস্যা হ'ল এটি পদ্ধতির দৈর্ঘ্য হ্রাস করে না।

আপনি যদি অতিরিক্ত স্তরের সুরক্ষা 'প্রাইভেট টু মেথড' চান তবে আপনি একটি নতুন ক্লাস তৈরি করতে পারেন

public class BigClass
{
    public void SomeLongMethod();

    private class SomeLongMethodRunner
    {
        private void Task1();
        private void Task2();
    }
}

তবে ক্লাসে ক্লাসগুলি বড় কুৎসিত: /


2

ভেরিয়েবল এবং পদ্ধতিগুলির মতো ভাষা নির্মানের সুযোগকে হ্রাস করা ভাল অনুশীলন is যেমন গ্লোবাল ভেরিয়েবলগুলি এড়ান .. এটি কোডটি বোঝা সহজ করে তোলে এবং অপব্যবহার এড়াতে সহায়তা করে কারণ কম জায়গায় কমপ্লিটটি অ্যাক্সেস করা যায়।

এটি স্থানীয় ফাংশনগুলি ব্যবহারের পক্ষে কথা বলে।


1
এইচএমএম নিশ্চয়ই কোডটি পুনরায় ব্যবহার করছে == অনেক কলকারীদের মধ্যে একটি পদ্ধতি ভাগ করে নেওয়া। অর্থাত্ এর পরিধিটি সর্বাধিকতর করা
ইওয়ান

1

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

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

স্থানীয় কার্যাবলী যে পৃষ্ঠাটি বলে:

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

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

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

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