নামকরণের বিষয়গুলি: "কিছু" এর জন্য "আইসমোথিং" নামকরণ করা উচিত? [বন্ধ]


68

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

আসুন নিম্নলিখিতটি ধরে নিই:

  • ইন্টারফেস ব্যবহার মূলত নির্ভরতা ইনজেকশনের মাধ্যমে পরীক্ষাযোগ্যতা অর্জন করা to
  • অনেক ক্ষেত্রে, এর ফলে একক প্রয়োগকারী সাথে একক ইন্টারফেস থাকে

সুতরাং, উদাহরণস্বরূপ, এই দুটি নামকরণ করা উচিত? Parserএবং ConcreteParser? Parserএবং ParserImplementation?

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

বা এই জাতীয় একক বাস্তবায়ন ক্ষেত্রে এই পরামর্শটি উপেক্ষা করা উচিত?


30
এটি এটিকে কোনও ধর্মের থেকে কম করে না। আপনি কারণ অনুসন্ধান করবেন, কেবলমাত্র কেউ এক্স ওয়াই বলেছে না
মাইক ডুনলাভে

35
@ মাইকডুনলাভে এবং এটাই প্রশ্নের কারণ!
ভিনকো ভার্সালোভিক

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

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

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

উত্তর:


191

"আঙ্কেল বব" সহ অনেকেই Iইন্টারফেসের উপসর্গ হিসাবে ব্যবহার না করার পরামর্শ দেন , এটি করা সি # এর সাথে একটি সুপ্রতিষ্ঠিত traditionতিহ্য। সাধারণ কথায় এটি এড়ানো উচিত। তবে আপনি যদি সি # লিখছেন, আপনার অবশ্যই সেই ভাষার সম্মেলনগুলি অনুসরণ করা এবং এটি ব্যবহার করা উচিত। এটি না করা সি # এর সাথে পরিচিত অন্য যে কেউ আপনার কোডটি পড়ার চেষ্টা করে তাদের সাথে বিভ্রান্তি সৃষ্টি করবে।


মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।
maple_shaft

9
আপনি "সাধারণভাবে এটি এড়ানো উচিত" এর কোনও ভিত্তি সরবরাহ করেন না। জাভাতে, আমার এড়ানো উচিত। সি # তে এটি গ্রহণ করা উচিত। অন্যান্য ভাষা তাদের নিজস্ব সম্মেলন অনুসরণ করে follow
বেসিক

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

39

ইন্টারফেসটি গুরুত্বপূর্ণ যৌক্তিক ধারণা, সুতরাং, ইন্টারফেসটি জেনেরিক নামটি বহন করে। সুতরাং, আমি বরং ছিল

interface Something
class DefaultSomething : Something
class MockSomething : Something

চেয়ে

interface ISomething
class Something : ISomething
class MockSomething : ISomething

পরেরটির কয়েকটি যুক্তি রয়েছে:

  1. কিছু হ'ল আইসোমথিংয়ের কেবলমাত্র একটি বাস্তবায়ন, তবুও এটি জেনেরিক নামটি এমন, যেন এটি কোনওরকম বিশেষ।
  2. মকসোমথিং কিছু থেকে প্রাপ্ত বলে মনে হচ্ছে, তবুও আইসোমিংটি প্রয়োগ করে। সম্ভবত এটির নাম মকিসোমথিং করা উচিত, তবে আমি বুনোতে কখনও দেখিনি।
  3. রিফ্যাক্টরিং কঠিন। যদি কিছু এখন ক্লাস হয় এবং আপনি কেবল পরে জানতে পারেন যে আপনাকে একটি ইন্টারফেস প্রবর্তন করতে হবে, সেই ইন্টারফেসটির নামকরণ করা উচিত, কারণ ক্লায়েন্টদের কাছে এটি স্বচ্ছ হওয়া উচিত যে প্রকারটি একটি কংক্রিট শ্রেণি, একটি বিমূর্ত শ্রেণি বা ইন্টারফেস কিনা clients । কিছু যে বিরতি।

59
আপনি কেন সি # প্রদান করে এমন সু-প্রতিষ্ঠিত মান অনুসরণ করবেন না? আপনার অনুসরণকারী প্রতিটি সি # প্রোগ্রামারকে বিভ্রান্ত ও বিরক্তিকর ব্যয় ছাড়িয়ে যাওয়া এই কী উপকারটি করে?
রবার্ট হার্ভে

