বৈশিষ্ট্যের পরিবর্তে অ্যাবস্ট্রাক্ট ক্লাস ব্যবহার করে কী সুবিধা?


371

বৈশিষ্ট্যের পরিবর্তে (পারফরম্যান্স বাদে) একটি অ্যাবস্ট্রাক্ট ক্লাস ব্যবহারের সুবিধা কী? দেখে মনে হচ্ছে বিমূর্ত ক্লাসগুলি বেশিরভাগ ক্ষেত্রে বৈশিষ্ট্যের দ্বারা প্রতিস্থাপন করা যেতে পারে।

উত্তর:


371

আমি দুটি পার্থক্য চিন্তা করতে পারেন

  1. বিমূর্ত শ্রেণিতে কনস্ট্রাক্টর প্যারামিটার পাশাপাশি টাইপ পরামিতি থাকতে পারে। বৈশিষ্ট্যে কেবলমাত্র টাইপ পরামিতি থাকতে পারে। কিছু আলোচনা ছিল যে ভবিষ্যতে এমনকি বৈশিষ্ট্যেও কনস্ট্রাক্টর প্যারামিটার থাকতে পারে
  2. অ্যাবস্ট্রাক্ট ক্লাসগুলি জাভার সাথে পুরোপুরি আন্তঃযোগিতাযোগ্য। আপনি জাভা কোড থেকে কোনও মোড়ক ছাড়াই তাদের কল করতে পারেন। বৈশিষ্ট্যগুলি কেবলমাত্র যদি কোনও প্রয়োগের কোড না থাকে তবে সম্পূর্ণরূপে আন্তঃযোগযোগ্য

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

15
জীবনকাল: "যদি কোনও প্রয়োগের কোড না থাকে তবেই বৈশিষ্ট্যগুলি সম্পূর্ণরূপে আন্তঃযোগাযোগ্য"
ওয়ালরাস দ্য ক্যাট

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

5
ভাবুন, দ্বিতীয় পার্থক্য জাভা 8 এ বিদ্যমান নেই।
ডুং নগুইন

14
স্কেল ২.২১ অনুযায়ী, একটি জাভা 8 ইন্টারফেসের জন্য একটি বৈশিষ্ট্য সংকলন করা হয়েছে - স্কালাআলাং.আর.আরউজ / নিউজ ২২.২.২.২০ #traits - compile- to - interfaces
কেভিন মেরিডেথ

209

স্কালায় প্রোগ্রামিংয়ের একটি বিভাগ রয়েছে যার নাম "বৈশিষ্ট্য, না বৈশিষ্ট্য নয়?" যা এই প্রশ্নে সম্বোধন করে। যেহেতু 1 ম এড অনলাইনে উপলব্ধ, আমি আশা করছি এটি এখানে পুরো জিনিসটি উদ্ধৃত করা ঠিক আছে। (যে কোনও গুরুতর স্কালার প্রোগ্রামার বইটি কিনতে হবে):

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

যদি আচরণটি পুনরায় ব্যবহার না করা হয় , তবে এটি একটি কংক্রিট শ্রেণি করুন। এটি সর্বোপরি পুনরায় ব্যবহারযোগ্য আচরণ নয়।

যদি এটি একাধিক, অপ্রাসঙ্গিক শ্রেণিতে পুনরায় ব্যবহার করা হয় তবে এটিকে একটি বৈশিষ্ট্য হিসাবে গড়ে তুলুন। শ্রেণি শ্রেণিবিন্যাসের বিভিন্ন অংশে কেবল বৈশিষ্ট্যগুলি মিশ্রিত করা যায়।

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

