পদ্ধতিগুলির স্থির আমদানির জন্য ভাল ব্যবহারের ক্ষেত্রে কী?


137

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

import static some.package.DA.*;
class BusinessObject {
  void someMethod() {
    ....
    save(this);
  }
} 

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

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

সুতরাং, স্থির আমদানির পদ্ধতিগুলি কখন তা বোঝায়? আপনি এটি কখন করেছেন? অযোগ্য কলগুলি যেভাবে দেখায় / পছন্দ করে?

সম্পাদনা: জনপ্রিয় মতামত মনে হয় যে স্থির-আমদানি পদ্ধতিগুলি যদি কেউ তাদেরকে বর্তমান শ্রেণির পদ্ধতি হিসাবে বিভ্রান্ত না করে। উদাহরণস্বরূপ java.lang.Math এবং java.awt.Coror থেকে পদ্ধতিগুলি। তবে যদি ABS এবং getAlpha দ্বিধাগ্রস্থ না হয় তবে আমি পড়ছি না কেন এমপ্লয়াই পড়ছে। প্রচুর প্রোগ্রামিং পছন্দ হিসাবে, আমি মনে করি এটিও একটি ব্যক্তিগত পছন্দের জিনিস।

আপনার প্রতিক্রিয়া বলার জন্য ধন্যবাদ, আমি প্রশ্নটি বন্ধ করছি।


2
: এখানে স্ট্যাটিক আমদানির খুব ভাল ব্যবহার হয় ibm.com/developerworks/library/j-ft18
intrepidis

1
@ mr5 সিনট্যাক্স হল import static, বৈশিষ্ট্যstatic import
মন্দ চলক

উত্তর:


150

এটি সূর্যের গাইডের কাছ থেকে যখন তারা বৈশিষ্ট্যটি প্রকাশ করেছিলেন (মূলত জোর দেওয়া):

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