6
@ ওয়ালেনবারন এটি ঠিক আছে, তবে বাস্তবিকভাবে আপনি কেবলমাত্র একটি ইন্টারফেসের একক বৈধ বাস্তবায়ন করতে পারেন, কারণ ইউনিট পরীক্ষাগুলিতে মকব্যাকের জন্য ইন্টারফেস ব্যবহার করা সাধারণ। আমি লাগাতে চাই না Defaultবা Realবা Implআমার ক্লাসের নাম অনেক মধ্যে
বেন Aaronson

4
আমি আপনার সাথে একমত, তবে আপনি যদি এই রাস্তাটি ভ্রমণ করেন তবে আপনাকে সি # এর জন্য তৈরি প্রতিটি লিটারের সাথে লড়াই করতে হবে।
রাবারডাক

3
আমি ইন্টারফেস হিসাবে একই নামের সাথে একটি তাত্ক্ষণিক ক্লাস থাকাতে কোনও সমস্যা দেখছি না যদি ইন্টারফেস বাস্তবায়ন করে এমন বেশিরভাগ দৃষ্টান্তই সেই শ্রেণি হয়। উদাহরণস্বরূপ, প্রচুর কোডের একটি সাধারণ-উদ্দেশ্য বাস্তবায়ন প্রয়োজন IList<T>এবং এটি অভ্যন্তরীণভাবে কীভাবে সঞ্চিত থাকে তা সত্যিই যত্নশীল নয়; কেবলমাত্র ল্যাপটপ করতে সক্ষম Iএবং ব্যবহারযোগ্য শ্রেণীর নাম থাকতে পারার ম্যাজিকভাবে জানা (জাভা হিসাবে) যে কোডটি List<T>ব্যবহার করা উচিত তার একটি সাধারণ বাস্তবায়ন চায় তার চেয়েও ভাল লাগে ArrayList<T>
সুপারক্যাট

2
@ আর্টবি কারণগুলি কয়েক। এক, কোনও ভাষা নেই যেখানে কনভেনশনটি ক্লাসের মতো একটি দুর্দান্ত সংক্ষিপ্ত চিহ্নিতকারী CFoo : Foo। সুতরাং যে বিকল্পটি সত্যিই উপলব্ধ নয়। দ্বিতীয়ত, আপনি তখন একটি অদ্ভুত অসঙ্গতি পান কারণ কিছু শ্রেণীর মার্কার থাকবে এবং অন্যরা একই ইন্টারফেসের অন্যান্য বাস্তবায়ন হতে পারে কি না তার উপর নির্ভর করে । CFoo : Fooকিন্তু SqlStore : Store। এটি আমার একটি সমস্যা Impl, যা মূলত কেবল একটি কুশল চিহ্নিতকারী। বোধহয় যদি সর্বদা একটি C(বা যা কিছু) যোগ করার সম্মেলনে কোনও ভাষা থাকত, তবে এটির চেয়ে ভাল হতে পারেI
বেন অ্যারনসন

27

এটি কেবল নামকরণের নাম নয় isn't সি # একাধিক উত্তরাধিকারকে সমর্থন করে না তাই হাঙ্গেরিয়ান স্বরলিপি ব্যবহারের এই উত্তরাধিকার ব্যবহারের একটি ছোট উপকারী সুবিধা রয়েছে যেখানে আপনি বেস ক্লাস থেকে উত্তরাধিকারী হন এবং এক বা একাধিক ইন্টারফেস প্রয়োগ করছেন। তাই এটা...

class Foo : BarB, IBarA
{
    // Better...
}

... এটি তার চেয়ে ভাল ...

class Foo : BarB, BarA
{
    // Dafuq?
}

আইএমও


7
এটি লক্ষণীয় যে জাভা ক্লাস উত্তরাধিকার এবং ইন্টারফেস বাস্তবায়নের জন্য বিভিন্ন কীওয়ার্ড, অর্থাৎ inheritsবনামের সাথে খুব সুন্দরভাবে এই সমস্যাটি এড়িয়ে চলে implements
কনরাড রুডল্ফ

6
@KonradRudolph আপনি কি বলতে চান extends
অরেঞ্জডগ

2
@ অ্যান্ডি যুক্ত হওয়া মানটি হ'ল আমরা হাঙ্গেরিয়ান নোটেশন ক্রাফট এড়াতে পারি, তবুও এই উত্তরে বর্ণিত সমস্ত স্পষ্টতা সংরক্ষণ করতে পারি।
কনরাড রুডল্ফ

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

1
@ অ্যান্ডি ... আপনি যদি কোনও শ্রেণীর উত্তরাধিকারী হন তবে তালিকায় এটি প্রথম হওয়া আবশ্যক এটি দুর্দান্ত তবে উপসর্গ ছাড়া আপনি জানতে পারবেন না আপনি কয়েকটি ইন্টারফেস বা বেস ক্লাস এবং একটি ইন্টারফেস নিয়ে কাজ করছেন কিনা ...
রবি ডি

