ইন্টারফেসের ভবিষ্যতে ব্যবহারের জন্য প্রোগ্রামিং

42

আমার পাশে একজন সহকর্মী বসে আছেন যিনি এই জাতীয় ইন্টারফেসটি ডিজাইন করেছেন:

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

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

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

এখন, আমার প্রশ্নটি হ'ল এমন কোনও উত্স আছে যা "সম্মানিত" কোডিং গুরুদের মতো কোনও বিষয় পরিচালনা করছে যা আমরা তাকে লিঙ্ক করতে পারি?

java object-oriented-design interfaces

— sveri
সূত্র

29

"ভবিষ্যদ্বাণী করা খুব কঠিন, বিশেষত ভবিষ্যতের বিষয়ে।"

— জার্গ ডব্লু মিট্টাগ

10

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

— ডোভাল

5

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

— রামি

3

জাভা 8 ডিফল্ট পদ্ধতিতে অপ্রয়োজনীয় যুক্তি যুক্ত করার কোনও কারণ নেই। ডিফল্ট প্রয়োগের সাথে পরে একটি পদ্ধতি যুক্ত করা যেতে পারে যা বলুন, এর সাথে সংজ্ঞায়িত কলকে সহজ করে null। প্রয়োগকারী ক্লাসগুলি প্রয়োজন অনুযায়ী ওভাররাইড করতে পারে।

— বোরিস স্পাইডার

1

@ ডোভাল আমি জাভা সম্পর্কে জানিনা, তবে। নেট মধ্যে আপনি কখনও কখনও এমন কিছু জিনিস দেখতে পাবেন যেমন IQueryableডালের বাইরে কোডের (কেবলমাত্র কিছু নির্দিষ্ট অভিব্যক্তি নিতে পারে) এড়াতে বাড়াতে এড়াতে

— বেন আারনসন

62

YAGNI সম্পর্কে জানতে তাকে আমন্ত্রণ জানান । উইকিপিডিয়া পৃষ্ঠার যৌক্তিক অংশটি এখানে বিশেষ আকর্ষণীয় হতে পারে:

যারা YAGNI পদ্ধতির পক্ষে ছিলেন তাদের মতে, কোডটি লেখার প্রলোভন যা এই মুহুর্তে প্রয়োজনীয় নয়, তবে ভবিষ্যতেও হতে পারে, নিম্নলিখিত অসুবিধাগুলি রয়েছে:

ব্যয় করা সময়টি প্রয়োজনীয় কার্যকারিতা যুক্ত, পরীক্ষা করা বা উন্নত করা থেকে নেওয়া হয়।

নতুন বৈশিষ্ট্যগুলি অবশ্যই ডিবাগ, ডকুমেন্টেড এবং সমর্থিত হতে হবে।

যে কোনও নতুন বৈশিষ্ট্য ভবিষ্যতে কী করা যায় তাতে বাধা আরোপ করে, সুতরাং একটি অপ্রয়োজনীয় বৈশিষ্ট্য ভবিষ্যতে প্রয়োজনীয় বৈশিষ্ট্যগুলি যুক্ত হতে বাধা দিতে পারে।

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

এটি কোড ফোলা বাড়ে; সফ্টওয়্যারটি আরও বড় এবং জটিল হয়ে ওঠে।

নির্দিষ্টকরণ এবং কোনও ধরণের সংশোধন নিয়ন্ত্রণ না থাকলে বৈশিষ্ট্যটি প্রোগ্রামারদের জানা থাকতে পারে না যারা এটি ব্যবহার করতে পারে।

নতুন বৈশিষ্ট্য যুক্ত করা অন্য নতুন বৈশিষ্ট্যগুলির পরামর্শ দিতে পারে। যদি এই নতুন বৈশিষ্ট্যগুলি পাশাপাশি প্রয়োগ করা হয় তবে এর ফলে বৈশিষ্ট্যটি ভঙ্গুর দিকে তুষারবল প্রভাব পড়তে পারে।

অন্যান্য সম্ভাব্য যুক্তি:

"এক টুকরো সফটওয়্যারের আজীবন ব্যয়ের 80% রক্ষণাবেক্ষণে যায়" । ঠিক সময়ে কোড রাইটিং রক্ষণাবেক্ষণের ব্যয় হ্রাস করে: একজনকে কম কোড বজায় রাখতে হবে এবং কোডটি আসলে প্রয়োজনীয় কোডটিতে ফোকাস করতে পারে।
উত্স কোডটি একবার লেখা হয়, তবে কয়েক ডজন বার পড়ে। একটি অতিরিক্ত যুক্তি, কোথাও ব্যবহৃত হয় না, কারণ কেন প্রয়োজন হয় না এমন একটি যুক্তি রয়েছে তা বোঝার জন্য সময় নষ্ট হবে। প্রদত্ত যে এটি বেশ কয়েকটি সম্ভাব্য বাস্তবায়নের একটি ইন্টারফেস যা জিনিসগুলিকে কেবল আরও কঠিন করে তোলে।
উত্স কোডটি স্ব-ডকুমেন্টিং হিসাবে প্রত্যাশিত। প্রকৃত স্বাক্ষর বিভ্রান্তিমূলক, যেহেতু একজন পাঠক মনে করবেন endএটি ফলশ্রুতি বা পদ্ধতির প্রয়োগকে প্রভাবিত করে।
এই ইন্টারফেসের কংক্রিট বাস্তবায়ন লেখার লোকেরা বুঝতে পারে না যে শেষ যুক্তিটি ব্যবহার করা উচিত নয়, যা বিভিন্ন পদ্ধতির দিকে পরিচালিত করে:
1. আমার দরকার নেই end, তাই আমি কেবল এর মানটিকে এড়িয়ে যাব,
2. আমার দরকার নেই end, তাই আমি যদি ব্যতিক্রম না হয় তবে বাদ দিয়ে দেব null,
3. আমার দরকার নেই end, তবে এটি কোনওভাবে ব্যবহার করার চেষ্টা করব,
4. আমি প্রচুর কোড লিখব যা পরে যখন endপ্রয়োজন হবে তখন ব্যবহার হবে।

তবে সচেতন হন যে আপনার সহকর্মী সঠিক হতে পারে।

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

এইচজেকের উত্তরটি একটি ভাল সমাধান দেয়: ইতিমধ্যে ব্যবহৃত ইন্টারফেসে একটি পদ্ধতি যুক্ত করা খুব কঠিন নয়, তবে কিছু ক্ষেত্রে এর ব্যয়ও খুব বেশি:

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

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

4

আমি মনে করি ভবিষ্যতে এই বৈশিষ্ট্যটি সম্ভবত প্রদর্শিত হতে পারে তা বিবেচনা করাও গুরুত্বপূর্ণ important যদি আপনি নির্দিষ্টভাবে জানেন তবে এটি যুক্ত করা হবে তবে এখনই নয় যে কারণেই হোক না কেন আমি বলব এটি কেবল "ক্ষেত্রে" বৈশিষ্ট্য নয় বলে মনে রাখা ভাল যুক্তি।

— জেরোইন ভেনেভেল

3

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

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

26

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

(একটু পরে)

public class EventGetter implements IEventGetter {

    private static final Date IMPLIED_END_DATE_ASOF_20140711 = new Date(Long.MAX_VALUE); // ???

    @Override
    public List<FooType> getFooList(String fooName, Date start) throws Exception {
        return getFooList(fooName, start, IMPLIED_END_DATE_ASOF_20140711);
    }

    @Override
    public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception {
        // Final implementation goes here
    }
}

আপনার কেবল এটিই দরকার, পদ্ধতি ওভারলোডিং। ভবিষ্যতে অতিরিক্ত পদ্ধতিটি বিদ্যমান পদ্ধতির কলগুলিকে প্রভাবিত না করে স্বচ্ছভাবে চালু করা যেতে পারে।

— hjk
সূত্র

6

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

— কিভেলি

1

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

— hjk

18

