জাভাতে ধ্রুবকগুলি কার্যকর করার সর্বোত্তম উপায় কী? [বন্ধ]


372

আমি এরকম উদাহরণ দেখেছি:

public class MaxSeconds {
   public static final int MAX_SECONDS = 25;
}

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



উত্তর:


403

এটি পুরোপুরি গ্রহণযোগ্য, সম্ভবত এমনকি মানক।

(public/private) static final TYPE NAME = VALUE;

TYPEটাইপটি কোথায় , NAMEস্পেসগুলির জন্য আন্ডারস্কোরযুক্ত সমস্ত ক্যাপের নাম এবং VALUEএটি ধ্রুবক মান;

আমি আপনার প্রতিরোধীদের তাদের নিজস্ব শ্রেণি বা ইন্টারফেসে না রাখার জন্য অত্যন্ত পরামর্শ দিচ্ছি।

পার্শ্ব নোট হিসাবে: চূড়ান্ত হিসাবে ঘোষিত এবং পরিবর্তনীয় পরিবর্তনীয় এখনও পরিবর্তন করা যেতে পারে; যাইহোক, ভেরিয়েবলটি কখনই আলাদা কোনও বস্তুতে নির্দেশ করতে পারে না।

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

public static final Point ORIGIN = new Point(0,0);

public static void main(String[] args){

    ORIGIN.x = 3;

}

এটি আইনী এবং ORIGINতারপরে (3, 0) পয়েন্ট হবে।


19
আপনি এমনকি 'স্ট্যাটিক ম্যাক্স সেকেন্ডস আমদানি করতে পারেন MA MAX_SECONDS;' তাই আপনি না এটি MaxSeconds.MAX_SECONDS বানান
হারুন Maenpaa

23
আমদানি স্থিতিশীল সম্পর্কে পূর্ববর্তী মন্তব্যটি কেবল জাভা 5+ এ প্রযোজ্য। কেউ কেউ মনে করেন যে লম্বা কোডটি পড়ার সময়, ধ্রুবকটি কোথা থেকে এসেছিল তা শর্টহ্যান্ড সম্ভাব্য বিভ্রান্তির উপযুক্ত নয়, ম্যাক্স সেকেন্ডস MA ম্যাক্স_সেকেন্ডস অনুসরণ করা এবং আমদানির দিকে নজর দেওয়া আরও সহজ হতে পারে।
MetroidFan2002

5
যেহেতু আপনি জেঞ্জুয়ে যেমন দেখিয়েছেন ওজেটটেকটি পরিবর্তন করতে পারেন, আপনার কনস্ট্যান্টগুলি পরিবর্তনযোগ্য অবজেক্ট বা কেবল সরল আদিম / স্ট্রিং হলে সবচেয়ে ভাল।
মার্কোস্পেরির

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

3
@jjnguy আপনি ভুল নন, তবে আমি যদি কেবল উত্তর এবং আপনার উত্তরটির প্রথম দুটি লাইন পড়ে থাকি তবে আমি এই ধারণাটি বদ্ধ হয়ে থাকব যে "একটি কনস্ট্যান্ট ক্লাস" "পুরোপুরি গ্রহণযোগ্য, সম্ভবত এমনকি মানক"। যে ধারণা হয় ভুল।
Zach Lysobey

235

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

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

12
সম্পূর্ণ সম্মত ... এটি বড় প্রকল্পগুলির জন্য শাস্ত্রীয় বিরোধী-প্যাটার্ন হিসাবে নথিভুক্ত করা যেতে পারে।
দাস

30
বিষয় ছাড়াই, তবে ... জেনেরিক্স অবশ্যই নিখুঁত নয়, তবে আমি মনে করি আপনি জাভা 5 এর একটি দরকারী বৈশিষ্ট্য হিসাবে তাদের জন্য একটি খুব ভাল কেস তৈরি করতে পারেন :)
মার্টিন ম্যাকএন্ট্রি

3
@ ŁukaszL। প্রশ্নটি সত্যই মতামত ভিত্তিক (যখনই "সেরা" উত্থাপিত হয়, এটি সাধারণত মতামতের বিষয়), সুতরাং উত্তরটি এই প্রশ্নের একটি বৈধ উত্তর। আমি কী উত্তর দিয়েছি (হ্যাঁ, আমি বিশ্বাস করি , তাই হ্যাঁ এটি একটি মতামত, কারণ আবার সময়ের সাথে "সেরা" পরিবর্তন হয় এবং সাধারণত মতামত ভিত্তিক হয়) জাভাতে ধ্রুবকগুলি বাস্তবায়নের সর্বোত্তম উপায়।
MetroidFan2002

1
উপরের কোনও বিকল্প আপনাকে সত্যিকারের গ্লোবাল ভেরিয়েবল দেয় না। আমার যদি এমন কিছু থাকে যা সর্বত্র ব্যবহৃত হয় তবে এনাম না হয়? আমি কি কেবল একটি জিনিসের জন্য এনাম তৈরি করব?
মার্কথেগ্রিয়া

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

120

কেবল ধ্রুবককে ধরে রাখার জন্য ইন্টারফেস ব্যবহার করা ( জশ ব্লচের নামকরণে ধ্রুব ইন্টারফেসের নিদর্শন) এটি একটি খারাপ অভ্যাস । জোশ যা পরামর্শ দেয় তা এখানে:

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

উদাহরণ:

// Constant utility class
package com.effectivejava.science;
public class PhysicalConstants {
    private PhysicalConstants() { }  // Prevents instantiation

    public static final double AVOGADROS_NUMBER   = 6.02214199e23;
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    public static final double ELECTRON_MASS      = 9.10938188e-31;
}

নামকরণের সম্মেলন সম্পর্কে:

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


23
আপনি যদি কিছু খারাপ অভ্যাস বলতে চলেছেন তবে সম্ভবত আপনি কেন এটি মনে করছেন তা ব্যাখ্যা করা উচিত?
গ্লেনস

14
এটি পুরানো পোস্ট তবে abstractপ্রাইভেট কনস্ট্রাক্টরের পরিবর্তে ক্লাসের জন্য স্বরলিপি ব্যবহার করা আরও ভাল ।
এক্সট্রিম বাইকার

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

7
@ এক্সট্রিম বাইকার abstractএকটি প্রাইভেট কনস্ট্রাক্টরের পরিবর্তে ক্লাস চিহ্নিত করা পুরোপুরি ইনস্ট্যান্টেশন প্রতিরোধ করে না, কারণ এটি একটি সাবক্লাস করে সাবক্লাসটি ইনস্ট্যান্ট করতে পারে (এমনটি করা ভাল ধারণা নয়, তবে এটি সম্ভব)) @ টলমেকারস্টেভ আপনি একটি প্রাইভেট কনস্ট্রাক্টরের সাথে ক্লাস সাবক্লাস করতে পারবেন না (কমপক্ষে কোনও বড় খারাপ হ্যাক ছাড়া নয়), কারণ সাবক্লাসটির নির্মাণকারীকে তার সুপারক্লাসের (এখন প্রাইভেট) কনস্ট্রাক্টর কল করতে হবে। সুতরাং, এটি চিহ্নিত finalকরা অপ্রয়োজনীয় (তবে সম্ভবত আরও স্পষ্টত)।
এই

