একে অপরের পরিপ্রেক্ষিতে দুটি জাভা 8 ডিফল্ট পদ্ধতি প্রয়োগ করা কি ভাল অনুশীলন?

Question

আমি এর সাথে দুটি সম্পর্কিত পদ্ধতিযুক্ত একটি ইন্টারফেস ডিজাইন করছি:

public interface ThingComputer {
    default Thing computeFirstThing() {
        return computeAllThings().get(0);
    }

    default List<Thing> computeAllThings() {
        return ImmutableList.of(computeFirstThing());
    }
}

প্রায় অর্ধেকটি বাস্তবায়ন কেবল একটি জিনিস গণনা করবে, অন্য অর্ধেকটি আরও বেশি গুণতে পারে।

এর কি বহুল ব্যবহৃত জাভা 8 কোডের কোনও নজির আছে? আমি জানি হাস্কেল কিছু টাইপচ্লায় ( Eqউদাহরণস্বরূপ) একই কাজ করে।

উল্টোটি হল আমার দুটি বিমূর্ত ক্লাস ( SingleThingComputerএবং MultipleThingComputer) থাকলে তার তুলনায় আমাকে উল্লেখযোগ্যভাবে কম কোড লিখতে হবে ।

অবক্ষয়টি হ'ল একটি খালি বাস্তবায়ন সংকলন করে তবে রানটাইমটিতে একটি সহ ফুরিয়ে যায় StackOverflowError। এটির মাধ্যমে পারস্পরিক পুনরাবৃত্তি সনাক্ত করা ThreadLocalএবং একটি ভাল ত্রুটি দেওয়া সম্ভব, তবে এটি নন-বাগি কোডে ওভারহেড যুক্ত করে।

Comments

আপনি কেন ইচ্ছাকৃতভাবে অসীম পুনরাবৃত্তি হওয়ার গ্যারান্টিযুক্ত কোড লিখবেন? এর থেকে ভাল কিছুই আসতে পারে না।

আচ্ছা এটি "গ্যারান্টিযুক্ত" নয়; একটি যথাযথ বাস্তবায়ন এই পদ্ধতিগুলির মধ্যে একটিকে ওভাররাইড করে।

— তাভিয়ান বার্নস

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

আমি @ স্নোমানের সাথে একমত, এটি একটি ল্যান্ডমাইন। আমি এটা পাঠ্যপুস্তক "মন্দ কোড" অর্থে যে জন স্কিট মানে মনে করি - দয়া করে মনে রাখবেন মন্দ হিসাবে একই নয় খারাপ , এটা দুষ্ট এর / চালাক / প্রলুব্ধকর, কিন্তু এখনও ভুল :) আমি সুপারিশ youtu.be/lGbQiguuUGc?t=15m26s ( বা প্রকৃতপক্ষে, বিস্তৃত প্রসঙ্গে পুরো আলাপ - এটি খুব আকর্ষণীয়)।

— কনরাড মোরাউস্কি

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

— জিমি হোফা

Answer 1

টিএল; ডিআর: এটি করবেন না।

আপনি এখানে যা দেখান তা হ'ল ভঙ্গুর কোড।

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

ত্রুটি বা সাবক্লাস নিক্ষেপ করা একটি গুরুতর ত্রুটি নির্দেশ করে যা ধরা উচিত নয়:

একটি ত্রুটি থ্রোয়েবলের একটি সাবক্লাস যা গুরুতর সমস্যাগুলি নির্দেশ করে যা যুক্তিসঙ্গত প্রয়োগটি ধরার চেষ্টা করা উচিত নয়।

তদ্ব্যতীত, স্ট্যাকওভারফ্লো এরর এর পিতাম শ্রেণি ভার্চুয়ালম্যাচাইন ইরর এটি বলে:

জাভা ভার্চুয়াল মেশিনটি ভাঙ্গা হয়েছে বা এটি চালিয়ে যাওয়ার জন্য প্রয়োজনীয় সংস্থানগুলি শেষ হয়ে গেছে তা বোঝাতে নিক্ষিপ্ত হয়।

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

---

এমিরিটাস হিসাবে "সি সি ল্যাঙ্গুয়েজ ডিজাইন কমিটির সদস্য" হিসাবে এই প্রচেষ্টা থেকে আপনি এরিক লিপার্টকে চেনেন । তিনি ভাষাগুলির বৈশিষ্ট্যগুলি সম্পর্কে লোকদের সাফল্য বা ব্যর্থতার দিকে ঠেলে দিচ্ছেন: যদিও এটি কোনও ভাষা বৈশিষ্ট্য বা ভাষা নকশার অংশ নয়, ইন্টারফেস প্রয়োগ করার সময় বা অবজেক্টগুলি ব্যবহার করার ক্ষেত্রে তাঁর বক্তব্যটি সমানভাবে বৈধ।

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

^{_{উত্স: সি ++ এবং হতাশার পিট}}

একটি ইন্টারফেস থাকলে StackOverflowErrorডিফল্টরূপে বিকাশকারীদের হতাশার গর্তে ফেলে দেয় এবং এটি খারাপ ধারণা । পরিবর্তে, বিকাশকারীদের সাফল্যের গর্তের দিকে ধাক্কা দিন । আপনার ইন্টারফেসটি সঠিকভাবে এবং JVM ক্রাশ না করে ব্যবহার করা সহজ করুন ।

পদ্ধতিগুলির মধ্যে ডেলিগেট করা এখানে ঠিক আছে। তবে নির্ভরতা এক পথে যেতে হবে go আমি নির্দেশিত গ্রাফের মতো পদ্ধতি প্রতিনিধিদের ভাবতে চাই । প্রতিটি পদ্ধতি গ্রাফের একটি নোড। প্রতিবার কোনও পদ্ধতি অন্য পদ্ধতিতে কল করে, কল করার পদ্ধতি থেকে কল হওয়া পদ্ধতিতে একটি প্রান্ত আঁকুন।

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

Comments

দুর্দান্ত উত্তর। আমি কৌতূহলী যে কেন হাসকেলের মধ্যে এটি এত সাধারণ প্রচলন। বিভিন্ন দেব সংস্কৃতি আমার ধারণা।

— তাভিয়ান বার্নস

আমি হাস্কেল-তে অভিজ্ঞ নই এবং ফাংশনাল প্রোগ্রামিংয়ে এটি কেন বা বেশি হয় তা নিয়ে কথা বলতে পারি না।

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

— তাবিয়ান বার্নস

বেশিরভাগ ক্রিয়ামূলক প্রোগ্রামিং ভাষাগুলিতে টেল কল অপ্টিমাইজেশন রয়েছে। এই অপ্টিমাইজেশনের সাথে, লেজ পুনরাবৃত্তি স্ট্যাকটি ফুঁকবে না, এই জাতীয় অনুশীলনগুলি বোঝায়।

— জেসন ইয়ো