[সেখানে কি "সম্মানিত" কোডিং গুরু রয়েছে যা আমরা তাকে [তাকে রাজি করানোর জন্য] লিঙ্ক করতে পারি?

কর্তৃপক্ষের কাছে আবেদনগুলি বিশেষভাবে বিশ্বাসযোগ্য নয়; যে যুক্তিই বলুক না কেন বৈধ যুক্তি উপস্থাপন করা আরও ভাল।

এখানে এমন একটি কমানোর বিজ্ঞাপন বিহীন যা আপনার সহকর্মী সংবেদনশীলতা নির্বিশেষে "ডান" হতে আটকে আছে তা বোঝাতে বা বোঝাতে পারে:

আপনার যা দরকার তা হ'ল

getFooList(String fooName, Date start, Date end, Date middle, 
           Date one_third, JulianDate start, JulianDate end,
           KlingonDate start, KlingonDate end)

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

— MSW
সূত্র

22

You never know when you'll have to internationalize for Klingon। এজন্য আপনার কেবল একটি পাস করা উচিত Calendar, এবং ক্লায়েন্ট কোডটি সিদ্ধান্ত নিতে দিন যে তিনি একটি GregorianCalendarবা একটি প্রেরণ করতে চান KlingonCalendar(আমি বাজি রেখেছি কিছু ইতিমধ্যে একটি করেছে)। Duh। :-p

— এসজুয়ান 76

3

কি StarDate sdStartএবং StarDate sdEnd? আমরা ফেডারেশনকে সর্বোপরি ভুলতে পারি না ...

— ওয়ার্নারসিডি

এগুলি সমস্তই স্পষ্টত হয় হয় সাবক্লাস বা রূপান্তরিত Date!

— দারখোগ

শুধুমাত্র যদি এটি সহজ ছিল ।

— এমএসডাব্লু

@ এমএসডাব্লু, আমি নিশ্চিত নই যে তিনি "সম্মানিত কোডিং গুরুদের" লিঙ্ক চাইলে তিনি "কর্তৃপক্ষের কাছে আবেদন" চেয়েছিলেন। যেমনটি আপনি বলছেন, তাঁর "একটি যুক্তি প্রয়োজন যা এটি বৈধ হোক না কেন এটি বলেছিল"। "গুরু" -ধর্মী লোকেরা তাদের অনেক কিছু জানার প্রবণতা রাখে। এছাড়াও আপনি ভুলে গেছেন HebrewDate startএবং HebrewDate end।

— ট্রাইসিস

12

একটি সফ্টওয়্যার ইঞ্জিনিয়ারিং দৃষ্টিকোণ থেকে, আমি বিশ্বাস করি যে এই ধরণের সমস্যার সঠিক সমাধান নির্মাতা প্যাটার্নে in এটি অবশ্যই আপনার সহকর্মী http://en.wikedia.org/wiki/Builder_ Pattern এর জন্য 'গুরু' লেখকের একটি লিঙ্ক ।

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

আপনার উদাহরণটি হয়ে উঠবে:

public interface IEventGetter {
    public List<FooType> getFooList(ISearchFooRequest req) {
        throws Exception;
    ....
    }
}

public interface ISearchFooRequest {
        public String getName();
        public Date getStart();
        public Date getEnd();
        public int getOffset();
        ...
    }
}

public class SearchFooRequest implements ISearchFooRequest {

    public static SearchFooRequest buildDefaultRequest(String name, Date start) {
        ...
    }

    public String getName() {...}
    public Date getStart() {...}
    ...
    public void setEnd(Date end) {...}
    public void setOffset(int offset) {...}
    ...
}

— InformedA
সূত্র

3

এটি একটি ভাল সাধারণ পদ্ধতির, কিন্তু এই ক্ষেত্রে শুধু থেকে সমস্যা ধাক্কা বলে মনে হয় IEventGetterকরতে ISearchFootRequest। আমি পরিবর্তে public IFooFilterসদস্যের সাথে এমন কিছু প্রস্তাব দেব public bool include(FooType item)যা আইটেমটি অন্তর্ভুক্ত করবে কিনা তা ফেরত দেয়। তারপরে স্বতন্ত্র ইন্টারফেস বাস্তবায়নগুলি কীভাবে তারা এই ফিল্টারিং করবেন তা সিদ্ধান্ত নিতে পারে

— বেন অ্যারনসন

@Ben Aaronson আমি শুধু সম্পাদন করা কোড প্রদর্শিত কিভাবে অনুরোধ পরামিতি বস্তুর তৈরি করা হয়

— InformedA

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

— অ্যারোনআট

7

আপনার এখন দরকার নেই, সুতরাং এটি যুক্ত করবেন না। আপনার যদি পরে এটির প্রয়োজন হয় তবে ইন্টারফেসটি প্রসারিত করুন:

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start)
         throws Exception;
    ....

}

public interface IBoundedEventGetter extends IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

— ToddR
সূত্র

বিদ্যমান (এবং সম্ভবত ইতিমধ্যে পরীক্ষিত / চালিত) ইন্টারফেস পরিবর্তন না করার জন্য +1

