ইন্টারফেস বিভাজন নীতিটি কি কংক্রিট পদ্ধতিতে প্রযোজ্য?

Question

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

তবে কংক্রিট পদ্ধতি সম্পর্কে কীভাবে? প্রত্যেক ক্লায়েন্ট ব্যবহার না করে এমন পদ্ধতিগুলি কি আমার আলাদা করা উচিত? নিম্নলিখিত শ্রেণীর বিবেচনা করুন:

public class Car{
    ....

    public boolean isQualityPass(){
        ...
    }

    public int getTax(){
        ...
    }

    public int getCost(){
        ...
    }
}

public class CarShop{
    ...
    public int getCarPrice(int carId){
        Car car=carList[carId];
        int price=car.getTax() + car.getCost()... (some formula);
        return price;
    }
}

উপরের কোডে, কার্শপ কারে মোটেও পদ্ধতিটি কোয়ালিটিপাস () ব্যবহার করে না, আমি কি কিউসপাসটি () কে নতুন শ্রেণিতে বিভক্ত করব:

public class CheckCarQualityPass{
    public boolean isQualityPass(Car car){
    }
}

কারশপের মিলন কমাতে? কারণ আমি একবারে মনে করি যদি আইকুয়েলটিপাস () এর অতিরিক্ত নির্ভরতার প্রয়োজন হয়, যেমন:

public boolean isQualityPass(){
    HttpClient client=...
}

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

Comments

"গাড়ী" পাস করার সময় কোনও গাড়ি কি সাধারণত জানেন? বা এটি সম্ভবত একটি ব্যবসার নিয়ম যা এটি নিজের দ্বারা আবদ্ধ হতে পারে?

— লাইভ

আইএসপিতে শব্দটি ইন্টারফেসটি বোঝায় এটি ইন্টারফেস সম্পর্কে । তাই আপনি যদি আপনার একটি পদ্ধতি আছে Carবর্গ যে আপনি চান না (সমস্ত) ব্যবহারকারীদের জানতে সম্পর্কে তারপর (একটির বেশি) তৈরি ইন্টারফেস যে Carবর্গ কার্যকরী একটি যা শুধুমাত্র ইন্টারফেসগুলি প্রেক্ষাপটে দরকারী পদ্ধতি ঘোষণা।

— টিমোথি ট্রকল

@ লাইভ আমি নিশ্চিত যে আমরা এমন যানবাহন দেখতে যাচ্ছি যা খুব শীঘ্রই এর চেয়ে আরও বেশি কিছু জানে। ;)

— ইউনিফাইড মডেলিং স্যান্ডউইচ

একটি গাড়ি তার নির্মাতা তাকে কী জানতে চায় তা জানবে। ভক্সওয়াগেন জানেন আমি কী সম্পর্কে বলছি :-)

— লাইভ

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

— নীল

Answer 1

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

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

যদি isQualityPassসহজেই অন্য কোনও শ্রেণিতে স্থানান্তরিত না করা যায় তবে বিকল্পটি হ'ল নির্মাণের সময় Httpএকটি বিমূর্ত ইন্টারফেসের মাধ্যমে কলগুলি IHttpClientকরা Carবা পুরো "কোয়ালিটিপাস" পরীক্ষণ কৌশলটি (এইচটিটিপি অনুরোধটি এনক্যাপসুলেটেড) ইনজেকশনের মাধ্যমে Carঅবজেক্টে করা উচিত the । তবে এটি কেবলমাত্র দ্বিতীয় সেরা সমাধান আইএমএইচও, কারণ এটি হ্রাস করার পরিবর্তে সামগ্রিক জটিলতা বাড়ায়।

Comments

কিউটিপাস পদ্ধতিটি সমাধান করার কৌশল কৌশল সম্পর্কে কী বলা যায়?

— লাইভ

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

— ডক ব্রাউন

Answer 2

সুতরাং আমার প্রশ্নটি হ'ল: ইন্টারফেস-বিভাজন নীতি অনুসারে, আমি কি কংক্রিটের পদ্ধতিগুলি পৃথক করব যা প্রতিটি ক্লায়েন্ট ব্যবহার করবে না, যাতে এই পদ্ধতিগুলি কেবল ক্লায়েন্টের উপর নির্ভর করে যখন ক্লায়েন্ট প্রকৃতপক্ষে সংযোগ হ্রাস করতে পারে?

ইন্টারফেস পৃথককরণের নীতিটি আপনার যা প্রয়োজন তা অ্যাক্সেসকে অস্বীকার করার বিষয়ে নয়। এটি আপনার যা প্রয়োজন তা অ্যাক্সেস করার জন্য জোর না দেওয়ার বিষয়ে।

ইন্টারফেসগুলি শ্রেণীর মালিকানাধীন নয় যা তাদের প্রয়োগ করে। এগুলি তাদের ব্যবহার করে এমন বস্তুর মালিকানাধীন।

public class CarShop{
    ...
    public int getCarPrice(int carId){
        Car car=carList[carId];
        int price=car.getTax() + car.getCost()... (some formula);
        return price;
    }
}

এখানে কী ব্যবহৃত হয় তা getTax()এবং getCost()। যার উপর জোর দেওয়া হচ্ছে তা হ'ল সমস্ত কিছু যা অ্যাক্সেসযোগ্য Car। সমস্যাটির Carঅর্থ হ'ল এটির অ্যাক্সেসের জন্য জোর দেওয়া isQualityPass()হচ্ছে যার প্রয়োজন নেই।

