কেন জাভা স্ট্রিংয়ের স্ট্যাটিক স্ট্রিং ম্যানিপুলেশন পদ্ধতি নেই?


17

কেন জাভা ডিজাইনাররাjava.lang.String ক্লাসে স্ট্রিং ম্যানিপুলেশন পদ্ধতির স্থির সংস্করণ তৈরি করেনি ? নিম্নলিখিত পদ্ধতিগুলি আমি উল্লেখ করছি তবে প্রশ্নটি ক্লাসের অন্যান্য অ-স্থিতিশীল পদ্ধতিতেও বাড়ানো যেতে পারে।

concat(String)                        substring(int, int)
replace(char, char)                   toLowerCase()
replace(CharSequence, CharSequence)   toLowerCase(Locale)
replaceAll(String, String)            toString()
replaceFirst(String, String)          toUpperCase()
split(String)                         toUpperCase(Locale)
split(String, int)                    trim()
substring(int)

এই পদ্ধতির কেবল অ-স্থিতিশীল সংস্করণ থাকার কারণে এ জাতীয় পদ্ধতিটি যে কোনও জায়গায় স্পষ্টভাবে নাল চেক করতে বাধ্য হয়। উদাহরণস্বরূপ, কেবল আহ্বান example = example.trim()হতে হবে নালপয়েন্টারএক্সেপশন যদি String example = null। সুতরাং প্রোগ্রামারকে নিম্নলিখিত বয়লারপ্লেট নাল চেক করতে হবে:

if (example != null)
    example = example.trim();
// OR:
example = (example==null) ? null : example.trim();
example = (example==null) ? null : example.substring(5);

আমি কল্পনা করতাম যদি Stringএই পদ্ধতিগুলির স্থির সংস্করণগুলি (সম্ভবত একচেটিয়াভাবেও ) থাকত তবে এটি অনেক বেশি সুবিধাজনক হত, যা ইনপুট স্ট্রিংটিকে প্রথম যুক্তি হিসাবে গ্রহণ করবে:

example = String.trim(example);
example = String.replace(example, 'a', 'b');
example = String.substring(example, 5);

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

জাভা ডিজাইনাররা যখন Stringজাভা 1 বা জাভা 2-তে ক্লাসটি ডিজাইন করেছিলেন , বা এমনকি জাভা সংস্করণে এ জাতীয় কার্যকারিতা যুক্ত করেছিলেন তখন কেন এটি সম্পর্কে চিন্তা করেননি ?


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

5
nullএকটি ব্যতিক্রমী রাষ্ট্র এবং স্পষ্টভাবে পরিচালনা করা উচিত।
কোডসইনচাউস

2
@ কনরাডমোরোভস্কি: ব্যক্তিগতভাবে আমি দেখতে পেয়েছি যে সম্প্রসারণের পদ্ধতিগুলির একদম অপব্যবহার। যদি আপনার নাল মান হয় তবে পৃথিবীতে আপনি কী পদ্ধতিতে কল করার চেষ্টা করছেন, আপনি কেবল সেই কোডটি পড়ে এমন সকলকে বিভ্রান্ত করতে চলেছেন। Maybe<T>আমার ধারণা, এটি কোনও ধরণের দরিদ্র পুনঃসংশোধন ?
ফোশি

1
@Phoshi এক হয়েছে তারা শুধু সিনট্যাক্স চিনি আছেন, মনে রাখতে হবে এক্সটেনশন পদ্ধতি বাস্তব পদ্ধতি নেই। তবে আমি একমত যে এটি বিতর্কিত। আমার ইচ্ছা সি # / জাভা কোনও ধরণের অন্তর্নির্মিত সিনট্যাকটিক নাল-সুরক্ষা প্রদান করেছিল, যেমন - বলুন - কোটলিন। string name = employee?.personalData?.name। ঠিক যেমন এই সমস্ত পুনরাবৃত্তির জন্য একটি শর্টকাট if (employee != null)। সম্পর্কিত এসও প্রশ্ন: স্ট্যাকওভারফ্লো
কনরাড মোরাউস্কি

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