আপনি যদি এটি সঙ্কলিত আকারে বিতরণ করার পরিকল্পনা করেন এবং আপনি বাইরের গোষ্ঠীগুলি এর উত্তরাধিকার সূত্রে ক্লাস লেখার প্রত্যাশা করেন তবে আপনি একটি বিমূর্ত শ্রেণীর ব্যবহারের দিকে ঝুঁকতে পারেন। সমস্যাটি হ'ল যখন কোনও বৈশিষ্ট্য কোনও সদস্য লাভ করে বা হারায়, সেখান থেকে উত্তরাধিকারসূত্রে প্রাপ্ত কোনও শ্রেণি অবশ্যই পরিবর্তিত না হলেও পুনরায় সংযুক্ত করতে হবে। যদি বাইরের ক্লায়েন্টরা কেবল তার থেকে উত্তরাধিকার সূত্রে পরিবর্তিত হয়ে আচরণে ডাকে, তবে বৈশিষ্ট্যটি ব্যবহার করা ভাল using

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

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

@ মুশতাক আহমেদ যেমন উল্লেখ করেছেন, তেমন একটি বৈশিষ্ট্যের দ্বারা কোনও শ্রেণীর প্রাথমিক নির্মাতাকে কোনও পরামিতি দেওয়া যেতে পারে না।

আর একটি পার্থক্য হ'ল চিকিত্সা super

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

আরও বিশদ জানতে 12 অধ্যায়ের বাকী অংশটি দেখুন ।

সম্পাদনা 1 (2013):

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

সম্পাদনা 2 (2018):

স্কেল ২.১২ অনুসারে, বৈশিষ্ট্যের দ্বিপাক্ষিক সামঞ্জস্যের আচরণটি পরিবর্তিত হয়েছে। 2.12 এর আগে, কোনও সদস্যকে যোগ করা বা অপসারণের জন্য বৈশিষ্ট্যের উত্তরাধিকারী সমস্ত শ্রেণীর বৈশিষ্ট্য পুনরায় সংকলন প্রয়োজন, এমনকি শ্রেণিগুলি পরিবর্তন না হলেও। এটি জেভিএমে যেভাবে বৈশিষ্ট্যগুলি এনকোড করা হয়েছিল তার কারণেই এটি।

স্কেল ২.১২ অনুসারে, বৈশিষ্ট্যগুলি জাভা ইন্টারফেসগুলির সাথে সংকলন করে , তাই প্রয়োজনীয়তাটি কিছুটা শিথিল হয়েছে। বৈশিষ্ট্যগুলি নিম্নলিখিত কোনও কাজ করে থাকলে, এর সাবক্লাসগুলি এখনও পুনঃসংশোধনের প্রয়োজন:

  • ক্ষেত্রগুলি সংজ্ঞায়িত ( valবা var, তবে একটি ধ্রুবক ঠিক আছে - final valফলাফলের ধরণের ছাড়াই)
  • কলিং super
  • শরীরে প্রারম্ভিক বিবৃতি
  • একটি ক্লাস প্রসারিত
  • সঠিক সুপাররেটে প্রয়োগগুলি সন্ধান করতে লিনিয়ারীকরণের উপর নির্ভর করা

তবে যদি বৈশিষ্ট্যটি না করে, আপনি এখন বাইনারি সামঞ্জস্যতা না ভেঙে এটি আপডেট করতে পারবেন।


2
If outside clients will only call into the behavior, instead of inheriting from it, then using a trait is fine- এখানে কেউ পার্থক্য কি তা ব্যাখ্যা করতে পারে? extendsবনাম with?
0fnt

2
@ 0fnt তাঁর পার্থক্য বনাম বর্ধিত সম্পর্কে নয়। তিনি যা বলছেন তা হ'ল আপনি যদি একই সংকলনের মধ্যে কেবল বৈশিষ্টটিতে মিশ্রিত হন তবে বাইনারি সামঞ্জস্যের সমস্যাগুলি প্রযোজ্য না। যাইহোক, যদি আপনার এপিআইটি ব্যবহারকারীদের নিজস্ব বৈশিষ্ট্যগুলিতে মিশ্রিত করার মঞ্জুরি দেওয়ার জন্য ডিজাইন করা হয় তবে আপনাকে বাইনারি সামঞ্জস্যতা নিয়ে চিন্তা করতে হবে।
জন কোলান্ডুইনি