3
কেবল ধ্রুবকগুলি ধরে রাখতে ক্লাস ব্যবহার করা আরও খারাপ। আপনি যদি কখনই সেই শ্রেণীর কোনও অবজেক্ট তৈরি করতে না চান তবে আপনি নিয়মিত ক্লাসটি প্রথম স্থানে কেন ব্যবহার করেন ?
ম্যাক্সজুম 21

36

কার্যকর জাভাতে (২ য় সংস্করণ), এটি প্রস্তাবিত হয় যে আপনি ধ্রুবকগুলির জন্য স্ট্যাটিক ইন্টের পরিবর্তে এনামগুলি ব্যবহার করুন।

জাভাতে এনামগুলিতে এখানে ভাল লেখার ব্যবস্থা রয়েছে: http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

দ্রষ্টব্য যে নিবন্ধের শেষে প্রশ্ন উত্থাপিত হয়:

সুতরাং আপনি কখন enums ব্যবহার করা উচিত?

এর উত্তর সহ:

যে কোনও সময় আপনার ধ্রুবকের একটি নির্দিষ্ট সেট প্রয়োজন


21

কেবল একটি ইন্টারফেস ব্যবহার করা এড়িয়ে চলুন:

public interface MyConstants {
    String CONSTANT_ONE = "foo";
}

public class NeddsConstant implements MyConstants {

}

এটি লোভনীয়, তবে এনক্যাপসুলেশন লঙ্ঘন করে এবং শ্রেণি সংজ্ঞাগুলির পার্থক্যকে ঝাপসা করে।


1
প্রকৃতপক্ষে স্থিতিশীল আমদানি অনেক বেশি পছন্দসই।
অ্যারন মেনপাআ

1
এই অনুশীলনটি ইন্টারফেসগুলির একটি অদ্ভুত ব্যবহার, যা কোনও শ্রেণীর সরবরাহিত পরিষেবাদিগুলি বর্ণনা করার উদ্দেশ্যে।
রাফা রোমেরো

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

এটি সত্য ... এটি এনক্যাপসুলেশন লঙ্ঘন করছে, আমি ব্যবহার করতে পছন্দ করি চূড়ান্ত কনস্ট্যান্ট ক্লাসটি যা ইন্টারফেস বা এনামের চেয়ে বেশি অবজেক্ট ওরিয়েন্টালি ও পছন্দনীয় দেখায় । দ্রষ্টব্য: এনড্রয়েডের প্রয়োজন না হলে এনাম এড়ানো যেতে পারে ।
CoDe

19

আমি নিম্নলিখিত পদ্ধতির ব্যবহার:

public final class Constants {
  public final class File {
    public static final int MIN_ROWS = 1;
    public static final int MAX_ROWS = 1000;

    private File() {}
  }

  public final class DB {
    public static final String name = "oups";

    public final class Connection {
      public static final String URL = "jdbc:tra-ta-ta";
      public static final String USER = "testUser";
      public static final String PASSWORD = "testPassword";

      private Connection() {}
    }

    private DB() {}
  }

  private Constants() {}
}

তুলনায়, উদাহরণস্বরূপ, আমি Constants.DB.Connection.URLধ্রুবক পেতে ব্যবহার করি । এটি আমার জন্য আরও "অবজেক্ট ওরিয়েন্টালি" দেখায়।


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

3
@ টুলমেকারস্টেভ তবে একাধিক ক্লাস ব্যবহার করতে পারে এমন সাধারণ ধ্রুবকগুলির সম্পর্কে কী? উদাহরণস্বরূপ, শৈলী, ওয়েব পরিষেবাদি url, ইত্যাদি ...?
ড্যানিয়েল গোমেজ রিকো

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

17

পৃথক শ্রেণিতে স্থির চূড়ান্ত স্থিরতা তৈরি করা আপনাকে সমস্যার মধ্যে ফেলতে পারে। জাভা সংকলক আসলে এটি সর্বোত্তম করে তুলবে এবং ধ্রুবকের আসল মান যে কোনও শ্রেণিতে রেফারেন্স দেয় place

আপনি যদি পরে 'কনস্ট্যান্টস' শ্রেণিটি পরিবর্তন করেন এবং অন্যান্য শ্রেণিতে যে ক্লাসটি উল্লেখ করা হয় তার জন্য আপনি কঠোর পুনরায় সংকলন না করেন তবে আপনি পুরানো এবং নতুন মানগুলির সংমিশ্রণটি ব্যবহার করবেন।

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


এই দুর্দান্ত ক্যাভিয়েটের জন্য +1। (যদি আপনি এটি স্থায়ী স্থিরতার গ্যারান্টি দিতে না পারেন তবে তার পরিবর্তে একজন গিটারকে বিবেচনা করুন, যেহেতু বড়_প্যান্ট_হর্স উল্লেখ করেছেন C) একইভাবে সি # তে কনস্টের সাথে প্রযোজ্য: এমএসডিএন.মাইক্রোসফটকম /en-us/library/e6w8fe1b.aspx
জোন কম্বস

13

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

পরিবর্তে, ধ্রুবকগুলি তাদের "মালিকানাধীন" শ্রেণিতে প্রবেশ করা উচিত। আপনার কি TIMEOUT নামে ধ্রুবক বলা আছে? এটি সম্ভবত আপনার যোগাযোগ () বা সংযোগ () শ্রেণিতে যেতে হবে। MAX_BAD_LOGINS_PER_HOUR? ব্যবহারকারী () এ যায়। এবং তাই এবং তাই ঘোষণা.

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


এবং অবশ্যই, আপনি কখনই একাধিক শ্রেণীর কাছ থেকে ধ্রুবক অ্যাক্সেস করতে বা ক্লাসের শীর্ষে থাকা বিশৃঙ্খলা এড়াতে চাইবেন না।
অরবফিশ

6

এটিই সঠিক পথে।

সাধারণত ধ্রুবকগুলি পৃথক "ধ্রুবক" শ্রেণিতে রাখা হয় না কারণ তারা আবিষ্কারযোগ্য নয়। ধ্রুবক যদি বর্তমান বর্গের সাথে সম্পর্কিত হয় তবে তাদের সেখানে রেখে দেওয়া পরবর্তী বিকাশকারীকে সহায়তা করে।



5

আমি ধ্রুবকগুলির চেয়ে গেটার ব্যবহার করতে পছন্দ করি। এই গিটারগুলি ধ্রুবক মানগুলি যেমন, যেমন ফেরত দিতে পারে public int getMaxConnections() {return 10;}তবে ধ্রুবকের যে কোনও কিছু প্রয়োজন হিসাবে পাওয়া যায়।

