প্রাইভেট সহায়ক সহায়তার পদ্ধতিগুলি স্থির থাকতে পারে


205

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

public class Example {
   private Something member;

   public double compute() {
       double total = 0;
       total += computeOne(member);
       total += computeMore(member);
       return total;         
   }

   private double computeOne(Something arg) { ... }
   private double computeMore(Something arg) {... } 
} 

সেখানে নির্দিষ্ট করার কোন বিশেষ কারণ আছে computeOneএবং computeMoreবা না কোনো নির্দিষ্ট কারণ - স্ট্যাটিক পদ্ধতি হিসেবে?

এগুলি অ-স্থির হিসাবে ছেড়ে দেওয়া অবশ্যই সবচেয়ে সহজ, যদিও তারা কোনও সমস্যা না করেই অবশ্যই স্থির থাকতে পারে।


3
জাভাতে কীওয়ার্ড স্ট্যাটিকটি ব্যবহার না করার সময় এটিও দেখুন: stackoverflow.com/questions/1766715/…
মার্ক বাটলার

উত্তর:


174

আমি এই ধরনের সহায়ক পদ্ধতি হতে পছন্দ করি private static; যা পাঠকের কাছে পরিষ্কার হয়ে যাবে যে তারা বস্তুর স্থিতি পরিবর্তন করবে না। আমার আইডিই ইটালিক্সে স্থির পদ্ধতিতে কলগুলিও প্রদর্শন করবে, সুতরাং আমি জানতে পারি যে স্বাক্ষরটি না দেখে পদ্ধতিটি স্থির।


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

2
আমি সেই হেল্পার পদ্ধতিগুলিকে সাধারণত ঘোষণা করি যেগুলি protected staticএকই প্যাকেজের একটি পরীক্ষার শ্রেণিতে খুব সহজেই পরীক্ষারযোগ্য করে তোলে।
জেমস

2
@ জেমস বা সহজভাবে static(যদি আমরা কেবল পরীক্ষার জন্য এটি চাই)।
mrod

3
"অবজেক্টের স্থিতি পরিবর্তন করবে না" - এটি কোনও ব্যক্তিগত পদ্ধতি থেকে কীভাবে আলাদা করা যায় তার বিশদ ব্যাখ্যা।
হোপকিং

110

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

আমি এগুলি স্থির করে তুলি, যেহেতু আমি যদি সম্ভব হয় তবে সাধারণত তা করি। তবে তা কেবল আমিই।


সম্পাদনা: বাইটকোড আকার সম্পর্কে অসমর্থিত দৃ as়তার কারণে সম্ভবত এই উত্তরটি নিম্নচাপিত হতে থাকবে। সুতরাং আমি আসলে একটি পরীক্ষা চালাতে হবে।

class TestBytecodeSize {
    private void doSomething(int arg) { }
    private static void doSomethingStatic(int arg) { }
    public static void main(String[] args) {
        // do it twice both ways
        doSomethingStatic(0);
        doSomethingStatic(0);
        TestBytecodeSize t = new TestBytecodeSize();
        t.doSomething(0);
        t.doSomething(0);
    }
}

বাইটকোড (এর সাথে পুনরুদ্ধার করা javap -c -private TestBytecodeSize):

Compiled from "TestBytecodeSize.java"
class TestBytecodeSize extends java.lang.Object{
TestBytecodeSize();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

private void doSomething(int);
  Code:
   0:   return

private static void doSomethingStatic(int);
  Code:
   0:   return

public static void main(java.lang.String[]);
  Code:
   0:   iconst_0
   1:   invokestatic    #2; //Method doSomethingStatic:(I)V
   4:   iconst_0
   5:   invokestatic    #2; //Method doSomethingStatic:(I)V
   8:   new     #3; //class TestBytecodeSize
   11:  dup
   12:  invokespecial   #4; //Method "<init>":()V
   15:  astore_1
   16:  aload_1
   17:  iconst_0
   18:  invokespecial   #5; //Method doSomething:(I)V
   21:  aload_1
   22:  iconst_0
   23:  invokespecial   #5; //Method doSomething:(I)V
   26:  return

}

