পাইথনের উত্তরাধিকার হ'ল উত্তরাধিকারের একটি "ইস-এ" শৈলী বা রচনাশৈলিক শৈলী?


10

পাইথন একাধিক উত্তরাধিকারের অনুমতি দেয়, পাইথনের প্রতিচ্ছবির উত্তরাধিকারটি দেখতে কেমন?

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

public class Animal {...}
public class Dog extends Animal {...}

পাইথন যেহেতু একাধিক উত্তরাধিকারকে সমর্থন করে আমরা অন্যান্য অনেকগুলি বস্তু এক সাথে রচনা করে একটি অবজেক্ট তৈরি করতে পারি। নীচের উদাহরণ বিবেচনা করুন:

class UserService(object):
    def validate_credentials(self, username, password):
        # validate the user credentials are correct
        pass


class LoggingService(object):
    def log_error(self, error):
        # log an error
        pass


class User(UserService, LoggingService):
    def __init__(self, username, password):
        self.username = username
        self.password = password

    def authenticate(self):
        if not super().validate_credentials(self.username, self.password):
            super().log_error('Invalid credentials supplied')
            return False
         return True

পাইথনে এটি কি একাধিক উত্তরাধিকারের গ্রহণযোগ্য বা ভাল ব্যবহার? উত্তরাধিকার হ'ল পরিবর্তে যখন কোনও বস্তু অন্য বস্তুর "হয়-এ" হয়, তার পরিবর্তে আমরা একটি এবং তৈরির একটি Userমডেল তৈরি করি ।UserServiceLoggingService

ডাটাবেস বা নেটওয়ার্ক ক্রিয়াকলাপের জন্য সমস্ত যুক্তিকে Userমডেল থেকে আলাদা করে রাখা যেতে পারে UserServiceবস্তুটিতে রেখে এবং লগ ইন করার জন্য সমস্ত যুক্তি রেখে LoggingService

