আপনি যে ভাষায় প্রোগ্রামিং করছেন তাতে বাহ্যিক ডেটা অনুবাদ করা

Question

নিম্নলিখিতগুলির সাথে কী করবেন তা আমি নিশ্চিত নই:

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

তাহলে কি এটি তৈরি করা যুক্তিসঙ্গত হবে:

public enum Department { BOUW, ONDERHOUD }

বা:

public enum Department { CONSTRUCTION, MAINTENANCE }

অথবা এমনকি:

public enum Afdeling { BOUW, ONDERHOUD }

(আফডালিং ডাচ বিভাগ

Comments

সম্ভাব্য সদৃশ নন-ইংলিশ নেমিং কনভেনশন

— মশা

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

— জেলি

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

— kayleeFrye_onDeck

আপনার বাকি প্রোগ্রাম (স্ট্যান্ডার্ড লাইব্রেরি বাদে) ইংরেজি বা ডাচ শনাক্তকারী ব্যবহার করে?

— ব্যবহারকারী 253751

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

— জেলি

Answer 1

এই পরিস্থিতিতে আমি ডাচ ভাষায় এনাম মানগুলি রেখে যাব :

public enum Department { BOUW, ONDERHOUD }

কারণ এই ধ্রুবকগুলি ব্যবহার করে যুক্তিটি ডাচ ভাষায় থাকা ডেটার সাথে মেলে । উদাহরণস্বরূপ, যদি ইনপুটটি "বাউ" হয় তবে তুলনা কোডটি দেখতে দেখতে পারে:

if (Department.BOUW == input.toUpper())

আমি মানগুলি মিলে গেলে ডিবাগ করা আরও সহজ মনে করি (মানগুলির অর্থ কী তা আমি জানি না)। অনুবাদ কেবলমাত্র একটি মানসিক হুপ যোগ করে, একজন বিকাশকারী হিসাবে, সঠিকতা প্রমাণের জন্য আমাকে ঝাঁপিয়ে পড়া উচিত নয়।

তবুও, আপনি কোডটি মন্তব্য করতে পারেন যদি তা অন্যদের উপাত্তের প্রসঙ্গে বুঝতে সহায়তা করে:

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}

Comments

@ জেলি অবশ্যই, যদি আপনি কখনও আন্তর্জাতিকভাবে প্রসারিত হয়ে থাকেন তবে আপনি যে কোনওভাবে অনুবাদ যুক্তিকে সন্তুষ্ট করতে পারেন। YAGNI তে YMMV।

— উইলিয়াম টটল্যান্ড

আপনার এনামগুলিকে স্ট্রিংয়ের সাথে সরাসরি যেকোনভাবে তুলনা করা উচিত নয়। যদি আপনাকে এনাম মানের সাথে বেশ কয়েকটি শব্দের সাথে একটি স্ট্রিং তুলনা করতে হয়?

— জার্জেন ফোগ

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

— অ্যাড্রিয়ানো রেপিটি

@ অ্যাবোশম্যান লাইনের মন্তব্যগুলির সমাপ্তি সর্বজনীনভাবে তারা যে লাইনে রয়েছে তার উল্লেখ করে। আমি শত

— শতবার

আমাদের দোকানে, আমরা এখানে প্রস্তাবিতগুলির বিপরীতটি করি: এনাম / কনস্টের নামগুলি ইংরেজীতে (বা যা ইংরেজীতে পাস হয়), এবং মন্তব্যগুলি "স্থানীয়করণ" হয়। যা ভাল. অন্যথায় আমাদের মতো নামগুলির সাথে এই সমস্ত কনসেটগুলি থাকত PAAMAYIM_NEKUDOTAYIM।

— sq33G

Answer 2

ইংরাজী একটি কারণে একটি লিঙ্গুয়া ফ্র্যাঙ্কা / সর্বনিম্ন সাধারণ ডিনোমিনেটর। এমনকি যদি কারণটি "প্রত্যেকেরই এটি করে" এর মত ধারণাগতভাবে দুর্বল হয় তবে এটি এখনও একটি গুরুত্বপূর্ণ কারণ।

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

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

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

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

Comments

+1, সেই ক্ষেত্রে ইংরাজী ব্যবহার করা আপনাকে কোড পঠনযোগ্যতা এবং পুনরায় ব্যবহারযোগ্যতা দেয় যা এই উত্তরে প্রকাশিত হয়েছে। এটি ডাচ বানানোর সময় কোনওভাবে তাদের বিরতি দেয়।

— মিখাইল চুরবানভ

@ জেলি কি কোডটির কোডটির অর্থের কোনও অর্থ রয়েছে? যদি হ্যাঁ, তবে এটি অনুবাদ করুন - যাইহোক আপনার ধারণাটির অনুবাদ দরকার। যদি তা না হয় তবে কেন আপনি enumএটির জন্য একটি আছে ? এটি কেবলমাত্র একটি চিহ্ন হতে পারে যে আপনি কোডে ডেটা মডেল করার চেষ্টা করছেন যা কোনও খারাপ ধারণা হতে পারে।

— লুয়ান

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

— রাইময়েড

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

— জেলি

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

— গুরান

Answer 3

যেখানে সম্ভব অনুবাদটি এড়িয়ে চলুন, কারণ প্রতিটি অনুবাদই অতিরিক্ত প্রচেষ্টা এবং বাগগুলি প্রবর্তন করতে পারে।

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

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

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

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

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

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

Comments