( https://docs.oracle.com/javase/8/docs/technotes/guides/language/static-import.html )

আমি দুটি অংশ বিশেষভাবে কল করতে চাই:

  • স্থিতিশীল আমদানি কেবল তখনই ব্যবহার করুন যখন আপনি "উত্তরাধিকারের অপব্যবহার" করার লোভ দেখিয়েছিলেন। এই ক্ষেত্রে, আপনি কি বিজনেসঅবজেক্টের জন্য প্রলুব্ধ হবেন extend some.package.DA? যদি তা হয়, স্থিতিশীল আমদানি এটি হ্যান্ডেল করার একটি পরিষ্কার উপায় হতে পারে। যদি আপনি কখনই বাড়ানোর স্বপ্ন দেখে না থাকেন তবে some.package.DAসম্ভবত এটি স্থিতিশীল আমদানির দুর্বল ব্যবহার। টাইপ করার সময় কয়েকটি অক্ষর সংরক্ষণ করতে এটি ব্যবহার করবেন না।
  • পৃথক সদস্য আমদানি করুন। import static some.package.DA.saveপরিবর্তে বলুন DA.*। এটি এই আমদানি করা পদ্ধতিটি কোথা থেকে আসছে তা সন্ধান করা আরও সহজ করে তুলবে।

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


9
একমত। আমি মাঝে মাঝে স্থিতিশীল আমদানি ভেরি ব্যবহার করেছি যেখানে তারা কোডটি অনুসরণ করা বাস্তবে উল্লেখযোগ্যভাবে সহজ করেছে।
নীল কফফি

65

স্ট্যাটিক আমদানির জন্য আরেকটি যুক্তিসঙ্গত ব্যবহার JUnit 4. সাথে আছেন মত JUnit পদ্ধতি 'র পূর্ববর্তী সংস্করণে assertEqualsএবং failযেহেতু পরীক্ষা বর্গ বাড়ানো উত্তরাধিকারসূত্রে হয়েছে junit.framework.TestCase

// old way
import junit.framework.TestCase;

public class MyTestClass extends TestCase {
    public void myMethodTest() {
        assertEquals("foo", "bar");
    }
}

JUnit 4 এ, পরীক্ষার ক্লাসগুলির আর প্রসারিত করার প্রয়োজন নেই TestCaseএবং পরিবর্তে টীকাগুলি ব্যবহার করা যেতে পারে। তারপরে আপনি স্থিতিসমূহ থেকে আমদানি পদ্ধতিগুলি আমদানি করতে পারেন org.junit.Assert:

// new way
import static org.junit.Assert.assertEquals;

public class MyTestClass {
    @Test public void myMethodTest() {
        assertEquals("foo", "bar");
        // instead of
        Assert.assertEquals("foo", "bar");
    }
}

JUnit নথি এই ভাবে ব্যবহার করে।


4
আমি রাজি হই পরীক্ষার কেসগুলি সরলকরণ এমন এক জায়গা যেখানে অভিপ্রায়টি ভুল বোঝার সম্ভাবনা নেই।
বিল মিশেল

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

27

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

import static com.example.UtilityClassWithFrequentlyUsedMethods.myMethod;

public class MyClass {
    public void doSomething() {
        int foo= UtilityClassWithFrequentlyUsedMethods.myMethod();
        // can be written less verbosely as
        int bar = myMethod();
    }
}

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

আপনার এখনও এটি খুব অল্প পরিমাণে ব্যবহার করা উচিত এবং কেবল যদি আপনি নিজেকে আমদানিকৃত ফাইল থেকে বহুবার, বহুবার ব্যবহার করে দেখতে পান।

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


1
আমার প্রশ্নটি স্থির-আমদানি পদ্ধতিগুলি সম্পর্কে , ক্ষেত্রগুলি সম্পর্কে নয়।
দুর্ভাগ্য পরিবর্তনশীল

7
সম্ভবত UtilityClassWithFrequentlyUsedMethodsছোট করা প্রয়োজন।
স্টিভ কুও

5
@ স্টিভকুও অবশ্যই অভ্যন্তরীণ ফ্রেমটাইটেলপ্যানম্যাক্সিমাইজ বাটনের উইন্ডো নটফোকাস স্টেটের তুলনায় কম : পি
অনির্বাণ নাগ 'টিন্টিনমজ'

@ রব-হুরস্কা আমি ঘন ঘন ব্যবহার করার পরিকল্পনা করছি, আমি কি কোনও নতুন পদ্ধতি বা ফিল্ডে স্থির আমদানির পদ্ধতি বা ক্ষেত্রটি কেবল लपेटতে পারি না? এটি কি আমাকে স্থিতিশীলভাবে আমদানি না করার অনুমতি দেবে? যেমন: double myPI = Math.PI;এবং তারপরে আমি কেবল myPIপরিবর্তে উল্লেখ করতে পারি Math.PI
আব্দুল

@ আবদুল - হ্যাঁ, আপনি এটি করতে পারেন।
রব হুড়স্কা

14

আমি সম্মত হই যে এগুলি পাঠযোগ্যতার দৃষ্টিকোণ থেকে সমস্যাযুক্ত হতে পারে এবং অল্প পরিমাণে ব্যবহার করা উচিত। কিন্তু একটি সাধারণ স্থিতিশীল পদ্ধতি ব্যবহার করার সময় তারা আসলে পাঠ্যতা বৃদ্ধি করতে পারে। উদাহরণস্বরূপ, JUnit পরীক্ষা ক্লাসে, জাতীয় পদ্ধতিগুলি assertEqualsকোথা থেকে এসেছে তা স্পষ্ট। একই পদ্ধতি থেকে java.lang.Math


5
এবং ম্যাথ.আউন্ড (ডি) বনাম বৃত্তাকার (ডি) দেখার কি এত খারাপ?
স্টিভ কুও

5
@ স্টেভকুও - একই কারণে যে গণিতবিদরা সূত্রগুলি নিয়ে ম্যানিপুলেট করার সময় এক-বর্ণের পরিবর্তনশীল নাম ব্যবহার করেন: এমন অনেক সময় আসে যখন সামগ্রিক বিবরণের পাঠযোগ্যতার সাথে দীর্ঘ নামগুলি হস্তক্ষেপ করে। একাধিক ত্রিকোণমিতিক ফাংশন জড়িত একটি সূত্র বিবেচনা করুন। একটি সহজে করায়ত্ত গণিত সূত্র: sin x cos y + cos x sin y। জাভা হয়ে:Math.sin(x) * Math.cos(y) + Math.cos(x) * Math.sin(y)। পড়তে ভয়ঙ্কর।
টুলমেকারস্টেভ

@ টুলমেকারস্টেভ, এই কারণেই আমি usingসি ++ তে এত বেশি নির্দেশনা মিস করেছি : তারা স্থানীয় হতে পারে ।
ফ্রাঙ্কলিন ইউ

11

আমি মনে করি স্ট্যাটিক আমদানি রিডানড্যান্ট ক্লাসের নামগুলি মুছে ফেলতে সত্যই কার্যকর Arraysএবং এর মতো ব্যবহারের ক্লাস ব্যবহার করার সময় Assertions

নিশ্চিত না কেন তবে রস শেষ বাক্যটি এড়িয়ে গেছেন যা উল্লেখ করেছেন যে নথিভুক্তিতে তিনি উল্লেখ করছেন

যথাযথভাবে ব্যবহৃত হয়, স্থির আমদানি শ্রেণীর নামের পুনরাবৃত্তির বয়লারপ্লেটটি সরিয়ে আপনার প্রোগ্রামটিকে আরও পঠনযোগ্য করে তুলতে পারে।

মূলত এই ব্লগটি থেকে অনুলিপি করা হয়েছে: https://medium.com/alphadev- જોકેts/static-imports-are-great-but-undused-e805ba9b279f

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

পরীক্ষায় জোর

এটি সর্বাধিক সুস্পষ্ট মামলা যা আমি মনে করি আমরা সকলেই একমত হই

Assertions.assertThat(1).isEqualTo(2);

// Use static import instead
assertThat(1).isEqualTo(2);

উপযোগী ক্লাস এবং enums

কোড পড়তে সহজ করে তোলে যখন ব্যবহারের ক্লাস ব্যবহার করার সময় ক্লাসের নামটি অনেক ক্ষেত্রে মুছে ফেলা যায়

List<Integer> numbers = Arrays.asList(1, 2, 3);

// asList method name is enough information
List<Integer> numbers = asList(1, 2, 3);

java.Time প্যাকেজের কয়েকটি ক্ষেত্রে এটি ব্যবহার করা উচিত

// Get next Friday from now, quite annoying to read
LocalDate.now().with(TemporalAdjusters.next(DayOfWeek.FRIDAY));

// More concise and easier to read
LocalDate.now().with(next(FRIDAY));

কখন ব্যবহার করবেন না তার উদাহরণ

// Ok this is an Optional
Optional.of("hello world");

// I have no idea what this is 
of("hello world");

10

আমি এটি রঙের জন্য অনেক ব্যবহার করি।

static import java.awt.Color.*;

রঙগুলি অন্য কোনও কিছুর সাথে বিভ্রান্ত হবে এমনটি খুব সম্ভবত।


1
এটি আমি দেখেছি যে সেরা ব্যবহারের ক্ষেত্রে এটি পুরানো JUnit / Hamcrest / TestNG এর চেয়ে আলাদা।
কেভিনারপে

3

আমি জাভা সহ ওপেনজিএল ব্যবহার করার সময় স্থিতিশীল আমদানি ব্যবহারের পরামর্শ দিই , যা "ইউটিলিটি ক্লাসের ধ্রুবকের ভারী ব্যবহার" এর মধ্যে পড়ে এমন একটি ব্যবহার-মামলা is বিভাগের

এটা বিবেচনা করুন

import static android.opengl.GLES20.*;

আপনাকে মূল সি কোড পোর্ট করতে এবং পাঠযোগ্য কিছু লিখতে দেয় যেমন:

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, texture);
glUniform1i(samplerUniform, 0);
glBindBuffer(GL_ARRAY_BUFFER, vtxBuffer);
glVertexAttribPointer(vtxAttrib, 3, GL_FLOAT, false, 0, 0);