2
@ 0fnt আছে: মধ্যে একেবারে কোন শব্দার্থিক পার্থক্য নেই extendsএবং with। এটি নিখুঁত বাক্য গঠনমূলক। আপনি যদি একাধিক টেম্পলেট থেকে উত্তরাধিকারী হন তবে প্রথমটি extendপাবেন with, অন্যরা সমস্ত পাবেন , এটি। চিন্তা করুন withএকটি কমা হিসাবে: class Foo extends Bar, Baz, Qux
জার্গ ডব্লু মিতাগ

77

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


20

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

অ্যাবস্ট্রাক্ট ক্লাস এবং বৈশিষ্ট্যের মধ্যে পার্থক্য সম্পর্কে থমাসের উত্তর থেকে :

trait A{
    def a = 1
}

trait X extends A{
    override def a = {
        println("X")
        super.a
    }
}  


trait Y extends A{
    override def a = {
        println("Y")
        super.a
    }
}

scala> val xy = new AnyRef with X with Y
xy: java.lang.Object with X with Y = $anon$1@6e9b6a
scala> xy.a
Y
X
res0: Int = 1

scala> val yx = new AnyRef with Y with X
yx: java.lang.Object with Y with X = $anon$1@188c838
scala> yx.a
X
Y
res1: Int = 1

9

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


এর কি কোনও ব্যবহারিক প্রভাব আছে, বা এটি কেবল কোডটি বুঝতে সহজ করে তোলে?
রালফ

8

ইন প্রোগ্রামিং Scala লেখক বিমূর্ত শ্রেণীর করতে যে একটি শাস্ত্রীয় অবজেক্ট ওরিয়েন্টেড "হয়-একটি" সম্পর্ক যখন বৈশিষ্ট্যগুলো রফা a Scala একমুখী হয় বলে।


5

বিমূর্ত শ্রেণিগুলিতে আচরণ থাকতে পারে - তারা কনস্ট্রাক্টর আরগগুলি (যা বৈশিষ্ট্যগুলি পারে না) দিয়ে পরামিতি করতে পারে এবং একটি কার্যকারী সত্তাকে উপস্থাপন করে। পরিবর্তে বৈশিষ্ট্যগুলি কেবল একটি একক বৈশিষ্ট্যকে উপস্থাপন করে যা একটি কার্যকারিতার ইন্টারফেস।


8
আশা করি আপনি বোঝাচ্ছেন না যে বৈশিষ্ট্যে আচরণ থাকতে পারে না। উভয়ই প্রয়োগের কোড থাকতে পারে।
মিচ ব্লিভিনস

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

4
@ ডারিও আমি "আচরণ" এবং "কার্যকারিতা" সমার্থক শব্দ হিসাবে দেখছি, তাই আপনার উত্তরটি আমি খুব বিভ্রান্তিকর বলে মনে করি।
ডেভিড জে।

3
  1. একটি শ্রেণি একাধিক বৈশিষ্ট্য থেকে উত্তরাধিকারী হতে পারে তবে কেবল একটি বিমূর্ত শ্রেণি।
  2. বিমূর্ত শ্রেণিতে কনস্ট্রাক্টর প্যারামিটার পাশাপাশি টাইপ পরামিতি থাকতে পারে। বৈশিষ্ট্যে কেবলমাত্র টাইপ পরামিতি থাকতে পারে। উদাহরণস্বরূপ, আপনি বৈশিষ্ট্য টি (i: Int) say} বলতে পারবেন না; আই প্যারামিটারটি অবৈধ।
  3. অ্যাবস্ট্রাক্ট ক্লাসগুলি জাভার সাথে পুরোপুরি আন্তঃযোগিতাযোগ্য। আপনি জাভা কোড থেকে কোনও মোড়ক ছাড়াই তাদের কল করতে পারেন। বৈশিষ্ট্যগুলি কেবলমাত্র যদি কোনও প্রয়োগের কোড না থাকে তবে সম্পূর্ণরূপে আন্তঃযোগযোগ্য।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.