পাইথনে একই ফাইলে একাধিক ক্লাস করা ঠিক কি?


18

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

অভিজ্ঞ পাইথন চিকিত্সকটির কাছে এই প্রশ্নটি নির্বোধ বলে মনে হতে পারে তবে আমি এর উত্তর চাই তাই ভাষাটি নিয়ে আরও এগিয়ে যেতে পারি:

জাভা এবং পিএইচপিতে ( যদিও কঠোরভাবে প্রয়োজন হয় না ), আপনার classনিজের ফাইলটিতে প্রতিটি লেখার আশা করা হচ্ছে , ফাইলের নামটি classএকটি সেরা অনুশীলন হিসাবে।

পাইথন বা কমপক্ষে টিউটোরিয়ালে আমি যাচাই করেছি, একই ফাইলটিতে একাধিক ক্লাস করা ঠিক আছে।

এই নিয়মটি কি উত্পাদন, মোতায়েনের জন্য প্রস্তুত কোড ধারণ করে বা কেবল শিক্ষামূলক-কোডে সংক্ষিপ্ততার জন্য সম্পন্ন করে?

উত্তর:


13

পাইথনে একই ফাইলে একাধিক ক্লাস করা ঠিক কি?

হ্যাঁ. উভয়ই দার্শনিক দৃষ্টিভঙ্গির পাশাপাশি ব্যবহারিক দিক থেকেও।

পাইথনে, মডিউলগুলি এমন একটি নেমস্পেস যা স্মৃতিতে একবারে উপস্থিত হয়।

বলুন যে আমাদের প্রতি ফাইলের জন্য একটি শ্রেণি সংজ্ঞায়িত করে নিম্নলিখিত অনুমানিক ডিরেক্টরি কাঠামোটি ছিল:

                    Defines
 abc/
 |-- callable.py    Callable
 |-- container.py   Container
 |-- hashable.py    Hashable
 |-- iterable.py    Iterable
 |-- iterator.py    Iterator
 |-- sized.py       Sized
 ... 19 more

এই শ্রেণীর collectionsসমস্তগুলি মডিউলে এবং (সেখানে প্রকৃতপক্ষে 25 টি রয়েছে) স্ট্যান্ডার্ড লাইব্রেরি মডিউলে সংজ্ঞায়িত_collections_abc.py

এখানে বেশ কয়েকটি সমস্যা রয়েছে যা আমি বিশ্বাস করি _collections_abc.pyবিকল্প অনুমানমূলক ডিরেক্টরি কাঠামোর চেয়ে উচ্চতর করে তোলে ।

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

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

না।

পাইথনের জেন থেকে, এটি যে দর্শন এবং নীতিগুলির অধীনে এটি বেড়ে ওঠে তা প্রতিফলিত করে:

নেমস্পেসগুলি হ'ল একটি দুর্দান্ত ধারণা - আসুন আমরা তাদের আরও কিছু করি!

তবে আসুন আমরা এটি মনে রাখি যে:

ফ্ল্যাট বাসা থেকে ভাল।

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

বিমূর্ত বেস ক্লাস মডিউল থেকে আসল কোডটি এখানে । আমি এটিকে ভাষাতে বিভিন্ন বিমূর্তের বর্ণ বোঝার জন্য একটি রেফারেন্স হিসাবে ব্যবহার করতে চাই।

আপনি কি বলতে পারবেন যে এই ক্লাসগুলির প্রত্যেকের জন্য একটি পৃথক ফাইলের প্রয়োজন?

class Hashable:
    __metaclass__ = ABCMeta

    @abstractmethod
    def __hash__(self):
        return 0

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Hashable:
            try:
                for B in C.__mro__:
                    if "__hash__" in B.__dict__:
                        if B.__dict__["__hash__"]:
                            return True
                        break
            except AttributeError:
                # Old-style class
                if getattr(C, "__hash__", None):
                    return True
        return NotImplemented


class Iterable:
    __metaclass__ = ABCMeta

    @abstractmethod
    def __iter__(self):
        while False:
            yield None

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Iterable:
            if _hasattr(C, "__iter__"):
                return True
        return NotImplemented

Iterable.register(str)


class Iterator(Iterable):

    @abstractmethod
    def next(self):
        'Return the next item from the iterator. When exhausted, raise StopIteration'
        raise StopIteration

    def __iter__(self):
        return self

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Iterator:
            if _hasattr(C, "next") and _hasattr(C, "__iter__"):
                return True
        return NotImplemented


class Sized:
    __metaclass__ = ABCMeta

    @abstractmethod
    def __len__(self):
        return 0

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Sized:
            if _hasattr(C, "__len__"):
                return True
        return NotImplemented


class Container:
    __metaclass__ = ABCMeta

    @abstractmethod
    def __contains__(self, x):
        return False

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Container:
            if _hasattr(C, "__contains__"):
                return True
        return NotImplemented


class Callable:
    __metaclass__ = ABCMeta

    @abstractmethod
    def __call__(self, *args, **kwds):
        return False

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Callable:
            if _hasattr(C, "__call__"):
                return True
        return NotImplemented

সুতরাং তাদের প্রত্যেকের নিজস্ব ফাইল থাকা উচিত?

আমি আশা করি না.