উত্তর:


30

নাল ফেরার বিষয়টি আমার কাছে বোধগম্য যেহেতু নাল স্ট্রিংয়ের কারসাজির ফলে নাল স্ট্রিং হওয়া উচিত, ত্রুটি নয়

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

"জাভা ডিজাইনারগণ" কেন কিছু করেছেন বা করেন নি তা জবাব দেওয়া কঠিন difficult

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


আপনার মন্তব্যের ভিত্তিতে সংযোজন

মন্তব্যগুলি পড়ে, মনে হচ্ছে আপনার আসল সমস্যাটি হ'ল nullআপনার কোডটি জুড়ে আপনাকে যাচাই করতে হবে। এটি ইন্টারফেসের মধ্যে পরিষ্কারভাবে সংজ্ঞায়িত চুক্তি ব্যতীত কোনও খারাপ প্রোগ্রাম ডিজাইনের সূচক হতে পারে। আপনি জাভাতে "! = নাল" স্টেটমেন্ট এড়ানোর বিষয়টি পড়তে চাইতে পারেন ?


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

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

নালাগুলির সাথে মোকাবিলার একটি উপায় হল পেয়ারা Optional- কোড. google.com/p/guava-libraries/wiki/…
কনরাড

10

আইএমও পুরো "যদি অর্গ নাল রিটার্ন নাল হয়" লেখার পদ্ধতিগুলির অভাব অহেতুক আপনার প্রোগ্রামের সাইক্লোমেটিক জটিলতা বৃদ্ধি করে।

শুরুর দিকে জাভা লিবিসগুলি রিটার্ন নাল পদ্ধতির ব্যবহার করে, তবে জেডি কে ছেলেরা সর্বদা ব্যতিক্রমগুলি বাদ দিয়ে রক্ষা করে।

সময়ের সাথে সাথে, আমি মনে করি যে পরবর্তী পদ্ধতিটি স্পষ্ট বিজয়ী হিসাবে প্রকাশিত হয়েছে।

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

আপনার সমস্যাগুলি সমাধান করার জন্য নাল ক্ষেত্রের উপর নির্ভর না করে নাল অবজেক্ট প্যাটার্নটি ব্যবহার করার বিষয়টি বিবেচনা করুন।


2
কিন্তু Stringবহুমুখী নয়, নেই? এবং আপনি কীভাবে স্ট্রিংয়ের মতো ইতিমধ্যে বিদ্যমান ধরণের জন্য নাল অবজেক্ট প্যাটার্নটি ব্যবহার করবেন?
সুইভ

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

@ আলেকজান্দারস্টলিং: টাইপের ক্ষেত্রের intচেয়ে শূন্যের চেয়ে শূন্য হয় null। ধারণামূলকভাবে এমন stringধরণের হওয়া সম্ভব যাঁর ডিফল্ট মানটি খালি স্ট্রিংয়ের পরিবর্তে null[এ জাতীয় ধরণটি নির্ধারিতভাবে Stringযা করতে হবে তা intহতে পারে Integer]। stringঅভ্যন্তরীণভাবে একটি খালি অবধি কোনও হিপ অবজেক্টের রেফারেন্স রাখবে তা বাস্তবায়নের বিশদ হবে; কোনও কারণ নেই যে এটি আধ্যাত্মিকভাবে কোনও আদিমের মতো আচরণ করতে পারে না।
সুপারক্যাট

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

