নিম্নলিখিত (অ্যান্টি) প্যাটার্নটির নাম কী? তার সুবিধা এবং অসুবিধা কি কি?


28

গত কয়েক মাস ধরে, আমি নিম্নলিখিত কৌশল / প্যাটার্নটি নিয়ে কয়েকবার হোঁচট খেয়েছি। তবে, আমি কোনও নির্দিষ্ট নাম খুঁজে পাচ্ছি না এবং এর সমস্ত সুবিধা এবং অসুবিধাগুলি সম্পর্কে আমি 100% নিশ্চিত নই।

নিদর্শনটি নিম্নরূপ:

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

public interface Vehicle {
    public void accelerate();
    public void decelerate();

    public static class Default {
         public static Vehicle getInstance() {
             return new Car(); // or use Spring to retrieve an instance
         }
    }
 }

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

 Vehicle someVehicle = Vehicle.Default.getInstance();
 someVehicle.accelerate();

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

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

হালনাগাদ:

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

public interface Vehicle {
      public void accelerate();
      public void decelerate();

      public static class Default {
           public static final Vehicle INSTANCE = getInstance();

           private static Vehicle getInstance() {
                return new Car(); // or use Spring/factory here
           }
      }
 }

 // Which allows to retrieve a singleton instance using...
 Vehicle someVehicle = Vehicle.Default.INSTANCE;

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


একরকম একক প্যাটার্ন?
ব্রায়ান চেন

আমি মনে করি আপনি ঠিক বলেছেন যে ইন্টারফেসটি এর প্রয়োগগুলি সম্পর্কে "জানতে" উচিত নয়। সম্ভবত Vehicle.Defaultএকটি কারখানা বর্গ, যেমন যেমন প্যাকেজ নামস্থান মধ্যে সরানো পর্যন্ত দিতে হবে VehicleFactory
আগস্ট

7
যাইহোক,Vehicle.Default.getInstance() != Vehicle.Default.getInstance()
কনরাড মোরাউস্কি

20
এন্টিপ্যাটার্নটি হ'ল অ্যান্টিপ্যাটারি অ্যান্টিপ্যাটার্নটি গাড়ি-অ্যানালজি ব্যবহার করতে হবে, যা প্রাণী-অ্যানালজি অ্যান্টিপ্যাটার্নের সাথে ঘনিষ্ঠভাবে সম্পর্কিত। বেশিরভাগ সফ্টওয়্যারটিতে চাকা বা পা থাকে না।
পিটার বি

@ পিটারবি: :-)))) আপনি আমার দিনটি তৈরি করেছেন!
ডক ব্রাউন

উত্তর:


24

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

এই নির্মাণের ফলে সৃষ্ট মূল সমস্যাটি হ'ল এটি Vehicleএবং এর মধ্যে একটি চক্রীয় নির্ভরতা প্ররোচিত করে Car। উদাহরণস্বরূপ, বর্তমান ফর্মটিতে এটি Vehicleএকটি লাইব্রেরিতে এবং Carঅন্যটিতে স্থাপন করা সম্ভব হবে না । একটি পৃথক কারখানার ক্লাস ব্যবহার করা এবং Default.getInstanceসেখানে পদ্ধতিটি স্থাপন করা সমস্যার সমাধান করবে। সিলেটলেটের সাথে সম্পর্কিত কোনও বিভ্রান্তি রোধ করার জন্য সেই পদ্ধতিটিকে একটি আলাদা নাম দেওয়াও ভাল ধারণা হতে পারে। সুতরাং ফলাফল কিছু হতে পারে

VehicleFactory.createDefaultInstance()


আপনার উত্তরের জন্য ধন্যবাদ! আমি সম্মত হই যে এই নির্দিষ্ট উদাহরণটি এসআরপি লঙ্ঘন। তবে, বাস্তবায়ন গতিশীলভাবে পুনরুদ্ধার করা সেক্ষেত্রে এটি এখনও লঙ্ঘন কিনা তা আমি নিশ্চিত নই। উদাহরণস্বরূপ একটি কনফিগারেশন ফাইল দ্বারা নির্দিষ্ট কোনও উদাহরণ পুনরুদ্ধার করার জন্য স্প্রিং (বা অনুরূপ কাঠামো) ব্যবহার করে ।
Jérôme

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

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

গাড়ি যদি খুব সাধারণ, যানবাহনের মানক প্রয়োগ হয় তবে এটি এসআরপি লঙ্ঘন নয়। যানবাহনটির এখনও পরিবর্তনের একমাত্র কারণ রয়েছে, যেমন যখন গুগল কোনও autodrive()পদ্ধতি যুক্ত করে। আপনার অতি জেনেরিক গাড়িটি অবশ্যই সেই পদ্ধতিটি বাস্তবায়নের জন্য অবশ্যই পরিবর্তন করতে হবে, উদাহরণস্বরূপ একটি নোটিপ্লিমেন্টেড এক্সেপশন নিক্ষেপ করে, তবে এটি যানবাহনে পরিবর্তন করার অতিরিক্ত কারণ প্রদান করে না
user949300

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

3

এটি আমার কাছে নাল অবজেক্ট প্যাটার্নের মতো দেখাচ্ছে ।

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

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


2
হ্যালো এবং উত্তরের জন্য ধন্যবাদ। যদিও আমি বেশ নিশ্চিত যে আমার ক্ষেত্রে এটি "নাল অবজেক্ট" প্যাটার্নটি প্রয়োগ করতে ব্যবহৃত হয়নি, এটি একটি আকর্ষণীয় ব্যাখ্যা।
Jérôme
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.