একটি সুবিধা হ'ল যদি আপনার প্রোগ্রামটি ধ্রুবককে ছাড়িয়ে যায় - আপনি দেখতে পান এটির কনফিগার করার দরকার আছে - আপনি কীভাবে ধ্রুবককে ফিরে আসেন তা পরিবর্তন করতে পারেন।

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


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

5

আমি একমত যে একটি ইন্টারফেস ব্যবহার করা উপায় না। ব্ল্যাচের কার্যকর জাভাতেও এই প্যাটার্নটি এড়িয়ে চলার নিজস্ব আইটেম (# 18) রয়েছে

ব্লচ ধ্রুবক ইন্টারফেস প্যাটার্নের বিরুদ্ধে একটি যুক্তি দেয় যে ধ্রুবকগুলির ব্যবহার একটি বাস্তবায়ন বিশদ, তবে সেগুলি ব্যবহারের জন্য একটি ইন্টারফেস প্রয়োগ করা আপনার এক্সপোর্টেড এপিআইতে সেই প্রয়োগের বিশদটি প্রকাশ করে।

দ্য public|private static final TYPE NAME = VALUE;প্যাটার্ন একটি ধ্রুবক প্রকাশক একটি ভাল উপায়। ব্যক্তিগতভাবে, আমি মনে করি আপনার সমস্ত ধ্রুবককে আলাদা করে আলাদা ক্লাস করা এড়ানো ভাল, তবে ব্যক্তিগত পছন্দ এবং স্টাইল বাদে আমি কখনও এটি না করার কারণ দেখিনি।

যদি আপনার ধ্রুবকগুলি একটি গণনা হিসাবে ভাল মডেল করা যায় তবে এনাম বিবেচনা করুন কাঠামো 1.5 বা তার পরে উপলব্ধ ।

আপনি যদি 1.5 এর আগে কোনও সংস্করণ ব্যবহার করে থাকেন তবে সাধারণ জাভা ক্লাস ব্যবহার করে আপনি এখনও টাইপসিয়েফের গণনাগুলি বন্ধ করতে পারেন। ( এই বিষয়ে আরও তথ্যের জন্য এই সাইটটি দেখুন )।


কিছু কনস্ট্যান্ট কোনও এপিআই কল করতে ব্যবহৃত হতে পারে। উদাহরণস্বরূপ, ইন্টারফেস org.springframework.transaction.TransactionDifinition দেখুন। এটির কাছে PROPAGATION_REQUIRED = 0 এর মতো ধ্রুবকের একটি তালিকা রয়েছে;
বোরজাব

আমি জানি এটি পুরানো, তবে ব্লচের কার্যকর জাভাটির লিঙ্কটি নষ্ট হয়ে গেছে। দয়া করে আপনি "ইন্টারফেস ব্যবহার করে যাওয়ার উপায় নয়" এমন সমর্থন করে অন্য কোনও রেফারেন্স সরবরাহ করতে পারেন?
Nelda.techspiress

4

উপরের মন্তব্যের উপর ভিত্তি করে আমি মনে করি এটি পুরাতন ফ্যাশনযুক্ত গ্লোবাল ধ্রুবক শ্রেণীর (পাবলিক স্ট্যাটিক চূড়ান্ত ভেরিয়েবলগুলি থাকা) এর এনামের মতো সমতুল্যভাবে এভাবে পরিবর্তন করার জন্য এটি একটি ভাল পদ্ধতি:

public class Constants {

    private Constants() {
        throw new AssertionError();
    }

    public interface ConstantType {}

    public enum StringConstant implements ConstantType {
        DB_HOST("localhost");
        // other String constants come here

        private String value;
        private StringConstant(String value) {
            this.value = value;
        }
        public String value() {
            return value;
        }
    }

    public enum IntConstant implements ConstantType {
        DB_PORT(3128), 
        MAX_PAGE_SIZE(100);
        // other int constants come here

        private int value;
        private IntConstant(int value) {
            this.value = value;
        }
        public int value() {
            return value;
        }
    }

    public enum SimpleConstant implements ConstantType {
        STATE_INIT,
        STATE_START,
        STATE_END;
    }

}

সুতরাং আমি তাদের পছন্দ মত উল্লেখ করতে পারেন:

Constants.StringConstant.DB_HOST

4
কেন? কিভাবে এই উন্নতি হয়? প্রতিটি রেফারেন্স এখন জটিল (কনস্ট্যান্টস স্ট্রিংকন্সট্যান্ট ডট ওয়ে ওয়েভ)। আইএমএইচও, আপনি এখানে একগাদা রাস্তায় যাচ্ছেন।
টুলমেকারস্টেভ

3

একটি ভাল অবজেক্ট ওরিয়েন্টেড ডিজাইনের জন্য অনেকগুলি প্রকাশ্যে উপলভ্য ধ্রুবকের প্রয়োজন হবে না। বেশিরভাগ ধ্রুবককে শ্রেণিতে আবদ্ধ করা উচিত যা তাদের কাজটি করার জন্য প্রয়োজন do


1
বা কনস্ট্রাক্টরের মাধ্যমে সেই ক্লাসে ইনজেকশন দেওয়া।
ডাব্লুডাব্লু

2

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

public, so that they are accessible from everywhere
static, so that they can be accessed without any instance. Since they are constants it
  makes little sense to duplicate them for every object.
final, since they should not be allowed to change

আমি কোনও কনসেন্টস অ্যাক্সেসর / অবজেক্টের জন্য কোনও ইন্টারফেস ব্যবহার করব না কারণ সাধারণত ইন্টারফেসগুলি বাস্তবায়িত হবে বলে আশা করা যায়। এটি কি মজার লাগবে না:

String myConstant = IMyInterface.CONSTANTX;

পরিবর্তে আমি কয়েকটি ছোট ব্যবসায়ের উপর ভিত্তি করে কয়েকটি ভিন্ন উপায়ে বেছে নেব এবং তাই এটি আপনার প্রয়োজনের উপর নির্ভর করে:

1.  Use a regular enum with a default/private constructor. Most people would define 
     constants this way, IMHO.
  - drawback: cannot effectively Javadoc each constant member
  - advantage: var members are implicitly public, static, and final
  - advantage: type-safe
  - provides "a limited constructor" in a special way that only takes args which match
     predefined 'public static final' keys, thus limiting what you can pass to the
     constructor

2.  Use a altered enum WITHOUT a constructor, having all variables defined with 
     prefixed 'public static final' .
  - looks funny just having a floating semi-colon in the code
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you still have to put explicit 'public static final' before each variable
  - drawback: not type-safe
  - no 'limited constructor'

3.  Use a Class with a private constructor:
  - advantage: you can JavaDoc each variable with an explanation
  - drawback: you have to put explicit 'public static final' before each variable
  - you have the option of having a constructor to create an instance
     of the class if you want to provide additional functions related
     to your constants 
     (or just keep the constructor private)
  - drawback: not type-safe

4. Using interface:
  - advantage: you can JavaDoc each variable with an explanation
  - advantage: var members are implicitly 'public static final'
  - you are able to define default interface methods if you want to provide additional
     functions related to your constants (only if you implement the interface)
  - drawback: not type-safe

2

জাভাতে ধ্রুবকগুলি কার্যকর করার সর্বোত্তম উপায় কী?

একটি উপায় যা আমাদের সত্যই এড়ানো উচিত : ধ্রুবকগুলির সংজ্ঞা দেওয়ার জন্য ইন্টারফেস ব্যবহার করা।

ধ্রুবকদের ঘোষণার জন্য বিশেষত একটি ইন্টারফেস তৈরি করা সবচেয়ে খারাপ জিনিস: এটি ইন্টারফেসগুলি কেন ডিজাইন করা হয়েছিল তার কারণটি হারায়: পদ্ধতি নির্ধারণের পদ্ধতি (গুলি)।

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


সরল করতে, আমাদের কাছে 4 টি বৈধ পন্থা রয়েছে

সঙ্গে static final String/Integerক্ষেত্র:

  • 1) এমন একটি বর্গ ব্যবহার করে যা ভিতরে স্থির ঘোষণা দেয় তবে কেবল তা নয়।
  • 1 বৈকল্পিক) কেবলমাত্র ধ্রুবকগুলি ঘোষণার জন্য উত্সর্গীকৃত একটি শ্রেণী তৈরি করা।