15

না না না.

নামকরণের কনভেনশনগুলি আপনার চাচা বব অবজ্ঞার কোনও কাজ নয়। এগুলি ভাষার কোনও ক্রিয়া নয়, সি # বা অন্যথায়।

এগুলি আপনার কোড বেসের একটি ফাংশন। আপনার দোকানের অনেক কম পরিমাণে। অন্য কথায় কোড বেসের প্রথমটি মান নির্ধারণ করে।

তবেই আপনি সিদ্ধান্ত নিতে পারেন। তারপরে ঠিক সামঞ্জস্যপূর্ণ হতে হবে। যদি কেউ অসঙ্গতিপূর্ণ হতে শুরু করে তবে তারা তাদের অসম্পূর্ণ বন্দুকটি কেড়ে নিন এবং অনুতপ্ত না হওয়া পর্যন্ত তাদের ডকুমেন্টেশন আপডেট করুন।

একটি নতুন কোড বেস পড়ার সময় আমি যদি কোনও Iউপসর্গ না দেখি তবে ভাষা নির্বিশেষে আমি ভাল আছি। আমি যদি প্রতিটি ইন্টারফেসে একটি দেখতে পাই তবে আমি ভাল আছি। আমি যদি মাঝে মাঝে একটি দেখতে পাই তবে কেউ অর্থ দিতে চলেছে।

আপনি যদি নিজের কোড বেসের জন্য এই নজিরটি স্থাপনের বিরল প্রসঙ্গে নিজেকে খুঁজে পান তবে আমি আপনাকে এটি বিবেচনা করার জন্য অনুরোধ করছি:

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

আপনি যদি Iসেই নামে কোনও ছিনতাই করেন তবে ক্লায়েন্টের কোনও যত্ন নেই। যদি না থাকে I, ক্লায়েন্ট যত্ন করে না। এটি যার সাথে কথা বলছে তা কংক্রিট হতে পারে। এটা নাও পারে। যেহেতু এটি এটি কোনওভাবেই কল করে না newএটি কোনও তাত্পর্য রাখে। ক্লায়েন্ট হিসাবে, আমি জানি না। আমি জানতে চাই না।

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

সম্ভবত এটি আপনার পক্ষে একটি অ ইস্যু। হয়তো না. যদি তা হয় তবে এটি যত্নের এক ভাল কারণ। তবে ডেস্ক খেলনাগুলির প্রেমের জন্য দাবি করবেন না যে আমাদের কেবল অন্ধভাবে এটি করা উচিত কারণ এটি কিছু ল্যাঙ্গুয়েজে এটি করা হয়েছিল। হয় খুব খারাপ কারণ আছে বা যত্ন নেই don't

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


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

আপনি যদি সি # ব্যবহার করছেন তবে আপনি সেগুলি দেখতে পাচ্ছেন I। যদি আপনার কোডগুলি সেগুলি ব্যবহার করে, আপনি এগুলি সর্বত্র দেখতে পাবেন। যদি আপনার কোডগুলি সেগুলি ব্যবহার না করে তবে আপনি ফ্রেমওয়ার্ক কোড থেকে তাদের দেখতে পাবেন যা আপনি চান না এমন মিশ্রণের দিকে নিয়ে যায়।
সেবাস্তিয়ান রেডল

8

জাভা এবং সি # এর মধ্যে একটি ছোট পার্থক্য রয়েছে যা এখানে প্রাসঙ্গিক। জাভাতে, প্রতিটি সদস্যই ডিফল্টরূপে ভার্চুয়াল। সি # তে, প্রতিটি সদস্যই পূর্বনির্ধারিতভাবে সিল করা হয় - ইন্টারফেস সদস্যদের ব্যতীত।

এই অনুমানগুলি যা গাইডলাইনটির উপর প্রভাব ফেলে - জাভাতে, প্রতিটি পাবলিক প্রকারকে লিসকোভের সাবস্টিটিউশন নীতিমালা [1] অনুসারে চূড়ান্তভাবে বিবেচনা করা উচিত। আপনার যদি কেবল একটি বাস্তবায়ন থাকে তবে আপনি শ্রেণীর নাম রাখবেন Parser; যদি আপনি দেখতে পান যে আপনার একাধিক বাস্তবায়ন প্রয়োজন, আপনি কেবল ক্লাসটি একই নামের একটি ইন্টারফেসে পরিবর্তন করবেন এবং কংক্রিট বাস্তবায়নটির নাম বর্ণনামূলক কিছুতে রাখবেন।

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