এই ফাইলগুলি কেবল কোড নয় - এগুলি পাইথনের শব্দার্থবিজ্ঞানের ডকুমেন্টেশন।

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

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

আমি মাঝেমধ্যে খুব সংক্ষিপ্ত ক্লাসের দু'টি করে চলেছি। সময়ের সাথে আরও বড় হওয়ার প্রয়োজন থাকলেও তারা ফাইলটিতে থাকে stay কখনও কখনও পরিপক্ক মডিউলগুলির 1000 টিরও বেশি কোড থাকে। তবে সিটিআরএল-এফ সহজ, এবং কিছু আইডিই ফাইলের বাহ্যরেখা দেখতে সহজ করে তোলে - সুতরাং ফাইলটি যত বড়ই হোক না কেন, আপনি যে কোনও বস্তু বা পদ্ধতিটি সন্ধান করছেন তাড়াতাড়ি আপনি যেতে পারেন।

উপসংহার

পাইথনের প্রসঙ্গে আমার দিকনির্দেশনাটি একই ফাইলটিতে সম্পর্কিত এবং শব্দার্থগতভাবে অনুরূপ শ্রেণীর সংজ্ঞা রাখতে পছন্দ করা। যদি ফাইলটি এত বড় হয়ে যায় যে অযৌক্তিক হয়ে উঠতে পারে তবে একটি পুনর্গঠন বিবেচনা করুন।


1
ঠিক আছে, আমি যখন বুঝতে পেরেছি, আপনি যে কোডটি জমা দিয়েছেন তার জন্য ধন্যবাদ যে একই ফাইলটিতে একাধিক ক্লাস করা ঠিক আছে, আমি যুক্তিটি খুব দৃinc়প্রত্যয়ী খুঁজে পাচ্ছি না। উদাহরণস্বরূপ, পিএইচপি-তে কেবল এই জাতীয় কোডের সমান একটি সম্পূর্ণ ফাইল থাকা খুব সাধারণ ছিল:class SomeException extends \Exception {}
অলিভিয়ার মালকি

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

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

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

ধন্যবাদ জেফরি আলবার্টসন / কমিক বুক গাই :) পাইথনের বেশিরভাগ ব্যবহারকারীদের (ডাবল-আন্ডারস্কোর) বিশেষ পদ্ধতি ব্যবহার করা উচিত নয়, তবে তারা কোনও মূল ডিজাইনার / আর্কিটেক্টকে অপারেটর, তুলনাকারী, সাবস্ক্রিপ্ট স্বরলিপি, প্রসঙ্গ এবং অন্যান্যগুলির কাস্টম ব্যবহার করতে মেটা-প্রোগ্রামিংয়ে জড়িত থাকতে দেয় do ভাষার বৈশিষ্ট্য সমূহ. যতক্ষণ না তারা ন্যূনতম আশ্চর্যের নীতি লঙ্ঘন করে না, আমি মনে করি মান অনুপাতের ক্ষতি অনির্দিষ্ট।
অ্যারন হল

4

পাইথনে আপনার অ্যাপ্লিকেশনটি কাঠামো করার সময়, আপনাকে প্যাকেজ এবং মডিউলগুলির ক্ষেত্রে বিবেচনা করতে হবে।

মডিউলগুলি আপনি যে ফাইলগুলির কথা বলছেন সেগুলি সম্পর্কে। একই মডিউলের মধ্যে একগুচ্ছ ক্লাস রাখা ভাল। লক্ষ্য হ'ল একই মডিউলের সমস্ত শ্রেণীর একই উদ্দেশ্য / যুক্তি সরবরাহ করা উচিত। মডিউলটি যদি খুব দীর্ঘ হয় তবে আপনার যুক্তিটিকে নতুন করে ডিজাইন করে এটিকে বিভাজন করার কথা ভাবেন।

পাইথন বর্ধন প্রস্তাবসমূহের সূচি সম্পর্কে সময়ে সময়ে পড়তে ভুলবেন না ।


2

এর আসল উত্তরটি সাধারণ, এবং ব্যবহৃত ভাষার উপর নির্ভর করে না: কোনও ফাইলে কী হওয়া উচিত তা প্রাথমিকভাবে এটি কত শ্রেণীর সংজ্ঞা দেয় তার উপর নির্ভর করে না। এটি যৌক্তিক সংযোগ এবং জটিলতার উপর নির্ভর করে। সময়কাল।

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

এটি বলেছিল যে, প্রতি-ফাইল-প্রতি-শ্রেণীর নিয়মটি সাধারণত একটি ভাল হিউরিস্টিক। তবে, গুরুত্বপূর্ণ ব্যতিক্রম রয়েছে: একটি ছোট সহায়ক সহায়ক শ্রেণি যা কেবলমাত্র তার একমাত্র ব্যবহারকারী শ্রেণীর বাস্তবায়নের বিশদটি সাধারণত সেই ব্যবহারকারী শ্রেণীর ফাইলটিতে বান্ডিল করা উচিত। তেমনি, আপনার যদি তিনটি শ্রেণি থাকে vector2, vector3এবং vector4, পৃথক ফাইলে এগুলি প্রয়োগ করার খুব কম কারণ রয়েছে।


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