আমি এই পদ্ধতির সাথে কিছু সমস্যা হ'ল:

  • এটি কি কোনও Godশ্বরের আপত্তি তৈরি করে? যেহেতু Userউত্তরাধিকার সূত্রে প্রাপ্ত, বা গঠিত, UserServiceএবং LoggingServiceএটি কি সত্যই একক দায়িত্বের নীতি অনুসরণ করছে?
  • পিতামাতার / পরবর্তী-ইন-লাইন অবজেক্টে পদ্ধতি অ্যাক্সেস করার জন্য (যেমন, UserService.validate_credentialsআমাদের ব্যবহার করতে superহবে which এটি কোন পদ্ধতিটি এই পদ্ধতিটি পরিচালনা করছে এবং এটি এতটা পরিষ্কার নয় তা বলার জন্য এটি আরও কিছুটা জটিল করে তোলে say , তাত্ক্ষণিকভাবে UserServiceএবং কিছু করার মতোself.user_service.validate_credentials

উপরের কোডটি বাস্তবায়নের পাইথোনিক উপায় কী হবে?

উত্তর:


9

পাইথনের উত্তরাধিকার হ'ল উত্তরাধিকারের একটি "ইস-এ" শৈলী বা রচনাশৈলিক শৈলী?

পাইথন উভয় শৈলীর সমর্থন করে। আপনি কম্পোজিশনের একটি সম্পর্ক রয়েছে তা প্রদর্শন করছেন, যেখানে একজন ব্যবহারকারীর একটি উত্স থেকে কার্যকারিতা লগ এবং অন্য উত্স থেকে শংসাপত্রের বৈধতা রয়েছে। LoggingServiceএবং UserServiceঘাঁটি mixins হয়: তারা কার্যকারিতা প্রদান এবং নিজেরাই instantiated করা উদ্দেশ্যে না হয়।

ধরণের মিশ্রণগুলি রচনা করে আপনার একটি ব্যবহারকারী রয়েছে যা লগ করতে পারে তবে তার নিজের ইনস্ট্যান্টেশন কার্যকারিতা যুক্ত করতে হবে।

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

এটি কি কোনও Godশ্বরের আপত্তি তৈরি করে?

লগিং কিছুটা স্পর্শকাতর বলে মনে হচ্ছে - পাইথনের একটি লগার বস্তুর সাথে নিজস্ব লগিং মডিউল রয়েছে এবং কনভেনশনটি হল মডিউল প্রতি এক লগার রয়েছে।

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

সুপার কি কম স্পষ্ট?

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

এখানে আপনার উদাহরণে, আপনাকে কেবল করা দরকার self.validate_credentialsselfআপনার দৃষ্টিকোণ থেকে, আরও পরিষ্কার নয়। তারা উভয়ই এমআরও অনুসরণ করে। আমি কেবল যেখানে উপযুক্ত সেখানে ব্যবহার করব।

আপনি ডাকছেন authenticate, validate_credentialsপরিবর্তে, আপনি ব্যবহার করতে প্রয়োজন হবে super(অথবা হার্ড কোড পিতা বা মাতা) একটি পুনরাবৃত্তির ত্রুটি এড়ানো।

বিকল্প কোড পরামর্শ

সুতরাং, ধরে নিলাম শব্দার্থবিজ্ঞান ঠিক আছে (লগিংয়ের মতো), আমি কি করব, ক্লাসে User:

    def validate_credentials(self): # changed from "authenticate" to 
                                    # demonstrate need for super
        if not super().validate_credentials(self.username, self.password):
            # just use self on next call, no need for super:
            self.log_error('Invalid credentials supplied') 
            return False
        return True

1
আমি একমত নই উত্তরাধিকার সর্বদা তার শ্রেণীর শ্রেণীর সর্বজনীন ইন্টারফেসের একটি অনুলিপি তৈরি করে। এটি "হেস-এ" সম্পর্ক নয়। এটি সাব টাইপিং, সরল এবং সাধারণ, এবং তাই বর্ণিত প্রয়োগটির পক্ষে অনুপযুক্ত।
জুলাই

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

1
বিষয়টি বাস্তবায়ন কীভাবে কাজ করে তার নির্দিষ্ট বিবরণ সম্পর্কে নয়, এটি শ্রেণীর পাবলিক ইন্টারফেসটি কেমন দেখাচ্ছে তা সম্পর্কে। উদাহরণস্বরূপ ক্ষেত্রে, Userবস্তু তাদের ইন্টারফেসগুলি না শুধুমাত্র সদস্যদের সংজ্ঞায়িত আছে Userবর্গ, কিন্তু বেশী সংজ্ঞায়িত UserServiceএবং LoggingService। এই নয় একটি "হয়েছে-একটি" সম্পর্ক, কারণ পাবলিক ইন্টারফেস (না সরাসরি কপি মাধ্যমে, বরং superclasses 'ইন্টারফেস একটি পরোক্ষ লুকআপ দ্বারা যদিও) অনুলিপি করা হয়েছে।
জুলাই

Has-a মানে কম্পোজিশন। মিক্সিনগুলি কম্পোজিশনের একটি রূপ। ব্যবহারকারী বর্গ হয় একটি UserService বা LoggingService না, কিন্তু এটা হয়েছে যে কার্যকারিতা। আমি মনে করি যে পাইথনের উত্তরাধিকার জাভা থেকে আপনি বুঝতে পারছেন তার চেয়ে আলাদা more
অ্যারন হল

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

-1

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

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

পাইথনে অবজেক্ট-ওরিয়েন্টেড সিস্টেমগুলি ডিজাইন করার সময়, জাভা ডিজাইনের বইগুলি দ্বারা প্রচারিত একই ম্যাক্সিমটিও প্রয়োগ হয়: উত্তরাধিকারের জন্য রচনাটিকে পছন্দ করুন। একাধিক উত্তরাধিকারী অন্যান্য সিস্টেমে একই (বেশিরভাগ [2]) ক্ষেত্রেও একই কথা।

[1]: আপনি এটি "একটি-একটি" সম্পর্ক বলতে পারেন, যদিও আমি ব্যক্তিগতভাবে এই শব্দটি পছন্দ করি না কারণ এটি বাস্তব বিশ্বের মডেলিংয়ের ধারণাটি প্রস্তাব করে এবং অবজেক্ট অরিয়েন্টেড মডেলিং বাস্তব বিশ্বের মতো নয়।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.