স্থিতিশীল পদ্ধতিটি চালু করতে দুটি বাইকোড (বাইটপ?) লাগে: iconst_0(যুক্তির জন্য) এবং invokestatic
স্থিতিশীল পদ্ধতিটি না নেওয়াতে তিনটি সময় লাগে: aload_1( TestBytecodeSizeবস্তুর জন্য, আমি মনে করি), iconst_0(যুক্তির জন্য), এবং invokespecial। (মনে রাখবেন যে এগুলি যদি ব্যক্তিগত পদ্ধতি না হত তবে এটির invokevirtualপরিবর্তে এটি হত invokespecial; জেএলএস §7.7 আমন্ত্রণ পদ্ধতিগুলি দেখুন ))

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

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

তবে 1997 এর পরে অনেক কিছুই পরিবর্তিত হয়েছে।

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


এই সমস্ত নেতিবাচক ভোটগুলির জন্য যা খুব সোজা উত্তর বলে মনে হচ্ছে সত্য, ন্যায়বিচারের স্বার্থে +1, ....
স্টিভ বি।

ধন্যবাদ। (যদিও আমি এটি মুছে ফেলা এবং একটি ব্যাজ অর্জিত যখন এটি এ -3 ছিল পারতেন। ডি)
মাইকেল ম্যাইইয়ার্স

2
জেআইটি সংকলক যাহাই হউক না কেন ইনলাইন এবং সেগুলি অপ্টিমাইজ করবে, সুতরাং বাইটকোড নির্দেশের পরিমাণটি কত দ্রুত হবে তার সাথে সামান্যই সম্পর্কযুক্ত।
এস্কো Luontola

3
এ কারণেই আমি বলেছিলাম "আমি মনে করি না এটি গতিতে কোনও পার্থক্য করে (এবং এটি যদি হয় তবে সামগ্রিকভাবে কোনও পার্থক্য করা খুব সামান্য হবে)"।
মাইকেল ময়র্স

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

18

আমার ব্যক্তিগত অগ্রাধিকার তাদের স্থির ঘোষণা করা হবে, কারণ এটি স্পষ্ট পতাকা যে তারা রাষ্ট্রহীন।


18

উত্তরটি হল, এটা নির্ভরশীল.

সদস্য যদি আপনি যে বিষয়টির সাথে কাজ করছেন তার সাথে সম্পর্কিত কোনও উদাহরণের পরিবর্তনশীল হয়, তবে কেন এটি একে একে পরামিতি হিসাবে পাস করবেন?

এই ক্ষেত্রে:

public class Example {
   private Something member;

   public double compute() {
       double total = 0;
       total += computeOne();
       total += computeMore();
       return total;         
   }

   private double computeOne() { /* Process member here */ }
   private double computeMore() { /* Process member here */ } 
}

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

11

স্থিতিশীল সহায়তার পদ্ধতিগুলি আপনি ঘোষণা করতে চাইতে পারেন তার একটি কারণ হ'ল যদি আপনাকে "পূর্বে" thisবা শ্রেণীর নির্মাতাকে তাদের কল করতে হয় super। উদাহরণ স্বরূপ:

public class MyClass extends SomeOtherClass { 
    public MyClass(String arg) {
       super(recoverInt(arg));
    }

    private static int recoverInt(String arg) {
       return Integer.parseInt(arg.substring(arg.length() - 1));
    }
}

এটি কিছুটা স্বল্প উদাহরণের উদাহরণস্বরূপ তবে স্পষ্টতই recoverIntএই ক্ষেত্রে কোনও উদাহরণ পদ্ধতি হতে পারে না।


আপনি কনস্ট্রাক্টরে একটি উদাহরণ পদ্ধতিতে কল করতে পারেন, তবে আপনি সুপার (...) বা এই (...) দিয়ে অন্য কোনও কনস্ট্রাক্টরকে ডেলিগেশন দিলে, আপনি প্রতিনিধি দলের পরে কোনও উদাহরণ পদ্ধতি কল করতে পারবেন না (তবে স্ট্যাটিকগুলি ঠিক আছে যেমন আপনি উল্লেখ করেছেন)
কিপ করুন

10

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

বিভিন্ন অ্যাক্সেস সুবিধা সহ পদ্ধতির জন্য, আমি মনে করি দুটি প্রধান যুক্তি রয়েছে:

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

তদ্ব্যতীত, পার্থক্যটি বেশ ছোট, এবং আমি দৃ strongly়ভাবে সন্দেহ করি যে উদাহরণটি পদ্ধতিতে অতিরিক্ত এই পয়েন্টারটি পাস করা একটি উল্লেখযোগ্য পার্থক্য করে makes


