কারণ Optionalজাভা যোগ করা হয়েছিল এই কারণে হল:
return Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
.stream()
.filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
.filter(m -> Arrays.equals(m.getParameterTypes(), parameterClasses))
.filter(m -> Objects.equals(m.getReturnType(), returnType))
.findFirst()
.getOrThrow(() -> new InternalError(...));
এর চেয়ে পরিষ্কার:
Method matching =
Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
.stream()
.filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
.filter(m -> Arrays.equals(m.getParameterTypes(), parameterClasses))
.filter(m -> Objects.equals(m.getReturnType(), returnType))
.getFirst();
if (matching == null)
throw new InternalError("Enclosing method not found");
return matching;
আমার বক্তব্যটি হ'ল ptionচ্ছিকটি ফাংশনাল প্রোগ্রামিং সমর্থন করার জন্য লেখা হয়েছিল , যা একই সাথে জাভাতে যুক্ত হয়েছিল। (উদাহরণটি ব্রায়ান গয়েটসের ব্লগের সৌজন্যে আসে A আরও ভাল উদাহরণটি orElse()পদ্ধতিটি ব্যবহার করতে পারে , যেহেতু এই কোডটি যাইহোক একটি ব্যতিক্রম ছুঁড়ে ফেলবে তবে আপনি ছবিটি পেয়ে যাবেন))
তবে এখন লোকেরা খুব আলাদা কারণে ptionচ্ছিক ব্যবহার করছে। তারা ভাষা ডিজাইনের কোনও ত্রুটি সমাধানের জন্য এটি ব্যবহার করছে। ত্রুটিটি হ'ল: কোনও এপিআই-র কোনটি প্যারামিটার এবং রিটার্ন মানগুলি শূন্য করার অনুমতি দেওয়া হয়েছে তা নির্দিষ্ট করার কোনও উপায় নেই। এটি জাভাডোকগুলিতে উল্লেখ করা যেতে পারে তবে বেশিরভাগ বিকাশকারীরা তাদের কোডের জন্য জাভাডোকগুলিও লেখেন না এবং লেখার সাথে সাথে অনেকেই জাভাদোকগুলি পরীক্ষা করবেন না। সুতরাং এটি প্রচুর কোডের দিকে নিয়ে যায় যা সর্বদা এগুলি ব্যবহারের আগে নাল মানগুলি পরীক্ষা করে, যদিও তারা প্রায়শই নাল হতে পারে না কারণ তারা কল স্ট্যাকের জন্য নয় বা দশ বার বার বার বৈধ হয়ে গিয়েছিল।
আমি মনে করি এই ত্রুটিটি সমাধানের জন্য সত্যিকারের তৃষ্ণা হয়েছিল, কারণ নতুন ptionচ্ছিক শ্রেণিটি দেখে এর এত লোক যে এর উদ্দেশ্য ধরে নিয়েছিল তা হ'ল এপিআইগুলিতে স্পষ্টতা যুক্ত করা। লোকেদের "বিকল্পগুলি কীভাবে ফিরে আসবে?" না, এগুলি সম্ভবত করা উচিত নয়, যদি না আপনি প্রত্যাশাটি কার্যকরী প্রোগ্রামিংয়ে ব্যবহৃত হওয়ার প্রত্যাশা করেন, যা খুব সম্ভবত না। প্রকৃতপক্ষে, আপনি যদি জাভা এপিআইতে ptionচ্ছিক ব্যবহৃত হয় তা লক্ষ্য করেন তবে এটি মূলত স্ট্রিম ক্লাসগুলিতে থাকে যা কার্যকরী প্রোগ্রামিংয়ের মূল বিষয়। (আমি খুব ভালভাবে পরীক্ষা করে দেখিনি, তবে স্ট্রিম ক্লাসগুলিই কেবল তাদের ব্যবহৃত স্থান হতে পারে ))
আপনি যদি কিছু ফাংশনাল কোডে একটি গেটর ব্যবহার করার পরিকল্পনা করেন, তবে এটি একটি আদর্শ গেটর এবং দ্বিতীয়টি ptionচ্ছিক ফিরে আসা ভাল ধারণা হতে পারে।
ওহ, এবং যদি আপনার শ্রেণি সিরিয়ালযোগ্য হওয়ার প্রয়োজন হয় তবে আপনার একেবারে ptionচ্ছিক ব্যবহার করা উচিত নয়।
বিকল্পগুলি এপিআই ত্রুটির জন্য খুব খারাপ সমাধান কারণ ক) তারা খুব ভার্ভোস, এবং খ) তাদের সমস্যাটি প্রথম স্থানে সমাধান করার উদ্দেশ্যে কখনও করা হয়নি।
এপিআই ত্রুটির আরও ভাল সমাধান হ'ল নলনেস চেকার । এটি একটি এনোটেশন প্রসেসর যা আপনাকে উল্লেখ করতে দেয় যে কোন প্যারামিটারগুলি এবং ফেরতের মানগুলি @ নুলাবল দিয়ে টিকিয়ে দিয়ে নালাগুলি মঞ্জুরিপ্রাপ্ত। এইভাবে, সংকলক কোডটি স্ক্যান করতে পারে এবং এটি নির্ধারণ করতে পারে যে কোনও মান যা আসলে নাল হতে পারে এমন কোনও মান যেখানে নাল অনুমতি দেওয়া হয় না তা পাস করা হচ্ছে। ডিফল্টরূপে, এটি ধরে নেওয়া হয় যে এটির কোনও উল্লেখ করা না থাকলে কোনও কিছুই শূন্য হওয়ার অনুমতি নেই। এইভাবে, আপনাকে নাল মান সম্পর্কে চিন্তা করতে হবে না। একটি প্যারামিটারে একটি নাল মান পাস করার ফলে একটি সংকলক ত্রুটি ঘটবে। শূন্যের জন্য কোনও বস্তুর পরীক্ষা করা যা নাল হতে পারে না তা সংকলক সতর্কতা তৈরি করে। এর প্রভাব হ'ল নালপয়েন্টারএক্সসেপশনকে রানটাইম ত্রুটি থেকে একটি সংকলন-সময় ত্রুটিতে পরিবর্তন করা।
এটি সবকিছু পরিবর্তন করে।
আপনার প্রাপকদের হিসাবে, ptionচ্ছিক ব্যবহার করবেন না। এবং আপনার ক্লাসগুলি ডিজাইনের চেষ্টা করুন যাতে কোনও সদস্যই সম্ভবত শূন্য হতে না পারে। এবং আপনার প্রকল্পে নুলনেস পরীক্ষক যুক্ত করার চেষ্টা করুন এবং আপনার গেটার্স এবং সেটার পরামিতিগুলি @ নলাবলের যদি তাদের প্রয়োজন হয় তা ঘোষণা করার চেষ্টা করুন। আমি কেবল নতুন প্রকল্পগুলি দিয়ে এটি করেছি। এটি শূন্যতার জন্য প্রচুর অতিরিক্ত অতিরিক্ত পরীক্ষা করে লেখা বিদ্যমান প্রকল্পগুলিতে প্রচুর সতর্কতা তৈরি করে, তাই এটি পুনরুদ্ধার করা শক্ত হতে পারে। তবে এটি অনেকগুলি বাগও ধরবে। আমি এটা ভালোবাসি. আমার কোড অনেক ক্লিনার এবং এর কারণে আরও নির্ভরযোগ্য।
(এটির সাথে একটি নতুন ভাষাও সম্বোধন করে। কোটলিন, যা জাভা বাইট কোডটি সংকলন করে, আপনাকে নির্দিষ্ট করার অনুমতি দেয় যে কোনও বস্তু যখন আপনি এটি ঘোষণার সময় নਾਲ হতে পারে It's এটি একটি ক্লিনার পদ্ধতির))
মূল পোস্টে সংযোজন (সংস্করণ 2)
অনেক চিন্তাভাবনা করার পরে, আমি অনিচ্ছাকৃতভাবে এই সিদ্ধান্তে পৌঁছেছি যে এক শর্তে ptionচ্ছিক ফিরিয়ে দেওয়া গ্রহণযোগ্য: এটি পুনরুদ্ধার করা মানটি আসলে শূন্য হতে পারে। আমি প্রচুর কোড দেখেছি যেখানে লোকেরা নিয়মিত গিটারগুলি থেকে tersচ্ছিক ফিরে আসে যা সম্ভবত বাতিল হয়ে যায় না। আমি এটি একটি খুব খারাপ কোডিং অনুশীলন হিসাবে দেখছি যা কোডগুলিতে কেবল জটিলতা যুক্ত করে, যা বাগগুলি আরও বেশি সম্ভাবনা তৈরি করে। কিন্তু যখন প্রত্যাবর্তিত মানটি আসলে শূন্য হতে পারে, তখন এগিয়ে যান এবং এটি একটি insideচ্ছিকের মধ্যে আবৃত করুন।
মনে রাখবেন যে পদ্ধতিগুলি কার্যকরী প্রোগ্রামিংয়ের জন্য ডিজাইন করা হয়েছে এবং এর জন্য একটি ফাংশন রেফারেন্স প্রয়োজন, দুটি আকারে লিখিত হবে (এবং হওয়া উচিত) যার মধ্যে একটি ptionচ্ছিক ব্যবহার করে। উদাহরণস্বরূপ, Optional.map()এবং Optional.flatMap()উভয়ই ফাংশন উল্লেখগুলি গ্রহণ করে। প্রথমটি কোনও সাধারণ গেটারের জন্য একটি রেফারেন্স নেয় এবং দ্বিতীয়টি oneচ্ছিকভাবে ফিরে আসে one সুতরাং আপনি কোনও Oচ্ছিক যেখানে মান নালার হতে পারে তা ফেরত দিয়ে কাউকে অনুগ্রহ করছেন না।
সমস্ত কিছু বলার পরেও, আমি এখনও দেখতে পাচ্ছি নুলস চেকার দ্বারা ব্যবহৃত পদ্ধতির নালগুলি মোকাবেলার সেরা উপায়, যেহেতু তারা সময় ত্রুটিগুলি সঙ্কলন করতে রানটাইম বাগগুলি থেকে নালপয়েন্টারএক্সেপশনগুলি ঘুরিয়ে দেয়।