কার্যকারিতার জন্য অ-আই-প্রিফিক্সড নামটি ছেড়ে দেওয়ার ক্ষেত্রে একটি দুর্দান্ত ব্যবহারযোগ্যতা বৈশিষ্ট্যও রয়েছে যা ইন্টারফেসটিকে একটি বিমূর্ত শ্রেণি তৈরি না করেই ইন্টারফেসের সাথে সম্পর্কিত which (যা সি # তে ক্লাসের একাধিক-উত্তরাধিকারের অভাবে ক্ষতিগ্রস্থ হবে)। এটি লিনকিউ দ্বারা জনপ্রিয় হয়েছিল, যা IEnumerable<T>ইন্টারফেস Enumerableহিসাবে এবং সেই ইন্টারফেসের জন্য প্রযোজ্য পদ্ধতিগুলির একটি সংগ্রহস্থল হিসাবে ব্যবহৃত হয়। এটি জাভাতে অপ্রয়োজনীয়, যেখানে ইন্টারফেসগুলিতে পদ্ধতি প্রয়োগকরণও থাকতে পারে।

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

আমি ধরে নিয়েছি যে চাচা বব এর যুক্তি কিছু ছিল:

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

আপনি যদি আপনার নমুনা IParserইন্টারফেসে এটি প্রয়োগ করেন তবে আপনি পরিষ্কারভাবে দেখতে পাবেন যে বিমূর্তিটি পুরোপুরি "অর্থহীন" অঞ্চলে রয়েছে। উভয় ক্ষেত্রেই একটা পার্সার (যেমন একটি কংক্রিট বাস্তবায়ন সম্পর্কে কিছু নির্দিষ্ট JsonParser, XmlParser, ...), অথবা আপনি শুধু একটি বর্গ ব্যবহার করা উচিত। "ডিফল্ট বাস্তবায়ন" বলে কোনও জিনিস নেই (যদিও কিছু পরিবেশে এটি সত্যই উপলব্ধি করে - উল্লেখযোগ্যভাবে, COM) হয় হয় একটি নির্দিষ্ট প্রয়োগ রয়েছে, বা আপনি "ডিফল্ট" এর জন্য একটি বিমূর্ত শ্রেণি বা এক্সটেনশন পদ্ধতি চান want তবে, সি # তে, যদি না আপনার কোডবেস ইতিমধ্যে Iপ্রিফিক্স বাদ দেয় , রাখুন। আপনি যখনই কোডটি দেখতে পান class Something: ISomethingতখনই একটি মানসিক নোট তৈরি করুন - এর অর্থ কেউ YAGNI অনুসরণ এবং যুক্তিসঙ্গত বিমূর্ততা তৈরি করতে খুব ভাল নয়।

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


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

@ কনরাডরুডল্ফ আমি এই সম্পর্কিত একটি পাদটীকা যুক্ত করেছি; প্রতিক্রিয়াটির জন্য ধন্যবাদ :)
লুয়ান

4

সুতরাং, উদাহরণস্বরূপ, এই দুটি নামকরণ করা উচিত? পার্সার এবং কংক্রিটপার্সার? পার্সার এবং পার্সার বাস্তবায়ন?

আদর্শ বিশ্বে আপনার নিজের নামটি ছোট হাতের ("আমি ...") দিয়ে উপস্থাপন করা উচিত নয় তবে কেবল নামটিকে একটি ধারণা প্রকাশ করতে দেওয়া উচিত।

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

অন্য কথায়, সম্মেলনটি জিনিসগুলির নামকরণের অসুবিধাটিকে সহজতর করে দেয় এবং সহজভাবে আউট আউট করা সহজভাবে ভুল


বাস্তব বিশ্বে, আপনার কোডের ক্লায়েন্টদের (যা কেবল "ভবিষ্যতে আপনি হতে পারেন") পরে এটি পড়তে সক্ষম হতে হবে এবং যত তাড়াতাড়ি সম্ভব (বা যত কম প্রচেষ্টা সহ) তার সাথে পরিচিত হতে হবে (ক্লায়েন্টদের দিতে আপনার কোডটি তারা কী পেতে পারে) of

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


*) আমি এই দৃ saying়তার সাথে বলতে পারি "ক্রাফ্ট" যাইহোক কোনও সঠিক ধারণা নয় :)


2

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

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

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

এই কিভাবে উদাহরণস্বরূপ, হয় Set<T>, HashSet<T>এবং TreeSet<T>নামকরণ করা হয়।