4
এটিকে স্থিতিশীল না করার সুবিধাটি হ'ল যে কেউ এই পদ্ধতির আচরণকে সাবক্লাস এবং ওভাররাইড করতে পারে।
ক্লিন্ট মিলার

7
এটি একটি ব্যক্তিগত পদ্ধতিতে ক্লিন্ট করুন যাতে আপনি পদ্ধতিটিকে ওভাররাইড করতে পারবেন না।
ভূষণ ভাঙলে

হুবহু, ব্যক্তিগত পদ্ধতির জন্য আমার মনে হয় না এটি খুব বেশি পার্থক্যের সৃষ্টি করে। জনসাধারণের পদ্ধতিগুলির জন্য, তবে আপনি যা বলছেন তার সাথে আমি একমত
এক্সেল জেগলারের

8

সঠিক উত্তরটি হ'ল:

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


5

বা কোনও নির্দিষ্ট কারণ না [তাদের স্থিতিশীল হিসাবে ঘোষণা করুন]?

হ্যাঁ.

এগুলিকে উদাহরণস্বরূপ পদ্ধতি হিসাবে রেখে আপনি পরে নিজেকে অন্যরকম বাস্তবায়ন করার অনুমতি দিন।

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

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

অতিরিক্তভাবে, আপনি নির্মাণকারীকে ব্যক্তিগত করে উপকার করতে পারেন এবং একই কারণে একটি স্থিতিশীল কারখানার পদ্ধতি সরবরাহ করতে পারেন।

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

কিছুটা সম্পর্কিত ভিডিওর জন্য এখানে দেখুন: একটি ভাল এপিআই কীভাবে ডিজাইন করা যায় এবং কেন এটি গুরুত্বপূর্ণ

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


1
সম্পূর্ণ একমত. আমি সাধারণত স্ট্যাটিক্স এড়াতে চেষ্টা করি এবং কেবল এই কারণে পুরোপুরি ব্যক্তিগতকরণ করি। আমি মনে করি যে অন্যান্য উত্তরগুলির বেশিরভাগই পয়েন্টটি মিস করেছে।
ক্লিন্ট মিলার

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

আআআআআআআআআআআমআমমম ... এটি একটি ভাল পয়েন্ট জোনিক। তবুও, একটি ভাল অভ্যাস তৈরি করার যথেষ্ট কারণ হওয়া উচিত (বিষয়গতভাবে অবশ্যই কথা বলা)
অস্কাররাজ

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

2
আপনি যে পরামর্শ দেন তা যদি পদ্ধতিটি ব্যক্তিগত না হয় তবে তা বোধগম্য হতে পারে তবে তারপরেও আমি আপনাকে কল্পনা করা প্রয়োজনের ভিত্তিতে ডিজাইনিং করার পরিবর্তে বর্তমান প্রয়োজনের ভিত্তিতে নকশা করার পরামর্শ দিচ্ছি।
পিটার ল্যারি

5

স্থির পদ্ধতিগুলি সম্পর্কে একটি সমস্যা হ'ল এটি ইউনিট পরীক্ষায় অবজেক্টটিকে আরও জটিল করে তুলতে পারে । মকিতো স্থির পদ্ধতির জন্য মক তৈরি করতে পারে না এবং আপনি পদ্ধতির একটি সাবক্লাস বাস্তবায়ন তৈরি করতে পারবেন না।


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

@ বিডাব্লু এটি একটি অত্যন্ত বিষয়মূলক জিনিস। একটি ব্যক্তিগত পদ্ধতি পরীক্ষা করার জন্য অনেকগুলি বৈধ কারণ রয়েছে।
রুহোলা

4

পদ্ধতিটি যদি মূলত কেবল একটি সাবরুটিন হয় যা কখনই রাষ্ট্রীয় তথ্য ব্যবহার করে না, স্থির ঘোষণা করুন।

এটি এটিকে অন্যান্য স্থিতিশীল পদ্ধতিতে বা শ্রেণি সূচনাতে যেমন ব্যবহার করতে দেয়:

public class Example {
   //...

   //Only possible if computeOne is static
   public final static double COMPUTED_ONE = computeOne(new Something("1"));

   //...
}

3

এই মত ক্ষেত্রে আমার পছন্দ করা হয় computeOneএবং computeMoreস্ট্যাটিক পদ্ধতি। কারণ: এনক্যাপসুলেশন। আপনার ক্লাসের প্রয়োগে যত কম কোড অ্যাক্সেস রয়েছে তত ভাল।