ব্যবসায় বিশেষজ্ঞরা ইংরেজিতে কথা বলবেন। কর্মীদের মধ্যে শিক্ষিত ডাচদের মধ্যে ইংরেজি দক্ষতা 100%।

— MSalters

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

— গুরান

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

— মেরিটন -

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

— এমসাল্টাররা

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

— এমসাল্টারস

Answer 4

সঠিক সমাধানটি হ'ল বিভাগগুলি কঠোর কোড না করা:

ArrayList<String> departments = (... load them from a configuration file ...)

অথবা, আপনার যদি একেবারে বিভাগীয় ধরণের প্রয়োজন হয়:

class Department { String name; Department(String name) { this.name = name; } ... }
HashMap<String, Department> = (... generate from configuration file ...)

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

Comments

এই. কোনও প্রস্থান যখন বিভক্ত হয়ে যায় বা একত্রিত হয়ে যায় বা কোনও নতুন রূপ নেয় তখন কী হয়? এই কোডটি কম বেশি স্বয়ংক্রিয়ভাবে মানিয়ে নেবে; এটিকে এনামে রূপান্তরিত করার অর্থ আপনার নতুন বিল্ড প্রয়োজন বা এটি বিস্ফোরিত হবে।

— jpmc26

বিভাগগুলি যদি আমাদের আবেদনে এত বড় ভূমিকা না নেয় তবে এটি একটি সমাধান হবে। আমাদের কাছে প্রচুর if (project.getDepartment().equals(Department.XYZ))বক্তব্য রয়েছে।

— জেলি

@ জেল কীভাবে project.isForDepartment("XYZ"), যা ঘুরেফিরে ড্যানিয়েলের হ্যাশম্যাপ ব্যবহার করে (যা প্রকল্পে ইনজেকশন দেওয়া হয়, বা

— কোনও

@ এসটিটি, এটি কেবল টাইপগুলির জন্য জিজ্ঞাসা করছে, সত্যই ...

— জেল

@ জেলি হ্যাঁ, তবে এটি রানটাইম ধরে যায়। সংকলন সময়েও টেস্টগুলি সেগুলি ধরতে পারে। (যদিও আপনি বুঝতে পেরেছেন আপনি কোথা থেকে এসেছেন, এবং আমি

— একরকম

Answer 5

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

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }

Comments

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

— বিশপ

আমি গৃহীত উত্তর পরিবর্তন করেছি। যাইহোক, upvotes মধ্যে পরিসর দেওয়া, আমি মনে করি এটি একটি ব্যক্তিগত পছন্দ, এবং আমি এই পদ্ধতির জন্য বেছে নিয়েছি।

— জেলি

Answer 6

আপনি যদি ব্যবহারকারী বা কিছু দেখানোর জন্য স্ট্রিং প্রতিনিধিত্ব সম্পর্কে উদ্বিগ্ন হন তবে কেবল আপনার এনমের ভিতরে একটি বর্ণনামূলক অ্যারের সংজ্ঞা দিন এবং কোনও পদ্ধতি প্রকাশ করুন exp
উদাহরণস্বরূপ: Department.BUILD.getDescription();"বাউ" আউটপুট আসবে

public enum Department { 
    BUILD,
    MAINTENANCE;

    private String[] descriptions = new String[] {
        "BOUW",
        "ONDERHOUD"
    };

    public String getDescription() {
        return descriptions[ordinal()];
    }
}

আমি জানি আপনি অন্যথায় বেছে নিয়েছেন তবে গুগল ঘূর্ণি লোকটিকে দুর্ঘটনাক্রমে এখানে ফেলে দেয়।

সম্পাদনা: পোকেচু 22 দ্বারা উল্লিখিত হিসাবে আপনি এনাম কনস্ট্রাক্টর এবং ব্যক্তিগত বৈশিষ্ট্যগুলি এর মতো ব্যবহার করতে পারেন:

public enum Department {
    BUILD("BOUW"),
    MAINTENANCE("ONDERHOUD");

    private final String description;

    private Department(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }
}

যা প্রভাবও অর্জন করবে।

Comments

আপনার অ্যারে লাগবে না। জাভাতে, এনামগুলিতে (বেসরকারী) কনস্ট্রাক্টর এবং ক্ষেত্র থাকতে পারে।

— পোকেচু 22

@ পোকেছু 22, তবে কনস্ট্রাক্টরের মান বা অর্ডিনাল কি বর্ণনার সাথে এটি মিলাতে সক্ষম হবে? আমি বোঝাতে চাইছি, সঠিক বর্ণনাটি পাওয়ার জন্য আপনার এখনও ডি কন্সট্রাক্টরের ভিতরে একটি অ্যারের দরকার হবে?

— স্পার্ক

না, আপনি এটি এর মতো করতে পারেন:public enum Department { BUILD("BOUW"), MAINTENANCE("ONDERHOUD"); private final String description; private Department(String description) { this.description = description; } public String getDescription() { return description; } }

— পোকেচু 22

@ পোকেছু 22 উত্তরে যুক্ত হয়েছে। অ্যারে বাড়ার ক্ষেত্রেও আমি লক্ষ করেছি, আমার প্রয়োগটি প্রতিবার 2 টি লাইন ভেঙে যেতে পারে এবং আপনার 1 টি লাইন বাড়বে এবং রেফারেন্স ভাঙবে না।

— স্পারক

Answer 7

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

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

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

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

ডেটা ফর্ম্যাট এবং আপনার ডোমেন মডেলের মধ্যে অনুবাদ করার চেয়ে পার্সার। আপনার কোডটিতে ডেটা ফর্ম্যাটটির প্রভাবের এটিই শেষ।