5
সি # তেও ইন্টারফেস পছন্দ করা হয়। আপনাকে কে বলেছিল যে ডটনেটে কংক্রিটের ধরণগুলি ব্যবহার করা বেশি পছন্দ?
রাবারডাক

@ রাবারডাক ভাষা আপনার উপর চাপিয়ে দেওয়ার কিছু অনুমানের মধ্যে এটি লুকিয়ে রয়েছে। উদাহরণস্বরূপ, সদস্যরা sealedডিফল্টরূপে রয়েছে এবং আপনার অবশ্যই তাদের স্পষ্ট করে তৈরি করতে হবে virtual। ভার্চুয়াল হওয়া সি # তে বিশেষ ক্ষেত্রে case অবশ্যই, লেখার কোডটির প্রস্তাবিত পদ্ধতির পরিবর্তিত বছরগুলিতে, সামঞ্জস্যতার জন্য থাকার জন্য অতীতের অনেকগুলি অবলম্বন দরকার ছিল :) মূল বিষয়টি হ'ল আপনি যদি সি # তে একটি ইন্টারফেস পান (যা শুরু হয় I) তবে আপনি জানেন যে এটি সম্পূর্ণরূপে বিমূর্ত প্রকার; আপনি যদি কোনও ইন্টারফেস না পেয়ে থাকেন তবে সাধারণ অনুমানটি হ'ল এটিই আপনার পছন্দ, এলএসপিকে ধিক্কার দেওয়া হবে।
লুয়ান

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

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

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

-8

আপনি সঠিক যে এই আই = ইন্টারফেস কনভেনশনটি (নতুন) নিয়মগুলি ভঙ্গ করে

পুরানো দিনগুলিতে আপনি প্রতিটি ধরণের intCounter boolFlag ইত্যাদি দিয়ে উপসর্গ করতেন

আপনি যদি উপসর্গ ব্যতিরেকে জিনিসটির নাম রাখতে চান তবে 'কংক্রিটপ্রেসার' এড়াতে পারেন তবে আপনি নেমস্পেস ব্যবহার করতে পারেন

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}

11
নতুন? পুরনো? অপেক্ষা করুন, আমি ভেবেছিলাম প্রোগ্রামিং হাইপ চেয়ে যৌক্তিকতা সম্পর্কে বেশি ছিল। নাকি পুরানো কালে এই ছিল?

3
তারা কীভাবে 'পাঠযোগ্যতা উন্নত করবে' সে সম্পর্কে কনভেনশন করা এবং ব্লগিংয়ের কিছুই নেই
ইওয়ান

8
আমি বিশ্বাস করি আপনি হাঙ্গেরিয়ান স্বরলিপি সম্পর্কে ভাবছেন, যেখানে আপনি প্রকৃতপক্ষে প্রকারের সাথে নামগুলি উপস্থাপন করেছিলেন। কিন্তু কোন সময় যা আপনার মত কিছু লিখতে চাই ছিল intCounterবা boolFlag। সেগুলি ভুল "প্রকার"। পরিবর্তে, আপনি লিখবেন pszName(একটি নাম সম্বলিত NUL- টার্মিনেটেড স্ট্রিংয়ের পয়েন্টার), cchName("নাম" স্ট্রিংয়ের অক্ষরের সংখ্যা)) xControl(নিয়ন্ত্রণের x স্থানাঙ্ক), fVisible(পতাকাটি কোনও কিছুর দৃশ্যমান রয়েছে), pFile(পয়েন্টার একটি ফাইল), hWindow(একটি উইন্ডোতে হ্যান্ডেল), এবং আরও অনেক কিছু।
কোডি গ্রে

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

4
@ কোডি গ্রে জোয়েল স্পলস্কি একটি দুর্দান্ত নিবন্ধ লিখেছিলেন, হাঙ্গেরিয়ান স্বরলিপি এবং যেভাবে এটি (ভুল) বোঝা গেছে সে সম্পর্কে ভুল কোড লুক রেকিং তৈরি করা । তার অনুরূপ মতামত রয়েছে: উপসর্গটি একটি উচ্চ স্তরের প্রকারের হওয়া উচিত, কাঁচা ডেটা স্টোরেজ ধরণের নয়। তিনি শব্দ "ধরনের" ব্যবহার ব্যাখ্যা, "আমি শব্দ ব্যবহার করছি ধরনের উদ্দেশ্যমূলকভাবে, সেখানে, কারণ সিমোনি ভুল শব্দ ব্যবহার করা টাইপ তার কাগজে, এবং প্রোগ্রামারদের প্রজন্মের অনেকেই ভুল বুঝে ভাবেন তিনি যা বোঝানো।"
জোশুয়া টেলর
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.