আপনি যে উদাহরণটি দিয়েছেন তা উদাহরণস্বরূপ, আপনি বলেছেন যে computeOneএবং computeMoreক্লাসের ইন্টার্নালগুলি অ্যাক্সেস করার দরকার নেই, সুতরাং কেন শ্রেণির রক্ষণাবেক্ষণকারীদের ইন্টার্নালের সাথে হস্তক্ষেপ করার সুযোগ দিন।


3

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

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

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


তবে এমন জায়গাগুলি রয়েছে যেখানে কেবল স্থির পদ্ধতি বলা যেতে পারে, যেমন আমার উদাহরণে এবং ক্রিস মার্শালের উদাহরণে
কিপ

হ্যাঁ কিপ করুন আপনার এবং ক্রিস উত্তরগুলি সঠিক। এগুলি সঠিক উত্তর হওয়ায় আমি তাদের বিষয়ে কোনও মন্তব্য করি নি। আমি কেবল ভুল উত্তর সম্পর্কে কথা বলেছি।
ভূষণ ভাঙলে

3

অভিজ্ঞতা থেকে আমি বলব যে এই জাতীয় ব্যক্তিগত পদ্ধতিগুলি বেশ সর্বজনীন এবং পুনরায় ব্যবহারযোগ্য হতে থাকে।

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

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


2

স্থিতিশীল / অ-স্থিতিশীল প্রশ্নটি নেমে আসে "সত্যই কি এই শ্রেণীর কোনও বস্তু ব্যবহার করা দরকার"?

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

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


2

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


এই সামান্য উত্তর, অন্যান্য উত্তরগুলির বোঝার নিচে সমাহিত, সত্যই বিষয়টিটির ছোঁয়া দেয়: শ্রেণি স্তরের কার্যকারিতা বনাম বস্তু স্তর কার্যকারিতা।
এলজেঞ্জো

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

আমি মন্তব্যটি লেখার সময় এটিতে একটি +1 দিয়েছিলাম।
এলজেনসো

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

1

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


নীচে আমার উত্তরটি দেখুন (এটি ইতিমধ্যে -3 এ থাকার পরে বিশ্লেষণ যুক্ত করেছি, সুতরাং এটি খুব বেশি দৃশ্যমান নয়)।
মাইকেল মায়ার্স

1

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

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


1

অফ-টপিক: আমি সহায়ক স্টাডেলগুলি / সহায়তা সহায়ক শ্রেণিতে কেবল স্ট্যাটিক পদ্ধতি সহ রাখি।

ব্যবহারের স্থানে সহায়তার পদ্ধতি থাকার সমস্যা ('একই শ্রেণি' পড়ুন) সমস্যাটি হ'ল লাইনের নীচে থাকা কেউই কেবল একই জায়গায় তাদের নিজস্ব সম্পর্কযুক্ত সহায়ক পদ্ধতি পোস্ট করতে পছন্দ করতে পারেন


-1: এসও কোনও মেসেজিং ফোরাম নয়। আপনি যথাযথ প্রশ্ন জিজ্ঞাসা করে আরও ভাল করবেন।
স্টু থম্পসন

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

1
class Whatever {

    public static varType myVar = initializeClassVariable();

    private static varType initializeClassVariable() {

        //initialization code goes here
    }
}

প্রাইভেট স্ট্যাটিক পদ্ধতির সুবিধা হ'ল যদি আপনার ক্লাস ভেরিয়েবলটি পুনরায় পুনর্নির্মাণের প্রয়োজন হয় তবে সেগুলি পরে পুনরায় ব্যবহার করা যেতে পারে।


1
  1. স্ট্যাটিক মডিফায়ার ব্যতীত আপনি বুঝতে পারবেন না যে পদ্ধতি বিশ্লেষণ ব্যতীত পদ্ধতিটি রাষ্ট্রহীন যা আপনি (পুনরায়) পদ্ধতিটি লেখার সময় সহজেই করা যেতে পারে।

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


0

আমি তাদের রাষ্ট্রহীন হিসাবে পতাকাঙ্কিত করার জন্য তাদের স্থির হিসাবে ঘোষণা করব।

রফতানি হয় না এমন ছোটখাটো ক্রিয়াকলাপের জন্য জাভাতে আরও ভাল ব্যবস্থা নেই, তাই আমি মনে করি যে ব্যক্তিগত স্ট্যাটিক গ্রহণযোগ্য।

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