সহ Java 5 enum:

  • 2) সম্পর্কিত উদ্দেশ্যে শ্রেণিতে এনাম ঘোষণা করা (সুতরাং নেস্টেড শ্রেণি হিসাবে)।
  • 2 বৈকল্পিক) স্ট্যান্ড স্টোন ক্লাস হিসাবে এনাম তৈরি করা (যাতে তার নিজস্ব বর্গের ফাইলে সংজ্ঞায়িত)।

টিএলডিআর: সবচেয়ে ভাল উপায় কোনটি এবং ধ্রুবকগুলি কোথায় অবস্থিত?

বেশিরভাগ ক্ষেত্রেই, enum উপায় সম্ভবত চেয়ে তীক্ষ্ণ স্বরূপ হয় static final String/Integerউপায় এবং ব্যক্তিগতভাবে আমি মনে করি যে static final String/Integerপথ ব্যবহার করা উচিত শুধুমাত্র যদি আমরা ভাল কারণ enums ব্যবহার করবেন করতে হবে।
এবং যেখানে আমাদের ধ্রুবক মানগুলি ঘোষণা করা উচিত সে সম্পর্কে ধারণাটি হ'ল স্থিত মানগুলির সাথে একটি নির্দিষ্ট এবং দৃ strong় কার্যকরী একাত্মতার মালিকানাধীন একক বিদ্যমান বর্গ রয়েছে কিনা তা অনুসন্ধান করা। যদি আমরা এই জাতীয় শ্রেণি খুঁজে পাই তবে আমাদের এটি ধ্রুবক ধারক হিসাবে ব্যবহার করা উচিত । অন্যথায়, ধ্রুবকটি কোনও একটি বিশেষ শ্রেণীর সাথে সম্পর্কিত হওয়া উচিত।


static final String/ static final Integerবনামenum

Enums ব্যবহার সত্যিই দৃ strongly়ভাবে বিবেচনা করার একটি উপায়।
এনামগুলিতে Stringবা Integerধ্রুবক ক্ষেত্রের উপরে দুর্দান্ত সুবিধা রয়েছে ।
তারা একটি শক্তিশালী সংকলনের সীমাবদ্ধতা সেট করে। আপনি যদি এনামকে প্যারামিটার হিসাবে গ্রহণ করে এমন কোনও পদ্ধতি নির্দিষ্ট করে থাকেন তবে আপনি কেবল এনাম শ্রেণিতে (বা নাল) সংজ্ঞায়িত এনুম মানটি পাস করতে পারেন।
স্ট্রিং এবং পূর্ণসংখ্যার সাথে আপনি এগুলি যে কোনও মান সম্মত প্রকারের সাথে প্রতিস্থাপন করতে পারেন এবং সংকলনটি ঠিক হবে যদি মান static final String/ / এ সংজ্ঞায়িত ধ্রুবক নাও হয় তবেstatic final Integer ক্ষেত্রগুলিতে ।

উদাহরণস্বরূপ, static final Stringক্ষেত্র হিসাবে শ্রেণিতে সংজ্ঞায়িত দুটি স্থির নীচে :

public class MyClass{

   public static final String ONE_CONSTANT = "value";
   public static final String ANOTHER_CONSTANT = "other value";
   . . .
}

এখানে এমন একটি পদ্ধতি যা প্রত্যাশা করে যে এইগুলির মধ্যে একটির প্যারামিটার হিসাবে রয়েছে:

public void process(String constantExpected){
    ...    
}

আপনি এটি এইভাবে প্রার্থনা করতে পারেন:

process(MyClass.ONE_CONSTANT);

অথবা

process(MyClass.ANOTHER_CONSTANT);

তবে কোনও সংকলনের সীমাবদ্ধতা আপনাকে এটি এইভাবে প্রার্থনা করতে বাধা দেয় না:

process("a not defined constant value");

আপনি কেবল রানটাইম এ ত্রুটি থাকতে হবে এবং কেবল যদি আপনি একবারে সংক্রমণিত মানটি পরীক্ষা করে থাকেন।

এনামের সাথে, চেকগুলি প্রয়োজন হয় না কারণ ক্লায়েন্ট কেবল এনাম প্যারামিটারে একটি এনাম মান পাস করতে পারে।

উদাহরণস্বরূপ, এখানে এনাম শ্রেণিতে সংজ্ঞায়িত দুটি মান (বাক্সের বাইরে ধ্রুবক):

public enum MyEnum {

    ONE_CONSTANT("value"), ANOTHER_CONSTANT(" another value");

    private String value;

    MyEnum(String value) {
       this.value = value;
    }
         ...
}

এখানে এমন একটি পদ্ধতি যা প্রত্যাশা করে যে এইগুলির মধ্যে একটি এনাম মানগুলি প্যারামিটার হিসাবে থাকবে:

public void process(MyEnum myEnum){
    ...    
}

আপনি এটি এইভাবে প্রার্থনা করতে পারেন:

process(MyEnum.ONE_CONSTANT);

অথবা

process(MyEnum.ANOTHER_CONSTANT);

তবে সংকলন কখনই আপনাকে এটিকে চালিত হতে দেবে না:

process("a not defined constant value");

আমরা কোথায় ধ্রুবক ঘোষণা করব?