— সেবাস্তিয়ান গোডলেট

4

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

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

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

যেহেতু আপনার এখনও প্রয়োজনীয়তা নেই, সেই পরামিতিটি কী ধরণের হবে তা আপনার জানার কোনও উপায় নেই। আপনার প্রায়শই হয় আপনার কাছে কোনও বিশ্রী ইন্টারফেস থাকে যা আপনার প্রয়োজনের জন্য সবচেয়ে উপযুক্ত নয়, বা যেকোন উপায়ে এটি পরিবর্তন করতে হবে।

— কার্ল বিলেফেল্ট
সূত্র

2

এই প্রশ্নের উত্তর দেওয়ার জন্য পর্যাপ্ত তথ্য নেই। এটি নির্ভর করে getFooListআসলে কী করে এবং কীভাবে এটি করে।

এখানে এমন কোনও পদ্ধতির স্পষ্ট উদাহরণ রয়েছে যা অতিরিক্ত পরামিতি ব্যবহার করা উচিত, ব্যবহৃত উচিত used

void CapitalizeSubstring (String capitalize_me, int start_index);

এমন কোনও পদ্ধতির প্রয়োগ যা কোনও সংকলনে কাজ করে যেখানে আপনি সূচনাটি নির্দিষ্ট করতে পারেন তবে সংগ্রহের শেষটি প্রায় বোকা।

আপনাকে সত্যিই সমস্যাটি দেখতে হবে এবং পুরো ইন্টারফেসের প্রেক্ষাপটে প্যারামিটারটি অযৌক্তিক কিনা এবং অতিরিক্ত প্যারামিটারটি কতটা বোঝা চাপিয়ে দেয় তা জিজ্ঞাসা করতে হবে।

— QuestionC
সূত্র

1

আমি ভয় করি আপনার সহকর্মীর আসলে খুব কার্যকর বৈধ পয়েন্ট থাকতে পারে। যদিও তার সমাধানটি সর্বোত্তম নয়।

তার প্রস্তাবিত ইন্টারফেস থেকে এটি পরিষ্কার যে

public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception;

সময়ের ব্যবধানে সময়ের মধ্যে পাওয়া উদাহরণগুলি ফিরিয়ে দিচ্ছে। যদি ক্লায়েন্টরা বর্তমানে শেষ প্যারামিটারটি ব্যবহার না করে তবে এটি সময়ের ব্যবধানের মধ্যে খুঁজে পাওয়া উদাহরণগুলি প্রত্যাশা করে এমনটি পরিবর্তন করে না। এর অর্থ হ'ল বর্তমানে সমস্ত ক্লায়েন্ট খোলা সমাপ্ত বিরতি ব্যবহার করে (শুরু থেকে অনন্তকাল পর্যন্ত)

সুতরাং একটি ভাল ইন্টারফেস হবে:

public List<FooType> getFooList(String fooName, Interval interval) throws Exception;

যদি আপনি একটি স্থিতিশীল কারখানার পদ্ধতি সহ অন্তর সরবরাহ করেন:

public static Interval startingAt(Date start) { return new Interval(start, null); }

তাহলে ক্লায়েন্টরাও শেষ সময় নির্দিষ্ট করার প্রয়োজন অনুভব করবে না।

একই সাথে আপনার ইন্টারফেসটি আরও সঠিকভাবে এটি যা getFooList(String, Date)করে তা জানায় , যেহেতু এটি কোনও আন্তঃব্যক্তির সাথে যোগাযোগ করে তা যোগাযোগ করে না।

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

— bowmore
সূত্র

0

অব্যবহৃত প্যারামিটার যুক্ত করা বিভ্রান্তিকর। এই বৈশিষ্ট্যটি কার্যকর হবে ধরে নিয়ে লোকেরা সেই পদ্ধতিটিকে কল করতে পারে।

আমি এটি যোগ করা হবে না। এটি একটি রিফ্যাক্টরিং এবং যান্ত্রিকভাবে কল সাইটগুলি ঠিক করে ব্যবহার করে এটি যুক্ত করা তুচ্ছ। স্ট্যাটিকালি টাইপ করা ভাষায় এটি করা সহজ। আগ্রহের সাথে এটি যুক্ত করার প্রয়োজন নেই।

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

— usr ডিরেক্টরির
সূত্র