কোনও বস্তুর দক্ষতাগুলি প্রয়োগ করা ইন্টারফেসগুলির দ্বারা একচেটিয়াভাবে চিহ্নিত করা উচিত?

Question

সি # এর isঅপারেটর এবং জাভা instanceofঅপারেটর আপনাকে ইন্টারফেসে শাখা করার অনুমতি দেয় (বা আরও অজানাভাবে এর বেস ক্লাস) কোনও অবজেক্ট ইনস্ট্যান্স কার্যকর করেছে।

কোনও ইন্টারফেস সরবরাহ করে এমন দক্ষতার উপর ভিত্তি করে এই বৈশিষ্ট্যটি কি উচ্চ স্তরের শাখার জন্য ব্যবহার করা উপযুক্ত?

অথবা কোনও বেস শ্রেণীর কোনও বস্তুর ক্ষমতার বর্ণনা দেওয়ার জন্য একটি ইন্টারফেস সরবরাহ করতে বুলিয়ান ভেরিয়েবলগুলি সরবরাহ করা উচিত?

উদাহরণ:

if (account is IResetsPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

বনাম

if (account.CanResetPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

দক্ষতা সনাক্তকরণের জন্য ইন্টারফেস বাস্তবায়ন ব্যবহারের জন্য কি তাদের কোনও সমস্যা রয়েছে?

---

এই উদাহরণটি ঠিক এটি ছিল, একটি উদাহরণ। আমি আরও সাধারণ প্রয়োগ সম্পর্কে ভাবছি।

Comments

আপনার দুটি কোড উদাহরণ দেখুন। কোনটি বেশি পাঠযোগ্য?

— রবার্ট হার্ভে

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

— বেকুজ

@ নোকমপ্রেন্ডে: xkcd.com/927

— রবার্ট হার্ভে

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

— মেটাফাইট

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

— ইউফোরিক

Answer 1

সাবধানতা অবলম্বন করে যে সম্ভব হলে ডাউন কাস্টিং এড়ানো ভাল, তবে প্রথম ফর্মটি দুটি কারণে ভাল:

1. আপনি আপনার জন্য টাইপ সিস্টেমকে কাজ করতে দিচ্ছেন। প্রথম উদাহরণে, যদি isআগুন লাগে তবে ডাউনকাস্ট অবশ্যই কাজ করবে। দ্বিতীয় আকারে, আপনাকে ম্যানুয়ালি নিশ্চিত করতে হবে যে কেবলমাত্র কার্যকর করা বস্তুগুলি IResetsPasswordসেই সম্পত্তির জন্য সত্য ফিরে আসে
2. ভঙ্গুর বেস ক্লাস। আপনি যুক্ত করতে চান এমন প্রতিটি ইন্টারফেসের জন্য আপনাকে বেস শ্রেণি / ইন্টারফেসে একটি সম্পত্তি যুক্ত করতে হবে। এটি জটিল এবং ত্রুটি-প্রবণ।

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

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

Comments

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

— দ্যাটিক্যাটহিস্পেরার

আপনি চেকটি এত সহজ করতে পারেন: (account as IResettable)?.ResetPassword();বাvar resettable = account as IResettable; if(resettable != null) {resettable.ResetPassword()} else {....}

— বারিন লরিচচ

Answer 2

কোনও বস্তুর দক্ষতাগুলি প্রয়োগ করা ইন্টারফেসগুলির দ্বারা একচেটিয়াভাবে চিহ্নিত করা উচিত?

কোনও বস্তুর সক্ষমতা একেবারে চিহ্নিত করা উচিত নয়।

কোনও অবজেক্ট ব্যবহার করা ক্লায়েন্টের কীভাবে এটি কাজ করে সে সম্পর্কে কিছু জানতে হবে না। ক্লায়েন্টের কেবল এমন জিনিসগুলি জানা উচিত যা এটি অবজেক্টটিকে বলতে পারে। বস্তুটি যা করে, একবার তা বলা হয়ে গেলে এটি ক্লায়েন্টদের সমস্যা নয়।

বরং বরং

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

অথবা

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

বিবেচনা

account.ResetPassword();

অথবা

account.ResetPassword(authority);

কারণ accountএটি কাজ করবে কিনা তা ইতিমধ্যে জানে। কেন এটা জিজ্ঞাসা? আপনি যা চান তা কেবল এটি বলুন এবং এটি যা করতে চলেছে তা করতে দিন।

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

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

Comments

পলিমারফিজম কেবল তখনই কাজ করে যখন আমি জানি না আমি ঠিক কী সাথে কথা বলছি care সুতরাং আমি যে পরিস্থিতিটি মোকাবেলা করব তা হ'ল সাবধানতা এড়ানো।

— candied_orange

যদি ক্লায়েন্টটি সত্যই এটির চেষ্টাটি সফল হয় কিনা তা জানা দরকার থাকলে, পদ্ধতিটি কোনও বুলিয়ান ফিরে আসতে পারে। if (!account.AttemptPasswordReset()) /* attempt failed */;এইভাবে ক্লায়েন্ট ফলাফলটি জানে তবে প্রশ্নের সিদ্ধান্তের যুক্তি সহ কিছু বিষয় এড়িয়ে চলে। চেষ্টাটি যদি অ্যাসিক্রোনাস হয় তবে আপনি একটি কলব্যাকটি পাস করবেন pass

— রেডিওডেফ

@ ডেভিডজেড আমরা দু'জনেই ইংরেজিতে কথা বলি। সুতরাং আমি আপনাকে এই মন্তব্যটি দুবার upvote করতে বলতে পারি। এর অর্থ কি আপনি এটি করতে সক্ষম? আমি এটি করার জন্য বলার আগে আপনি কি পারছেন তা আমার জানা দরকার?

— candied_orange

আপনি কি জানেন যে সকলের জন্য কিউপ্যাজ টেক্সস accountএটি নির্মাণের সময় একটি ত্রুটি হ্যান্ডলারটি প্রবেশ করেছিল । পপআপ, লগিং, প্রিন্টআউট এবং অডিও সতর্কতাগুলি এই মুহুর্তে ঘটতে পারে। ক্লায়েন্টের কাজ "এখনই এটি করুন" বলা। এর চেয়ে বেশি কিছু করার দরকার নেই। আপনাকে এক জায়গায় সবকিছু করতে হবে না।

— candied_orange

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

— টম। বোয়েন 89

Answer 3

পটভূমি

উত্তরাধিকার হ'ল একটি শক্তিশালী সরঞ্জাম যা অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ে একটি উদ্দেশ্য পরিবেশন করে। তবে এটি প্রতিটি সমস্যা মার্জিতভাবে সমাধান করে না: কখনও কখনও, অন্যান্য সমাধানগুলি আরও ভাল are

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

এটি একটি গুরুত্বপূর্ণ দক্ষতা যা আমাদের মধ্যেও সবচেয়ে অভিজ্ঞর ভুল হয়: সঠিকভাবে প্রয়োজনীয়তাগুলি সনাক্ত করে এবং সেগুলি মেশিন ভাষায় অনুবাদ করে।

তোমার প্রশ্ন

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

শুধু একটি বস্তু একটি যেমন কারণ accountএকটি অ্যাকাউন্ট টাইপ একটি OO যেমন পণ্য ভাষায় একটি টাইপ মধ্যে যে অনুবাদ মানে এই নয় হয়েছে। একটি মানব ভাষায় "টাইপ" এর অর্থ সর্বদা "শ্রেণি" হয় না। কোনও অ্যাকাউন্টের প্রসঙ্গে, "প্রকার" আরও বেশি ঘনিষ্ঠভাবে "অনুমতি সেট" এর সাথে সম্পর্কিত হতে পারে। আপনি কোনও ক্রিয়া সম্পাদন করতে একটি ব্যবহারকারী অ্যাকাউন্ট ব্যবহার করতে চান তবে সেই ক্রিয়াটি সেই অ্যাকাউন্টের দ্বারা সম্পাদন করতে সক্ষম হতে পারে বা নাও পারে। উত্তরাধিকার ব্যবহারের পরিবর্তে, আমি একটি প্রতিনিধি বা সুরক্ষা টোকেন ব্যবহার করব।

আমার সমাধান

এমন এক অ্যাকাউন্ট ক্লাস বিবেচনা করুন যাতে এটি সম্পাদন করতে পারে এমন বেশ কয়েকটি optionচ্ছিক ক্রিয়া রয়েছে। উত্তরাধিকারের মাধ্যমে "এক্স এক্স এক্স সম্পাদন করতে পারে" পরিবর্তে অ্যাকাউন্টটি কোনও প্রতিনিধি অবজেক্ট (পাসওয়ার্ড রিসেটর, ফর্ম সাবমিটার, ইত্যাদি) বা একটি অ্যাক্সেস টোকন ফিরিয়ে দেয় না কেন?

account.getPasswordResetter().doAction();
account.getFormSubmitter().doAction(view.getContents());

AccountManager.resetPassword(account, account.getAccessToken());

শেষ বিকল্পটির সুবিধাটি যদি আমি অন্যের পাসওয়ার্ডটি পুনরায় সেট করতে আমার অ্যাকাউন্ট শংসাপত্রগুলি ব্যবহার করতে চাই তবে কী হবে ?

AccountManager.resetPassword(otherAccount, adminAccount.getAccessToken());

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

---

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

Comments

আপনি বাক্যাংশটি ব্যবহার না করেও ডিজাইনের জন্য +1 গন্ধ পেয়েছে।

— জ্যারেড স্মিথ

রিসেট পাসওয়ার্ডের ধরণের উপর নির্ভর করে সম্পূর্ণ ভিন্ন যুক্তি রয়েছে এমন ক্ষেত্রে কী হবে? রিসেটপ্যাসওয়ার্ড (পিএসডাব্লুডু) বনাম রিসেটপ্যাসওয়ার্ডটিওর্যান্ডম ()

— দ্য থিক্যাটহিস্পেরার 14

@ দ্য গুগলহিস্পেরার প্রথম উদাহরণ হ'ল "পাসওয়ার্ড পরিবর্তন করুন" যা একটি ভিন্ন পদক্ষেপ। দ্বিতীয় উদাহরণটি আমি এই উত্তরে যা বর্ণনা করছি।

কেন হবে না account.getPasswordResetter().resetPassword();।

— AnoE

The benefit to the last option there is what if I want to use my account credentials to reset someone else's password?.. সহজ। আপনি অন্য অ্যাকাউন্টের জন্য একটি অ্যাকাউন্ট ডোমেন অবজেক্ট তৈরি করেন এবং এটি ব্যবহার করেন। ইউনিট টেস্টিংয়ের জন্য স্ট্যাটিক ক্লাসগুলি সমস্যাযুক্ত (সেই পদ্ধতিটি সংজ্ঞা অনুসারে কিছু স্টোরেজ অ্যাক্সেসের প্রয়োজন হবে, সুতরাং এখন আপনি সহজেই কোনও শ্রেণীর পরীক্ষা করতে পারবেন না যা সেই শ্রেণীর সাথে আরও স্পর্শ করে) এবং সেরা এড়ানো যায়। কিছু অন্যান্য ইন্টারফেস ফিরে আসার বিকল্পটি প্রায়শই একটি ভাল ধারণা তবে অন্তর্নিহিত সমস্যাটির সাথে সত্যিই ডিল করে না (আপনি সমস্যাটি কেবল অন্য ইন্টারফেসে সরিয়ে নিয়েছেন)।

— ভু

Answer 4

বিল ভেনার বলেছেন যে আপনার পদ্ধতির বিষয়টি একেবারে ঠিক আছে ; 'কখন ব্যবহার করবেন উদাহরণস্বরূপ' শিরোনামে বিভাগে যান। আপনি একটি নির্দিষ্ট ধরণের / ইন্টারফেসে ডাউনসকাস্ট করছেন যা কেবলমাত্র সেই নির্দিষ্ট আচরণকেই কার্যকর করে তাই আপনি এটি সম্পর্কে নির্বাচনী হতে একেবারেই সঠিক।

তবে আপনি যদি অন্য কোনও পদ্ধতির ব্যবহার করতে চান তবে ইয়াক শেভ করার বিভিন্ন উপায় রয়েছে।

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

এটি একটি অকার্যকর ফিরে আসতে পারে এবং নিঃশব্দে এটি সম্পূর্ণরূপে পাসওয়ার্ডটি পুনরায় সেট করা হোক বা না করুক, বার্তাটি পাসওয়ার্ডটি পুনরায় সেট না করে তবে অভ্যন্তরীণভাবে বার্তা প্রিন্ট করার দায়িত্ব গ্রহণ করবে। সেরা ধারণা না।

এটি পুনরায় সেটটি সফল হয়েছে কিনা তা বোঝায় এমন একটি বুলিয়ান ফিরে আসতে পারে। সেই বুলিয়ানটি স্যুইচ করে আমরা সেই পাসওয়ার্ড পুনরায় সেট করতে ব্যর্থ হতে পারি।

এটি পাসওয়ার্ড পুনরায় সেট করার প্রচেষ্টার ফলাফলকে নির্দেশ করে একটি স্ট্রিং ফিরিয়ে দিতে পারে। একটি রিসেট কেন ব্যর্থ হয়েছে এবং আউটপুট হতে পারে সে সম্পর্কে স্ট্রিং আরও বিশদ দিতে পারে।

এটি একটি রিসেটরেসল্ট অবজেক্টটি ফিরিয়ে আনতে পারে যা আরও বিশদ জানায় এবং পূর্ববর্তী সমস্ত রিটার্ন উপাদানকে একত্রিত করে।

এটি একটি অকার্যকর ফিরে আসতে পারে এবং পরিবর্তে যদি আপনি এমন কোনও অ্যাকাউন্ট পুনরায় সেট করার চেষ্টা করেন যে তার সক্ষমতা নেই (সাধারণ প্রবাহ নিয়ন্ত্রণের ক্ষেত্রে ব্যতিক্রম হ্যান্ডলিং ব্যবহার করা বিভিন্ন কারণে খারাপ অভ্যাস হয় তবে এটি করবেন না)।

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

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

আপনি কার্যকারিতাটিকে তার নিজস্ব শ্রেণিতে বহিরাগত করার কথা ভাবতে পারেন যা কোনও প্যারামিটার হিসাবে অ্যাকাউন্ট নিতে পারে এবং এটিতে কাজ করতে পারে (উদাহরণস্বরূপ resetter.reset(account)), যদিও এটি প্রায়শই খারাপ অভ্যাসও হয় (একটি সাধারণ উপমা নগদ পেতে আপনার মানিব্যাগে পৌঁছানো একজন দোকানদার)।

সক্ষমতা সহ ভাষাগুলিতে আপনি মিশ্রণ বা বৈশিষ্ট্য ব্যবহার করতে পারেন, তবে আপনি যেখানে শুরু করেছিলেন সেই অবস্থানটিতে আপনি শেষ করতে পারেন যেখানে আপনি এই ক্ষমতাগুলির অস্তিত্বের জন্য যাচাই করতে পারেন।

Comments

সমস্ত অ্যাকাউন্টের পাসওয়ার্ড থাকতে পারে না (যাইহোক এই নির্দিষ্ট সিস্টেমের দৃষ্টিকোণ থেকে)। উদাহরণস্বরূপ অ্যাকাউন্টটি আমার তৃতীয় পক্ষ হতে ... গুগল, ফেসবুক, ect। এটি দুর্দান্ত উত্তর নয় বলে!

— দ্যাটিক্যাটহিস্পেরার

Answer 5

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

class Foo : IResetsPassword {
    //...
}

আপনি অবিলম্বে নির্দিষ্ট করে দিচ্ছেন (সংকলনের সময়) যে আপনার ক্লাসটি ' পাসওয়ার্ড পুনরায় সেট করতে পারে '। তবে, যদি আপনার দৃশ্যে, সামর্থ্যের উপস্থিতি শর্তযুক্ত এবং অন্যান্য বিষয়ের উপর নির্ভর করে, তবে আপনি আর সংকলনের সময় জিনিসগুলি নির্দিষ্ট করতে পারবেন না। তারপরে, আমি এটি করার পরামর্শ দিচ্ছি:

class Foo {

    PasswordResetter passwordResetter;

}

এখন, রানটাইমে, আপনি myFoo.passwordResetter != nullএই অপারেশনটি করার আগে পরীক্ষা করতে পারেন । আপনি যদি আরও বেশি জিনিস ডিকুয়াল করতে চান (এবং আপনি আরও অনেক ক্ষমতা যুক্ত করার পরিকল্পনা করেন), আপনি করতে পারেন:

class Foo {
    //... foo stuff
}

class PasswordResetOperation {
    bool Execute(Foo foo) { ... }
}

class SendMailOperation {
    bool Execute(Foo foo) { ... }
}

//...and you follow this pattern for each new capability...

হালনাগাদ

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

class BaseAccount {
    //...
}
class GuestAccount : BaseAccount {
    //...
}
class UserAccount : BaseAccount, IMyPasswordReset, IEditPosts {
    //...
}
class AdminAccount : BaseAccount, IPasswordReset, IEditPosts, ISendMail {
    //...
}

//Capabilities

interface IMyPasswordReset {
    bool ResetPassword();
}

interface IPasswordReset {
    bool ResetPassword(UserAccount userAcc);
}

interface IEditPosts {
    bool EditPost(long postId, ...);
}

interface ISendMail {
    bool SendMail(string from, string to, ...);
}

এখন, আমি উল্লিখিত সমস্ত বিকল্প বিশ্লেষণ করার চেষ্টা করব:

ওপি দ্বিতীয় উদাহরণ:

if (account.CanResetPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

ধরা যাক এই কোডটি কিছু বেস অ্যাকাউন্ট ক্লাস গ্রহণ করছে (যেমন: BaseAccountআমার উদাহরণে); এটি বেস ক্লাসে বুলিয়ানগুলি tingোকানো হচ্ছে, কোড সহ এটি দূষিত করছে যা এটির কোনও কারণই বোধ করে না this

ওপি প্রথম উদাহরণ:

if (account is IResetsPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

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

ক্যান্ডিডআরঞ্জের আনসার:

account.ResetPassword(authority);

যদি এই ResetPasswordপদ্ধতিটি BaseAccountক্লাসে সন্নিবেশ করা হয় , তবে এটি অপের দ্বিতীয় উদাহরণের মতো অনুপযুক্ত কোড সহ বেস শ্রেণিকেও দূষিত করছে

স্নোম্যানের উত্তর:

AccountManager.resetPassword(otherAccount, adminAccount.getAccessToken());

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

আমার আরেকটি পরামর্শ:

উচ্চ স্তরের শাখার জন্য টেম্পলেট পদ্ধতি প্যাটার্ন ব্যবহার করুন। উল্লিখিত শ্রেণি শ্রেণিবিন্যাসটি যেমন রয়েছে তেমন রাখা হয়; বেস ক্লাসকে কলুষিত করার জন্য ক্যাস্ট এবং অনুপযুক্ত বৈশিষ্ট্য / পদ্ধতিগুলি এড়াতে আমরা কেবলমাত্র অবজেক্টগুলির জন্য আরও উপযুক্ত হ্যান্ডলার তৈরি করি।

//Template method
class BaseAccountOperation {

    BaseAccount account;

    void Execute() {

        //... some processing

        TryResetPassword();

        //... some processing

        TrySendMail();

        //... some processing
    }

    void TryResetPassword() {
        Print("Not allowed to reset password with this account type!");
    }

    void TrySendMail() {
        Print("Not allowed to reset password with this account type!");
    }
}

class UserAccountOperation : BaseAccountOperation {

    UserAccount userAccount;

    void TryResetPassword() {
        account.ResetPassword(...);
    }

}

class AdminAccountOperation : BaseAccountOperation {

    AdminAccount adminAccount;

    override void TryResetPassword() {
        account.ResetPassword(...);
    }

    void TrySendMail() {
        account.SendMail(...);
    }
}

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

Comments

এটি কি সর্বদা "এক্সিকিউট ()" পদ্ধতিটি কার্যকর করার জন্য কাজ করবে তবে কখনও কখনও এটি কিছুই করে না? এটি একটি বিল ফিরিয়ে দেয়, তাই আমি অনুমান করছি যে এটি এটি করেছে বা হয়নি। এটি ক্লায়েন্টের কাছে ফিরে ছুঁড়ে ফেলে: "আমি পাসওয়ার্ডটি পুনরায় সেট করার চেষ্টা করেছি, তবে এটি ঘটেনি (যে কারণেই হোক), এখন আমার উচিত ..."

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

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

— মিয়ামোটো আকিরা

আকর্ষণীয়: শীর্ষ ভোটের উত্তরটি আমার মন্তব্য উপরে যা বলেছে তা মূলত বলে। কিছু দিন আপনি কেবল ভাগ্যবান হন।

@ নোকমপ্রেন্ডে - হ্যাঁ, আমি বেশ কয়েকটি মন্তব্য অনুসারে আমার উত্তর আপডেট করেছি। ফিডব্যাকসটির জন্য ধন্যবাদ :)

— ইমারসন কার্ডোসো

Answer 6

আপনি যে অপশন উপস্থাপন করেছেন তা উভয়ই ভাল ওও নয়। যদি আপনি লিখতে থাকেন তবে যদি কোনও অবজেক্টের ধরণের আশেপাশে বিবৃতি দেওয়া থাকে তবে আপনি সম্ভবত ওও ভুল করছেন (ব্যতিক্রম রয়েছে, এটি এক নয়) আপনার প্রশ্নটির সহজ ওও উত্তর এখানে (বৈধ সি # নাও হতে পারে):

interface IAccount {
  bool CanResetPassword();

  void ResetPassword();

  // Other Account operations as needed
}

public class Resetable : IAccount {
  public bool CanResetPassword() {
    return true;
  }

  public void ResetPassword() {
    /* RESET PASSWORD */
  }
}

public class NotResetable : IAccount {
  public bool CanResetPassword() {
    return false;
  }

  public void ResetPassword() {
    Print("Not allowed to reset password with this account type!");}
  }

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

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

Comments

সমস্ত অ্যাকাউন্ট পুনরায় সেট করা যায় না। এছাড়াও, কোনও অ্যাকাউন্টের পুনরায় সেটযোগ্য হওয়ার চেয়ে আরও কার্যকারিতা থাকতে পারে?

— দ্যাটিক্যাটহিসার

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

— জিমি জেমস

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

— মিয়ামামোটো আকিরা

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

— মিয়ামামোটো আকিরা

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

— কনরাড রুডলফ

Answer 7

উত্তর

আপনার প্রশ্নের আমার সামান্য মতামত উত্তর হ'ল:

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

সংযোজন:

অবজেক্টের ধরণের ব্রাঞ্চিং মন্দ is

অসংলগ্ন

আমি দেখতে পাচ্ছি আপনি c#ট্যাগটি যোগ করেন নি , তবে সাধারণ object-orientedপ্রসঙ্গে জিজ্ঞাসা করছেন ।

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

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

সুতরাং, এই জাতীয় ভাষায় (উদাহরণস্বরূপ রুবি) আপনার কোডটি হয়ে যায়:

account.reset_password

সময়কাল।

accountপারেন পাসওয়ার্ড পুনরায় সেট করবে, একটি "থেকে বঞ্চিত" ব্যতিক্রম নিক্ষেপ, অথবা একটি 'কিভাবে' reset_password 'হ্যান্ডেল করতে জানি না "ব্যতিক্রম নিক্ষেপ করা।

যদি আপনার কোনও কারণেই সুস্পষ্টভাবে শাখা করা দরকার হয় তবে আপনি ক্লাসে নয়, সামর্থ্যের উপর এমনটি করবেন:

account.reset_password  if account.can? :reset_password

(কোথায় can?কেবল এমন একটি পদ্ধতি যা পরীক্ষা করে অবজেক্টটি কোনও পদ্ধতি প্রয়োগ করতে পারে কিনা তা পরীক্ষা করে))

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

Comments

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

— দ্যাটিক্যাটহিস্পেরার

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

— দ্যাটিক্যাটহিস্পেরার

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

— আইএমএসওপি

Answer 8

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

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