@ আলেকজান্ডারস্টারলিং: সমস্ত ধরণের স্টোরের অবস্থানগুলি অল-বাইট-শূন্যের ডিফল্টরূপে থাকা এবং সেই কাঠামোর ধরণগুলি অল-বাইট-অনুলিপি দ্বারা নির্ধারিত করা যায়, একটি কাঠামো সহজভাবে সরল করে তোলে, তবে বেশিরভাগ ক্ষেত্রে বোঝানো হয় যে পরিবর্তনীয় রেফারেন্স শব্দার্থবিজ্ঞানযুক্ত ধরণের ক্ষেত্রে অবশ্যই ডিফল্টরূপে আবশ্যক খালি. তবে এটি কার্যকর হতে পারে এমন মান ধরণের ক্ষেত্রে কাঠামোগত সমর্থন থাকতে হবে যা একটি একক রেফারেন্সকে আবদ্ধ করে এবং "বাক্স" হিসাবে - এবং সেই রেফারেন্স টাইপ থেকে আনবক্স করতে পারে
সুপারক্যাট

3

এটি কারণ হিসাবে বলা হচ্ছে না, তবে টসস্ট্রিং ব্যতীত, এই সমস্ত পদ্ধতি সহজেই একটি স্ট্যাটিক সহায়ক শ্রেণিতে আবদ্ধ হয়, যখন বিপরীতটি সত্য হয় না।

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


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

2
আপাতত, আপনার কাছে String.format(অচল) রয়েছে তবে আপনি এটি করতে পারবেন না "something %s".format(id)
কনরাড মোরাওস্কি

@ অ্যাডটিসি: কারণ এটি স্ট্যাটিক শ্রেণীর মাধ্যমে ভাষা করা কোনও মৌলিক বৈশিষ্ট্য নয়। এই ভিত্তিটি থেকে শুরু করে, এটি না করার অনেক কারণ রয়েছে - অপ্রয়োজনীয় কোড / কোড ফোলা, নকল কার্যকারিতা, বিকাশের খরচ / রক্ষণাবেক্ষণ।
jmoreno

-2

জাভাতে, স্ট্রিংটি একটি অবজেক্ট। এটি একটি নকশা পছন্দ।

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

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

জাভা ডিজাইনাররা যখন জাভা 1 বা জাভা 2-এ স্ট্রিং ক্লাসটি ডিজাইন করেছিলেন বা পরবর্তী জাভা সংস্করণে এ জাতীয় কার্যকারিতা যুক্ত করেছেন তখন কেন এটি সম্পর্কে চিন্তা করেননি?

তারা সম্ভবত এটি সম্পর্কে চিন্তাভাবনা করেছিল এবং আচরণ-আচরণকে অন্তর্ভুক্ত করার সিদ্ধান্ত নিয়েছিল।


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

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

4
স্ট্রিংগুলি অবজেক্টস হওয়ার কারণে স্ট্রিং ক্লাসে স্থির পদ্ধতি থাকতে পারে না বলে বোঝায়। এবং প্রকৃতপক্ষে এটি ইতিমধ্যে কিছু আছে। String.format। (সি # তে একই, উপায় দ্বারা)। সুতরাং যদি এটি কোনও ডিজাইনের পছন্দ হয় তবে এটি কেবল স্ট্রিংগুলি অবজেক্টের থেকে আসে না এবং এটি ধারাবাহিকভাবে প্রয়োগ হয় না।
কনরাড মোরাওস্কি

@ পিটারবি যদি কমপক্ষে এই পদ্ধতিগুলি কোনও Stringsইউটিলিটি ক্লাসে সরবরাহ করা হত তবে আমি অভিযোগ করব না , যদিও আমাদেরArrays ইউটিলিটি ক্লাস রয়েছে ( যদিও আমি বুঝতে পারি যে এটি অ্যারেগুলির ফলে আদিম এবং বস্তুর মধ্যে এক ধরণের অদ্ভুত ক্রস হওয়ার কারণে নিখরচায় প্রয়োজনীয়তার কারণে তৈরি হয়েছিল: ) ) .. যতক্ষণ না এটি স্ট্যান্ডার্ড জাভার অংশ ছিল এবং নির্ভরতার প্রয়োজন পড়েনি।
এডিটিসি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.