যদি আপনার অ্যাপ্লিকেশনটিতে একটি একক বিদ্যমান বর্গ থাকে যা স্থির মানগুলির সাথে একটি নির্দিষ্ট এবং শক্তিশালী কার্যকরী সংহতির মালিক হয়, তবে 1) এবং 2) আরও স্বজ্ঞাত বলে মনে হয়।
সাধারণত, ধ্রুবকগুলির ব্যবহারটি সহজ করে দেয় যদি এগুলি প্রধান শ্রেণিতে ঘোষণা করা হয় যা এগুলি চালিত করে বা এর নাম খুব স্বাভাবিক থাকে তবে অনুমান করা যায় যে আমরা এটি ভিতরে পেয়ে যাব।

উদাহরণস্বরূপ জেডিকে লাইব্রেরিতে, সূচকীয় এবং পাই ধ্রুবক মানগুলি এমন একটি শ্রেণিতে ঘোষিত হয় যা কেবল ধ্রুবক ঘোষণাই না ( java.lang.Math) ঘোষণা করে ।

   public final class Math {
          ...
       public static final double E = 2.7182818284590452354;
       public static final double PI = 3.14159265358979323846;
         ...
   }

গণিতের ফাংশন ব্যবহার করে ক্লায়েন্টরা প্রায়শই Mathক্লাসের উপর নির্ভর করে । সুতরাং, তারা সহজেই পর্যাপ্ত পরিমাণে খুঁজে পেতে পারে Eএবং PIখুব প্রাকৃতিক উপায়ে কোথায় সংজ্ঞায়িত হয় তাও মনে রাখতে পারে ।

যদি আপনার অ্যাপ্লিকেশনটিতে কোনও বিদ্যমান শ্রেণি না থাকে যা ধ্রুবক মানগুলির সাথে একটি খুব নির্দিষ্ট এবং শক্তিশালী কার্যকরী সংহতিযুক্ত থাকে তবে 1 ভেরিয়েন্ট) এবং 2 ভেরিয়েন্ট) উপায়গুলি আরও স্বজ্ঞাত বলে মনে হচ্ছে।
সাধারণত, ধ্রুবকগুলির ব্যবহার সহজেই স্বাচ্ছন্দ্য দেয় না যদি এগুলি যদি এমন এক শ্রেণিতে ঘোষণা করা হয় যা তাদেরকে হেরফের করে তবে আমাদের কাছে 3 বা 4 অন্যান্য ক্লাস রয়েছে যা তাদের যতটা হেরফের করে এবং এই শ্রেণীর কোনওটিই অন্যদের চেয়ে বেশি স্বাভাবিক বলে মনে হয় না স্থির মান হোস্ট করুন।
এখানে, কেবল ধ্রুবক মানগুলি ধরে রাখার জন্য একটি কাস্টম শ্রেণীর সংজ্ঞা দেওয়া অর্থপূর্ণ makes
উদাহরণস্বরূপ java.util.concurrent.TimeUnitজেডিকে পাঠাগারটিতে এনাম নির্দিষ্ট শ্রেণিতে ঘোষণা করা হয়নি কারণ সেখানে সত্যই একটি এবং জেডিকে নির্দিষ্ট একটি শ্রেণি নেই যা এটি ধারণের জন্য সবচেয়ে স্বজ্ঞাত হিসাবে উপস্থিত হয়:

public enum TimeUnit {
    NANOSECONDS {
      .....
    },
    MICROSECONDS {
      .....
    },
    MILLISECONDS {
      .....
    },
    SECONDS {
      .....
    },
      .....
}      

অনেক ক্লাস ঘোষণা java.util.concurrentব্যবহার তাদের: BlockingQueue, ArrayBlockingQueue<E>, CompletableFuture, ExecutorService, ... এবং সত্যিই তাদের কোন এক আরো উপযুক্ত enum রাখা বলে মনে হয়।


1

কোনও ধরণের কনস্ট্যান্টকে এমন এক অবিচ্ছেদ্য সম্পত্তি তৈরি করে ঘোষণা করা যেতে পারে যা কোনও শ্রেণীর মধ্যে (যা finalসংশোধনকারী সহ একটি সদস্যের পরিবর্তনশীল )। সাধারণত staticএবং publicসংশোধক এছাড়াও সরবরাহ করা হয়।

public class OfficePrinter {
    public static final String STATE = "Ready";  
}

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

public class OfficePrinter {
    public enum PrinterState { Ready, PCLoadLetter, OutOfToner, Offline };
    public static final PrinterState STATE = PrinterState.Ready;
}

1

একটি একক, জেনেরিক ধ্রুবক শ্রেণি একটি খারাপ ধারণা। ধ্রুবকগুলি যে শ্রেণীর সাথে সবচেয়ে যুক্তিযুক্ত সেগুলির সাথে তাদের একত্রিত করা উচিত।

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


1

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


1

পার্থক্য কি

1।

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

2।

public class MyGlobalConstants {
    private MyGlobalConstants () {} // Prevents instantiation
    public static final int TIMEOUT_IN_SECS = 25;
}

এবং MyGlobalConstants.TIMEOUT_IN_SECSযেখানেই আমাদের এই ধ্রুবক প্রয়োজন সেখানে ব্যবহার করছি । আমার মনে হয় দুটোই এক।


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