এটি স্থির করা যেতে পারে। আপনি জিজ্ঞাসা করুন এটি দৃ concrete়ভাবে স্থির করা যায় কিনা। এটা হতে পারে.

public class CarShop{
    ...
    public int getCarPrice(int carId){
        CarLiability carLiability=carLiabilityList[carId];
        int price=carLiability.getTax() + carLiability.getCost()... (some formula);
        return price;
    }
}

এমনকি এই কোডটির কোনওটিই জানে না CarLiabilityকোনও ইন্টারফেস বা কংক্রিটের শ্রেণি কিনা । সেটা একটা ভাল জিনিস. এটি জানতে চায় না।

যদি এটি কোনও ইন্টারফেস হয় তবে এটি Carপ্রয়োগ করতে পারে। এটি আইএসপি লঙ্ঘন করবে না যদিও isQuality()এটি Car CarShopথাকাতে এটি জিদ দেয় না। এটা ঠিকাসে.

যদি এটি কংক্রিট isQuality()হয় তবে এটি হতে পারে যে কোনওটিই নেই বা অন্য কোথাও চলে গেছে। এটা ঠিকাসে.

এটি এমনও হতে পারে যে CarLiabilityএটি একটি কংক্রিটের মোড়কের কাছাকাছি Carযা এটিকে কাজ দেয়। তাই দীর্ঘ CarLiabilityদেখাবে না তা isQuality()তারপর CarShopজরিমানা। অবশ্যই এটি কেবল কিকটিকে রাস্তায় নামায় এবং CarLiabilityকীভাবে Carএকইভাবে আইএসপি অনুসরণ CarShopকরতে হবে তা নির্ধারণ করতে হবে।

সংক্ষেপে, আইএসপি-এর কারণে isQuality()অপসারণের প্রয়োজন নেই Car। প্রয়োজনের অপ্রয়োজনীয় প্রয়োজনগুলি isQuality()অপসারণ করা উচিত CarShopকারণ CarShopএটির প্রয়োজন নেই, সুতরাং এটির জন্য এটি চাওয়া উচিত নয়।

Answer 3

ইন্টারফেস বিভাজন নীতিটি কি কংক্রিট পদ্ধতিতে প্রযোজ্য?

তবে কংক্রিট পদ্ধতি সম্পর্কে কীভাবে? প্রত্যেক ক্লায়েন্ট ব্যবহার না করে এমন পদ্ধতিগুলি কি আমার আলাদা করা উচিত?

আসলে তা না. এতে কি লুকানোর বিভিন্ন উপায় আছে Car.isQualityPassথেকে CarShop।

1. অ্যাক্সেস পরিবর্তনকারী

থেকে Demeter এর আইন দৃষ্টিকোণ, আমরা বিবেচনা করতে পারে Carএবং CardShopহতে না বন্ধুদের । এটি আমাদের পরবর্তী কাজটি করার বৈধতা দেয়।

package com.my.package.domain.model
public class Car{
    ...
    protected boolean isQualityPass(){...}
}

package com.my.package.domain.services
public class CarShop{
    ...
}

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

2. ইন্টারফেস বিভাজন

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

প্রকৃত Carবাস্তবায়ন সত্ত্বেও , আইএসপি অনুশীলন থেকে আমাদের কিছুই থামায় না।

//role interfaces 
public interface Billable{
   public int getCosts();
   public int getTaxs();
}

//role interfaces
public interface QualityAssurance{
   public boolean isQualityPass();
}

public class Car implements Billable, QualityAssurance{
   ...
}

public class CarShop {
  ...
  public int getPrice(Billable billable){
     return billable.getCosts() * billable.getTaxs();
  }
}

আমি এখানে কি করেছি। বিল ইন্টারফেস রোল ইন্টারফেসের মধ্যে Carএবং এর CarShopমধ্য দিয়ে আমি ইন্টারঅ্যাকশনটিকে সংকুচিত করেছি । স্বাক্ষরের পরিবর্তন সম্পর্কে সচেতন হন । আমি ইচ্ছাকৃতভাবে যুক্তি সংশোধন করেছি। আমি স্পষ্ট করে তুলতে চেয়েছিলাম যে এটি উপলব্ধ রোল ইন্টারফেসগুলির মধ্যে একটির সাথে "আবদ্ধ / আবদ্ধ" । আমি প্রকৃত বাস্তবায়ন অনুসরণ করতে পারতাম তবে বাস্তব বাস্তবায়ন বিবরণ জানি না এবং কংক্রিটের ক্লাসে প্রকৃতর অ্যাক্সেস (দৃশ্যমানতা) রয়েছে তা সম্পর্কে আমি ভীত । যদি এটি থাকে তবে আইএসপি দিয়ে করা সমস্ত কাজ অকেজো হয়ে যায় কারণ ingালাই করা এবং কেবল ইন্টারফেস বিলেবল দিয়ে কাজ করা বিকাশকারীর হাতে রয়েছে । আমরা যতই পদ্ধতিগত হই না কেন, প্রলোভনটি সর্বদা সেখানেই থাকবে।getPriceCarShopgetPrice(String carId)

3. একক দায়িত্ব

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

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

সাতরে যাও

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