ইন্টারফেসের জন্য কংক্রিটের ক্লাসগুলির উপর নির্ভর করা কি ঠিক আছে?

আমি কাস্টম ত্রুটি হ্যান্ডলারের জন্য জাভাতে ইন্টারফেস তৈরি করছি।

একটি আর্গুমেন্ট ত্রুটি বস্তুটি পাস করতে চাই তবে আমার এটি Exceptionক্লাসের শিশু হওয়া দরকার ।

কোনও ইন্টারফেসে আমার সংজ্ঞায়িত শ্রেণীর নামটি ব্যবহার করা কি ঠিক আছে?

এটি কোনও প্রয়োগের উপর নির্ভরশীল না হওয়ার শর্তে এটি কোনও ইন্টারফেসকে কম তৈরি করবে না?

আমি এরকম কিছু করার চেষ্টা করি:

public class CustomException {
    /* ... Implementation ... */
}

public interface Interface {

    void onError(CustomException ex);

}

— nikachx
সূত্র

আপনি কি জিজ্ঞাসার চেষ্টা করছেন যে কোনও ইন্টারফেসে অন্য শ্রেণির উত্তরাধিকারী হওয়া ঠিক আছে কিনা?

— স্নুপ

@ স্টেভিভ নং, আমি প্রশ্নটি সম্পাদনা করেছি, দেখুন।

— নিকচেক্স

@AndresF। এটি কেবলমাত্র একটি উদাহরণ এবং ইন্টারফেসে ক্লাস ব্যবহার সম্পর্কে যে কোনও ওও ভাষায় প্রয়োগ করা যেতে পারে।

— নিকচেক্স

আমাকে বলুন: CustomExceptionবাস্তবায়ন বা ইন্টারফেসের অংশ?

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

@nikachx আপনি "নিরাপদ" বলতে কী বুঝছেন তা আমি বুঝতে পারি না। কোন উপায়ে Stringনিরাপদ CustomException? CustomExceptionপরিবর্তে, যদি অন্যান্য নির্ভরতা থাকে তবে তা কেন গুরুত্বপূর্ণ ?

— আন্দ্রেস এফ।

উত্তর:

প্রথমে আমি সত্যটি CustomExceptionপ্রকাশ করতে চাই যা প্রসারিত হয় না Exceptionতাই এটি আসলে একটি নয় Exception।

বলেছিল:

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

অপরপক্ষে:

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

বিকল্প 1

CustomExceptionবিমূর্ত করুন
void onError(CustomException ex)যেমন আছে তেমন রাখুন

বিকল্প 2

CustomExceptionএকটি ইন্টারফেস তৈরি করুন
void onError(CustomException ex)যেমন আছে তেমন রাখুন

এই বিকল্পগুলির যে কোনওটির সাথে আপনি ডিআইপি সাপেক্ষে যাবেন, যেহেতু ইন্টারফেসটি কোনও কংক্রিট শ্রেণির উপর নির্ভর করে না, কেবল বিমূর্ততার উপর on

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

চতুর সফ্টওয়্যার বিকাশ, নীতিমালা,> নিদর্শন এবং অনুশীলনসমূহ। প্রেন্টিস হল. পৃষ্ঠা 127–131। আইএসবিএন 978-0135974445।

— তুলিনেস কর্ডোভা
সূত্র

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

— জ্যাকব রায়হলে

@ জ্যাকবআরইহলে বাস্তবায়নে হার্ড-কোডেড একটি উদাহরণ পাস করার অর্থ কী?

— তুলাইনস কর্ডোভা

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

— জ্যাকব রায়হলে

@ জ্যাকোব্রাইহলে "নির্ভরতা বিপরীতকরণের প্রত্যক্ষ প্রয়োগে, বিমূর্তগুলি উপরের / নীতি স্তরগুলির মালিকানাধীন architect এই আর্কিটেকচারটি উচ্চ / নীতি উপাদান এবং বিমূর্ত যা একই প্যাকেজে নিম্ন পরিষেবাদি সংজ্ঞায়িত করে। নিম্ন স্তরের স্তর তৈরি করা হয় এই বিমূর্ত শ্রেণি বা ইন্টারফেসের উত্তরাধিকার / প্রয়োগ দ্বারা "" মার্টিন, রবার্ট সি। (2003)। চতুর সফ্টওয়্যার বিকাশ, নীতি, প্যাটার্নস এবং অনুশীলনসমূহ। প্রেন্টিস হল. পৃষ্ঠা 127–131। আইএসবিএন 978-0135974445।

— তুলাইনস কর্ডোভা

আপনি যদি যুক্তিসঙ্গত ডিফল্ট সরবরাহ করতে পারেন তবে একটি বিমূর্ত শ্রেণীর বিন্দুটি কী? আপনি কি তা হারাতে পারেন ? শুধু বই উদ্ধৃতি করবেন না, ভাবেন।

— জ্যাকব রায়হলে

Tulains সঠিক - ইন্টারফেস সব সময় কংক্রিট ক্লাস উপর নির্ভর করে। এগুলি কেবল তাদের নিজস্ব উদ্বেগের জন্য একটি চুক্তি তৈরি করার উদ্দেশ্যে। এই চুক্তিতে কোনও ধরণের ডেটা নেওয়া এবং ফেরত জড়িত থাকতে পারে।

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

— সাভা বি।
সূত্র

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

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

আপনার যদি প্রসঙ্গের উপর নির্ভর করে আলাদা ব্যতিক্রম ব্যবহার করতে হয় তবে আপনি জেনেরিকগুলি ব্যবহারে আগ্রহী হতে পারেন।

— আরসেনি মরজেনকো
সূত্র

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

— নিকচেক্স

ওপি প্রশ্ন জিজ্ঞাসা করা উত্তরগুলি ... একটি মন্তব্যে জিজ্ঞাসা করুন, তারপরে আপনার উত্তর সরবরাহ করুন।

— স্নুপ

@ স্টেভিভ: প্রথম অনুচ্ছেদে আরও একটি বাকবিতণ্ডিত প্রশ্ন ছিল। এবং ওপির মন্তব্যে যেমন দেখানো হয়েছে, আমি আসলে ওপি-র প্রশ্নের উত্তর দিয়েছি।

— আর্সেনি মরজেনকো