ক্লাস ঘোষণায় "চূড়ান্ত" স্থাপন করাও সাবক্লাসিং প্রতিরোধ করবে। (সি # তে আপনি "স্ট্যাটিক" করতে পারেন, যার অর্থ "চূড়ান্ত বিমূর্ত", সুতরাং সুস্পষ্ট বেসরকারী নির্মাণকারীর প্রয়োজন নেই))
জন কোম্বস

হ্যাঁ, @ জোনকুমস তবে "চূড়ান্ত" এটি সরাসরি তাত্পর্য প্রতিরোধ করে না। এবং জাভা ক্লাসে একসাথে উপস্থিত হতে চূড়ান্ত এবং বিমূর্ত উভয়কেই অস্বীকার করে, তাই তড়িৎ এবং সাবক্লাসিং উভয়ই রোধ করতে অবিচ্ছিন্নভাবে প্রাইভেট কনস্ট্রাক্টর উপস্থিত হয়। "চূড়ান্ত বিমূর্ত" কেন বর্জন করা হয়েছে তা আমার কোনও ধারণা নেই, প্রথম নজরে এটি যেভাবে এটি পড়ছে তাতে বিপরীত মনে হয়: "আপনি সাবক্লাস করতে পারবেন না তবে এই শ্রেণিটি সাবক্ল্যাস করা বোঝানো হয়েছে"।

0

আমি ক্লাসটিকে ধ্রুবক হিসাবে একই (কেসিং বাদে) বলব না ... আমার ন্যূনতম এক ক্লাস "সেটিংস", বা "মান" বা "ধ্রুবক" থাকবে, যেখানে সমস্ত ধ্রুবক বাস করত। আমার যদি তাদের প্রচুর সংখ্যা থাকে তবে আমি তাদের লজিকাল ধ্রুবক শ্রেণিতে (ইউজারসেটিংস, অ্যাপসেটেটিংস ইত্যাদি) গ্রুপ করব


কনস্ট্যান্টস নামে একটি ক্লাস থাকা আমার কাজটি করার পরিকল্পনা ছিল, এটি আমার কাছে পাওয়া একটি ছোট উদাহরণ।
এমকে

0

এটিকে আরও একধাপ এগিয়ে নিয়ে যাওয়ার জন্য, আপনি বিশ্বব্যাপী ব্যবহৃত ধ্রুবকগুলিকে একটি ইন্টারফেসে রাখতে পারেন যাতে তারা ব্যাপী সিস্টেম জুড়ে ব্যবহার করতে পারেন। যেমন

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

তবে এটি বাস্তবায়ন করবেন না। পুরোপুরি যোগ্য শ্রেণিবদ্ধের মাধ্যমে কেবল কোডগুলিতে কেবল তাদের সাথে উল্লেখ করুন।


একটি ইন্টারফেসে এগুলি ঘোষণা করার বিষয়টি (এবং এটি প্রয়োগ না করে) আপনি "পাবলিক স্ট্যাটিক ফাইনাল" মিস করতে পারেন।
টম হাটিন - 16:44

9
ইন্টারফেসগুলি আচরণগত চুক্তি সংজ্ঞায়নের জন্য, ধ্রুবকগুলি ধরে রাখার জন্য কোনও সুবিধা ব্যবস্থা নয়।
জন টপলি 21

@ জন টপলি হ্যাঁ, তবে এটি কার্যকর হয়। ;)
trusktr

0

ধ্রুবকগুলির জন্য, এনাম একটি ভাল পছন্দ আইএমএইচও। এখানে একটি উদাহরণ

পাবলিক ক্লাস মাইক্লাস {

public enum myEnum {
    Option1("String1", 2), 
    Option2("String2", 2) 
    ;
    String str;
            int i;

            myEnum(String str1, int i1) { this.str = str1 ; this.i1 = i }


}

0

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


0

static finalআমার পছন্দ, enumআইটেমটি সত্যিই অগণনীয় ছিল আমি কেবল একটি ব্যবহার করব ।


0

আমি ব্যবহার করি static final ধ্রুবকগুলি ঘোষণা করতে এবং ALL_CAPS নামকরণের স্বরলিপি ব্যবহার করি। আমি বেশ কয়েকটি বাস্তব জীবনের উদাহরণ দেখেছি যেখানে সমস্ত ধ্রুবককে একটি ইন্টারফেসে একত্রিত করা হয়। কয়েকটি পোস্ট ঠিকই বলেছে যে এটি একটি খারাপ অভ্যাস, প্রাথমিকভাবে কারণ এটি ইন্টারফেসের জন্য নয়। একটি ইন্টারফেসের জন্য একটি চুক্তি কার্যকর করা উচিত এবং অপ্রাসঙ্গিক ধ্রুবকগুলিকে স্থাপনের জায়গা হওয়া উচিত নয় inst এটিকে ক্লাসে একত্রে স্থাপন করা যা তাত্ক্ষণিকভাবে চালু করা যায় না (একটি বেসরকারী নির্মাণকারীর মাধ্যমে) খুব ধ্রুব শব্দার্থবিজ্ঞান নির্দিষ্ট শ্রেণীর অন্তর্ভুক্ত না হলে ( স্প্যানিশ ভাষায়)। আমি সর্বদা ক্লাসে একটি ধ্রুবক রাখি যার সাথে এটি সর্বাধিক সম্পর্কিত, কারণ এটি উপলব্ধি করে এবং সহজেই বজায় থাকে।

এনামগুলি মানগুলির একটি ব্যাপ্তি উপস্থাপনের জন্য একটি ভাল পছন্দ, তবে আপনি যদি নিখুঁত মানটির উপর জোর দিয়ে স্বতন্ত্র ধ্রুবকগুলি সঞ্চয় করে থাকেন (যেমন IM টিমিয়ুট = 100 এমএস) তবে আপনি কেবল static finalপদ্ধতির দিকে যেতে পারেন ।


0

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

@Retention(SOURCE)
@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST,NAVIGATION_MODE_TABS})
public @interface NavigationMode {}
public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;
...
public abstract void setNavigationMode(@NavigationMode int mode);
@NavigationMode
public abstract int getNavigationMode();

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


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

0

মৌলিক ভিত্তি-শূন্য মৌলবাদকে না বুঝেই জোশুয়া ব্লচকে উদ্ধৃত করা খারাপ অভ্যাস এবং ভয়াবহভাবে কিছু করার অভ্যাস নয়

আমি জোশুয়া ব্লচ কিছু পড়িনি, তাই হয়

  • তিনি একটি ভয়ানক প্রোগ্রামার
  • বা যে লোকেরা আমি এখনও তাকে উদ্ধৃত করে দেখি (জোশুয়া আমার ধারনা করা একটি ছেলের নাম) কেবলমাত্র তাদের সফ্টওয়্যার ধর্মীয় প্রবৃত্তি প্রমাণ করার জন্য তাঁর উপাদানটিকে ধর্মীয় লিপি হিসাবে ব্যবহার করছে are

বাইবেলের মৌলবাদ হিসাবে বাইবেলের সমস্ত আইন সংক্ষিপ্ত করা যেতে পারে

  • আপনার সমস্ত হৃদয় এবং আপনার সমস্ত মন দিয়ে মৌলিক পরিচয়টি ভালবাসুন
  • নিজের প্রতিবেশীকে নিজের মতো করে ভালবাসুন

এবং একইভাবে সফ্টওয়্যার ইঞ্জিনিয়ারিং মৌলবাদের সংক্ষিপ্তসার করা যেতে পারে

  • আপনার সমস্ত প্রোগ্রামিং শক্তি এবং মন দিয়ে গ্রাউন্ড-জিরো ফান্ডামেন্টালগুলিতে নিজেকে নিয়োজিত করুন
  • এবং আপনার সহ-প্রোগ্রামারদের উত্সাহের প্রতি উত্সর্গ করুন যেমন আপনি নিজের জন্য চান।

এছাড়াও, বাইবেলের মৌলবাদী চেনাশোনাগুলির মধ্যে একটি শক্তিশালী এবং যুক্তিসঙ্গত প্রতিবিম্ব আঁকা হয়

  • প্রথমে নিজেকে ভালোবাসো. কারণ আপনি যদি নিজেকে বেশি ভালোবাসেন না, তবে "আপনার প্রতিবেশীকে যেমন নিজেকে ভালোবাসেন" ধারণাটি তেমন ওজন বহন করে না, যেহেতু "আপনি নিজেকে কতটা ভালোবাসেন" এটি উপরের ডাতুম লাইন যা আপনি অন্যকে ভালবাসেন would

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