পরিবর্তে সেই সাধারণ ব্যাপক কদর্যতা:

GLES20.glActiveTexture(GLES20.GL_TEXTURE0);
GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, texture);
GLES20.glUniform1i(samplerUniform, 0);
GLES20.glBindBuffer(GLES20.GL_ARRAY_BUFFER, vtxBuffer);
GLES20.glVertexAttribPointer(vtxAttrib, 3, GLES20.GL_FLOAT, false, 0, 0);

2

স্থির আমদানি জাভাটির একমাত্র "নতুন" বৈশিষ্ট্য যা আপনি কখনও উল্লিখিত সমস্যার কারণে আমি কখনও ব্যবহার করি নি এবং কখনও ব্যবহার করার ইচ্ছা করি না।


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

2

সি / সি ++ থেকে জাভাতে গণিতের ভারী কোড পোর্ট করার সময় আমি 'আমদানি স্ট্যাটিক জাভা.লং.ম্যাথ।' ব্যবহার করি। গণিতের পদ্ধতিগুলি 1 থেকে 1 এর মানচিত্র করে এবং বর্গের নাম যোগ্যতা ছাড়াই পোর্টড কোডকে আলাদা করে তোলে।


2

আমি ইউটিলিটি ক্লাস ব্যবহার করার সময় এটি খুব সুবিধাজনক বলে মনে করেছি।