সফ্টওয়্যার প্রোগ্রামিং এর মৌলিক আইন

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

ইন্টারফেস-প্যাটার্ন ধ্রুবক একটি খারাপ অভ্যাস ???

মৌলিকভাবে কার্যকর এবং দায়িত্বশীল প্রোগ্রামিংয়ের কোন আইনের অধীনে এই ধর্মীয় আদেশটি পড়ে?

ইন্টারফেস-প্যাটার্ন ধ্রুবকগুলিতে উইকিপিডিয়া নিবন্ধটি কেবলমাত্র পড়ুন ( https://en.wikedia.org/wiki/Constant_interface ), এবং নির্বোধ অজুহাত এটিকে ইন্টারফেস-প্যাটার্নের ধ্রুবকের বিরুদ্ধে উল্লেখ করেছে।

  • ওফতিফ-কোনও আইডিই নেই? সফ্টওয়্যার প্রোগ্রামার হিসাবে পৃথিবীতে কে আইডিই ব্যবহার করবে না? আমাদের মধ্যে বেশিরভাগ প্রোগ্রামার যারা আইডিই ব্যবহার এড়িয়ে গিয়ে মাচো এসেসেটিক বেঁচে থাকার পক্ষে প্রমাণ করতে চান না।

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

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

    • "ধ্রুবকদের" অবশ্যই চুক্তি হিসাবে বিবেচনা করা উচিত নয়। এবং ইন্টারফেসগুলি কোনও চুক্তি মেনে চলার জন্য বা প্রয়োগ করার জন্য ব্যবহৃত হয়।
  • ভবিষ্যতে ইন্টারফেসগুলি বাস্তবায়িত শ্রেণিতে রূপান্তর করা যদি অসম্ভব না হয় তবে এটি কঠিন। হাহ .... হুমমম ... ???

    • আপনি কেন আপনার অবিরাম জীবিকা হিসাবে প্রোগ্রামিংয়ের এমন প্যাটার্নে যুক্ত থাকতে চান? আইওউ, কেন এমন একটি এমবিভ্যালেন্ট এবং খারাপ প্রোগ্রামিং অভ্যাসের প্রতি নিজেকে নিয়োজিত রাখুন?

অজুহাত যাই হোক না কেন, ইন্টারফেস ধ্রুবকগুলির ব্যবহারকে প্রতিনিধিত্বমূলক বা নিরুৎসাহিত করার জন্য যদি স্বতঃস্ফূর্তভাবে কার্যকর সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের কথা আসে তখন কোনও ভ্যালিডের ব্যয় হয় না।

মার্কিন যুক্তরাষ্ট্রের সংবিধানের কারুকাজকারী প্রতিষ্ঠাতা পিতাদের মূল উদ্দেশ্য এবং মানসিক অবস্থা কী তা বিবেচনাধীন নয়। আমরা প্রতিষ্ঠাতা পিতৃগণের মূল উদ্দেশ্য সম্পর্কে বিতর্ক করতে পারি তবে আমি যে বিষয়টি যত্নশীল তা হ'ল মার্কিন সংবিধানের লিখিত বিবৃতি। এবং মার্কিন সংবিধানের অলিখিত লিখিত-উদ্দেশ্যগুলি নয়, লিখিত সাহিত্য-মৌলবাদকে কাজে লাগানো প্রতিটি মার্কিন নাগরিকের দায়িত্ব is

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

ফান্ডামেন্টাল হ'ল ডেটা-মডেল নরমালাইজেশন

আপনার ডেটা-মডেলটি কীভাবে হোস্ট করা বা সংক্রমণ করা যায় তা বিবেচ্য নয়। আপনি যদি ইন্টারফেস বা enums বা whetvernots, রিলেশনাল বা ন-এসকিউএল ব্যবহার করেন, যদি আপনি ডেটা-মডেল সাধারণকরণের প্রয়োজনীয়তা এবং প্রক্রিয়া না বুঝতে পারেন।

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

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

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

ডেটা নরমালাইজেশনের ফান্ডামেন্টালস

ইএফ কোডড যা প্রকাশ করতে ব্যর্থ হয়েছিল।

প্রতিটি সুসংগত ডেটা-মডেলের মধ্যে, এটি হ'ল ডেটা-মডেল সংহতি অর্জনের ক্রমিক স্নাতক ক্রম।

  1. ডেটা উদাহরণগুলির ityক্য এবং পরিচয়।
    • প্রতিটি ডেটা উপাদানগুলির গ্রানুলারিটি ডিজাইন করুন, যার মাধ্যমে তাদের গ্রানুলারিটি এমন স্তরে যেখানে কোনও উপাদানগুলির প্রতিটি উদাহরণ স্বতন্ত্ররূপে সনাক্ত এবং পুনরুদ্ধার করা যায়।
    • উদাহরণ অ্যালিজিং অনুপস্থিতি। উদাহরণস্বরূপ, কোনও উপায় বিদ্যমান নেই যার মাধ্যমে একটি সনাক্তকরণ কোনও উপাদানটির একাধিক উদাহরণ উপস্থাপন করে।
  2. উদাহরণ ক্রসস্টালকের অনুপস্থিতি। কোনও উপাদানটির উদাহরণ সনাক্তকরণে অবদান রাখার জন্য কোনও উপাদানটির এক বা একাধিক উদাহরণ ব্যবহার করার প্রয়োজনীয়তা নেই।
  3. ডেটা উপাদান / মাত্রার একতা এবং পরিচয়।
    • উপাদান ডি-এলিয়াসিংয়ের উপস্থিতি। একটি সংজ্ঞা বিদ্যমান থাকতে হবে যার মাধ্যমে কোনও উপাদান / মাত্রা অনন্যভাবে চিহ্নিত করা যায়। কোন উপাদানটির প্রাথমিক সংজ্ঞা;
    • যেখানে প্রাথমিক সংজ্ঞার ফলে সাব-ডাইমেনশন বা সদস্য-উপাদানগুলি উদ্দিষ্ট উপাদানগুলির অংশ নয় তা প্রকাশের ফলাফল হবে না;
  4. উপাদান বিলোপ করার অনন্য উপায়। একটি উপাদান এবং একটি মাত্র অবশ্যই এই উপাদানটির জন্য ডি-আলিয়াজিং সংজ্ঞা থাকা উচিত।
  5. উপাদানগুলির ক্রমবর্ধমান সম্পর্কের ক্ষেত্রে পিতা বা মাতা উপাদান সনাক্ত করার জন্য একটি, এবং কেবল একটি, সংজ্ঞা ইন্টারফেস বা চুক্তি বিদ্যমান।
  6. উপাদান ক্রসস্টালকের অনুপস্থিতি। কোন উপাদানটির নির্দিষ্ট সনাক্তকরণে অবদান রাখতে অন্য উপাদানটির সদস্য ব্যবহার করার প্রয়োজনীয়তা নেই।
    • এই জাতীয় পিতা-মাতার সন্তানের সম্পর্কের ক্ষেত্রে পিতামাতার সনাক্তকরণ সংজ্ঞাটি কোনও সন্তানের সদস্য উপাদানগুলির সেটগুলির উপর নির্ভর করে না। পিতামাতার পরিচয়ের একটি সদস্য উপাদান সন্তানের কোনও বা সমস্ত সন্তানের রেফারেন্স ছাড়াই সম্পূর্ণ শিশু পরিচয় হতে হবে।
  7. একটি ডেটা-মডেলের উপস্থিতি দ্বি-মডেল বা মাল্টি-মডেল উপস্থিতি।
    • যখন কোনও উপাদানটির দুটি প্রার্থীর সংজ্ঞা উপস্থিত থাকে, তখন এটি স্পষ্ট লক্ষণ যে দুটি পৃথক ডেটা-মডেল এক হিসাবে মিশ্রিত রয়েছে exists এর অর্থ ডেটা-মডেল স্তরের বা মাঠের স্তরে অসঙ্গতি রয়েছে।
    • অ্যাপ্লিকেশনগুলির একটি ক্ষেত্র অবশ্যই এককভাবে এবং কেবলমাত্র একটি ডেটা-মডেল ব্যবহার করতে পারে।
  8. উপাদান রূপান্তর সনাক্ত করুন এবং সনাক্ত করুন। যদি আপনি বিশাল ডেটা সম্পর্কিত পরিসংখ্যানগত উপাদান বিশ্লেষণ না করেন তবে আপনি সম্ভবত উপাদান সংযোজনকে দেখতে বা চিকিত্সা করার প্রয়োজনটি দেখতে পাচ্ছেন না।
    • একটি ডেটা-মডেলটির কিছু উপাদান ঘূর্ণায়মান বা ধীরে ধীরে পরিবর্তিত হতে পারে।
    • মোডটি সদস্য-আবর্তন বা স্থানান্তর-ঘূর্ণন হতে পারে।
    • সদস্য-ঘূর্ণন পরিব্যক্তি উপাদানগুলির মধ্যে শিশুদের উপাদানগুলির স্বতন্ত্র স্ব্যাপিং হতে পারে। অথবা যেখানে সম্পূর্ণ নতুন উপাদানগুলি সংজ্ঞায়িত করতে হবে।
    • স্থানান্তরিত রূপান্তর ত্রিপরিবর্তনীয় একটি গুণে রূপান্তরকারী একটি মাত্রিক সদস্য হিসাবে প্রকাশিত হবে।
    • প্রতিটি মিউটেশন চক্র অবশ্যই একটি স্বতন্ত্র ডেটা-মডেল হিসাবে চিহ্নিত করা উচিত।
  9. প্রতিটি রূপান্তর সংস্করণ। আপনি ডেটা মডেলের পূর্ববর্তী সংস্করণটি টেনে আনতে পারেন, যখন সম্ভবত প্রয়োজন হতে পারে কোনও 8 বছরের পুরানো রূপান্তরটি ডেটা মডেলের চিকিত্সা করার জন্য।

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

আমরা কি এখনও জিজ্ঞাসা করছি যে আমরা ইন্টারফেস কনস্ট্যান্ট ব্যবহার করতে পারি? সত্যি?

এই জাগতিক প্রশ্নের চেয়ে ডেটা-নরমালাইজেশন সমস্যাগুলি আরও ঝুঁকির মধ্যে রয়েছে। যদি আপনি এই সমস্যাগুলি সমাধান না করেন, তবে আপনার মনে হয় যে বিভ্রান্তি ইন্টারফেসের ধ্রুবকের কারণ হিসাবে তুলনামূলকভাবে কিছুই নয়। Zilch।

ডেটা-মডেল নরমালাইজেশন থেকে তারপরে আপনি উপাদানগুলি ভেরিয়েবল হিসাবে, বৈশিষ্ট্য হিসাবে, চুক্তি ইন্টারফেসের ধ্রুবক হিসাবে নির্ধারণ করুন।

তারপরে আপনি নির্ধারণ করুন কোনটি মান ইনজেকশন, সম্পত্তি কনফিগারেশন স্থানধারক, ইন্টারফেস, চূড়ান্ত স্ট্রিং ইত্যাদি into

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

সম্ভবত আপনি একটি ভিসি রিলিজে ডেটা-মডেলটি সংকলন করতে চান। যে আপনি কোনও ডেটা-মডেলের স্বতন্ত্র সনাক্তকরণযোগ্য সংস্করণটি বের করতে পারেন।

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

সুতরাং কেন এটি একটি ডেটা-মডেল চুক্তি প্রকাশ করার জন্য নয়? আমি বোঝাতে চাইছি যদি আপনি এটি সুসংহতভাবে পরিচালনা করতে এবং স্বাভাবিক করতে পারেন তবে কেন নয়? ...

public interface CustomerService {
  public interface Label{
    char AssignmentCharacter = ':';
    public interface Address{
      String Street = "Street";
      String Unit= "Unit/Suite";
      String Municipal = "City";
      String County = "County";
      String Provincial = "State";
      String PostalCode = "Zip"
    }

    public interface Person {
      public interface NameParts{
        String Given = "First/Given name"
        String Auxiliary = "Middle initial"
        String Family = "Last name"
      }
    }
  }
}

এখন আমি আমার অ্যাপগুলির চুক্তিবদ্ধ লেবেলগুলিকে এমনভাবে উল্লেখ করতে পারি

CustomerService.Label.Address.Street
CustomerService.Label.Person.NameParts.Family

এই জার ফাইলের বিষয়বস্তু গুলিয়ে দেয়? জাভা প্রোগ্রামার হিসাবে আমি জারের কাঠামো সম্পর্কে চিন্তা করি না।

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

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

public class PurchaseRequest {
  private interface Constants{
    String INTERESTINGName = "Interesting Name";
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

সম্ভবত এটি:

public interface PurchaseOrderConstants {
  public interface Properties{
    default String InterestingName(){
       return something();
    }
    String OFFICIALLanguage = "Official Language"
    int MAXNames = 9;
  }
}

ইন্টারফেস বাস্তবায়িত হলে ইন্টারফেস ধ্রুবকগুলির একমাত্র ইস্যুটি হ'ল।

এটি ইন্টারফেসের "মূল অভিপ্রায়" নয়? সুপ্রিম কোর্ট মার্কিন সংবিধানের লিখিত চিঠিগুলিকে কীভাবে ব্যাখ্যা করবে তার চেয়ে আমি মার্কিন সংবিধানের কারুকাজ করার ক্ষেত্রে প্রতিষ্ঠাতা পিতাদের "মূল উদ্দেশ্য" সম্পর্কে চিন্তা করব ???

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

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