উদাহরণস্বরূপ, ব্যবহারের পরিবর্তে: if(CollectionUtils.isNotEmpty(col))

পরিবর্তে আমি করতে পারি:

import static org.apache.commons.collections.CollectionUtils.isNotEmpty;
if(isNotEmpty(col))

আমি যখন আমার কোডটিতে একাধিকবার এই ইউটিলিটিটি ব্যবহার করি তখন কোন IMO কোডের পাঠযোগ্যতা বৃদ্ধি করে।


2

ইউনিট পরীক্ষাগুলির বিষয়ে কথা বলা: বেশিরভাগ লোক মজাদার ফ্রেমওয়ার্কগুলি সরবরাহ করে এমন বিভিন্ন স্থিতিশীল পদ্ধতির জন্য স্থির আমদানি ব্যবহার করে , যেমন when()বা verify()

import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

এবং অবশ্যই, যখন assertThat()এটির ব্যবহার করছেন এবং কেবলমাত্র আপনার দৃ should়ভাবে দাবি করা উচিত তখন এটি হ্যামস্ট্রেষ্টের প্রয়োজনীয় ম্যাচচারগুলি স্থিতিশীলভাবে আমদানি করতে কার্যকর হবে:

import static org.hamcrest.Matchers.*;

1

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

একটি উদাহরণ: কোড যা জাভা.লং.ম্যাথের একাধিক উল্লেখ জড়িত

আরেকটি: একটি এক্সএমএল নির্মাতা শ্রেণি যেখানে প্রতিটি রেফারেন্সের জন্য ক্লাসের নাম প্রিফেন্ড করা কাঠামোটি তৈরি করা লুকিয়ে রাখে


1

আমি মনে করি স্থির আমদানি গেটেক্সটেক্স-স্টাইলে এনএলএসের জন্য ঝরঝরে।

import static mypackage.TranslatorUtil._;

//...
System.out.println(_("Hello world."));

এটি উভয়ই স্ট্রিংটিকে একটি স্ট্রিং হিসাবে চিহ্নিত করে যা উত্তোলন করতে হবে এবং তার অনুবাদটির সাথে স্ট্রিংটি প্রতিস্থাপনের জন্য একটি সহজ এবং পরিষ্কার উপায় সরবরাহ করে।


1

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

public class AngleUtils {

    public static final float _ZERO = 0.0f;
    public static final float _PI   = 3.14f;

    public static float _angleDiff(float angle1, float angle2){

    }

    public static float _addAngle(float target, float dest){

    }
}

এই ক্ষেত্রে স্থিতিশীল আমদানি স্বচ্ছতা সরবরাহ করে এবং কোড কাঠামো আমার কাছে আরও মার্জিত দেখায়:

import static AngleUtils.*;

public class TestClass{

    public void testAngles(){

        float initialAngle = _ZERO;
        float angle1, angle2;
        _addAngle(angle1, angle2);
    }
}

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


পুনরায় নামকরণের পরামর্শের জন্য ধন্যবাদ। বিটিডাব্লু, সামনের একটি আন্ডারস্কোর প্রথাগতভাবে কিছু পরিবেশে ব্যক্তিগত পদ্ধতি / ক্ষেত্রগুলির নামকরণের জন্য ব্যবহৃত হয়। আমি একটি সংশোধিত কনভেনশন বিবেচনা করছি, যেমন আমার কাছে H_থাকা কোনও Helperইউটিলিটি ক্লাস থেকে আমদানির C_জন্য Common, বা এর U_জন্য বা এর জন্য Utility। বিকল্পভাবে, আমি এই বহুল ব্যবহৃত ক্লাসগুলির জন্য এক বা দুটি চরিত্রের শ্রেণিটির নাম ব্যবহার করার বিষয়টি বিবেচনা করেছি, তবে উদ্বিগ্ন ছিল যেগুলি কখনও কখনও স্থানীয় নামের সাথে বিরোধে লিপ্ত হয় - বড় হাতের পদ্ধতি পদ্ধতির নামের সাথে কিছু উত্তরাধিকার কোড থাকে।
টুলমেকারস্টেভ

-1

আপনার সেগুলি ব্যবহার করা উচিত যখন:

  • আপনি switchএনাম মান সহ একটি বিবৃতি ব্যবহার করতে ইচ্ছুক
  • আপনি আপনার কোড বুঝতে অসুবিধা করতে চান

9
এটি সত্য নয়। (1) আপনি এনাম কনস্ট্যান্টগুলি কোনও স্ট্যাটিক আমদানি ছাড়াই নিখুঁতভাবে ব্যবহার করতে পারেন। (২) স্থিতিশীল আমদানিগুলি বলুন, ইউনাইট অ্যাসেট ক্লাসের পদ্ধতিগুলি বেল হিসাবে পরিষ্কার। "assertTrue (...)" "Assert.assertTrue (...)" এর মতোই পঠনযোগ্য, সম্ভবত আরও।
অ্যালান ক্রুয়েগার

5
আপনার যদি 500 লাইনের শ্রেণিতে 5 টি স্ট্যাটিক আমদানি থাকে তবে পদ্ধতিগুলি কোথা থেকে এসেছে তা বলা খুব শক্ত।
davetron5000 23

4
আপনি যখন নিজের কোডটি বোঝা মুশকিল করতে চান তখন জন্য +1 :)
দুর্বল পরিবর্তনশীল

-5

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


13
আপনি নিয়মিত আমদানির কথা ভাবছেন। স্ট্যাটিক আমদানি আপনাকে ক্লাসের সদস্যদের কোনও ক্লাসের নাম না দিয়ে যোগ্যতার জন্য উল্লেখ করতে দেয়, যেমন স্ট্যাটিক আমদানি java.lang.s systemm.out; out.println ( "foo বিন্যাস"); // System.out.println ("foo") এর পরিবর্তে;
স্ক।

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