এটি একটি লাইব্রেরির মধ্যে থেকে STDIN থেকে পড়ার বিরোধী নিদর্শন হিসাবে বিবেচিত হয়?


39

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

আমার সহকর্মী বলেছে যে কেবল এসটিডিএন (পাইথন ব্যবহার করে code = input("Enter code: ")) থেকে পড়তে হবে এবং তারপরে কোনও ব্যবহারকারী এটি প্রবেশ করিয়ে দেবে, তবে আমার কাছে এটি খারাপ অভ্যাস বলে মনে হয় কারণ গ্রন্থাগারটি সম্ভবত (এই ক্ষেত্রে অবশ্যই কোনও সার্ভারের ব্যাকগ্রাউন্ড টাস্কে ব্যবহৃত হবে) ।

আমি ভাবছিলাম এটি এন্টি-প্যাটার্ন হিসাবে বিবেচিত হবে কি না।


45
খারাপ সব কিছুই "অ্যান্টি-প্যাটার্ন" নয়, যদিও এটি অবশ্যই খারাপ।
ফোশি

4
"প্যাটার্ন" এর অর্থ প্রোগ্রামাররা ঘন ঘন এমন কিছু করে। এটি কেবলমাত্র একটি এন্টি-প্যাটার্ন যদি এটি (ক) একটি খারাপ ধারণা এবং (খ) এমন কিছু হয় যা আপনি বিকাশকারীদেরকে সর্বদা করতে দেখেন।
সলোমন স্লো

20
এন্টি-প্যাটার্ন হতে এটি অনেক বেশি বোবা। একটি অ্যান্টি-প্যাটার্ন এমন একটি জিনিস যা প্রাকৃতিক এবং বোধগম্য মনে হয় তবে আপনি এটি খনন করার সময় খারাপ হতে পারে। আপনি এখানে যা বর্ণনা করছেন তা স্পষ্টতই মারাত্মক।
ইভান হার্পার

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

2
এটা বেশ ভয়াবহ। যদি এর মতো একটি টোকেন পাস করার প্রয়োজন হয় তবে আপনি লাইব্রেরিটি ব্যবহার করে একটি পৃথক নির্বাহযোগ্য করতে পারেন এবং আপনার টোকেনটিকে তার স্টিডিনে দিয়ে যেতে পারেন। কিন্তু কলিং এক্সিকিউটেবলের স্টাডিন হাইজ্যাক করার জন্য, এটি কোনও নং নয়।
গ্র্যান্ডমাস্টারবি

উত্তর:


78

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

অবশ্যই, এই নিয়মের ব্যতিক্রম আছে, তবে অবশ্যই এটির জন্য খুব ভাল কারণ থাকতে হবে। ব্যবহারের ক্ষেত্রে stdin, আমি কোনও কারণ খুঁজে পাচ্ছি না (যদি না আপনার লাইব্রেরিটি স্ট্যান্ডিন থেকে পড়ার জন্য রুটিনগুলি সরবরাহ না করে, std::cinসি ++ এর মতো)। এছাড়াও, হার্ডকড না করে প্যারামিটার থেকে I / O স্ট্রিম গ্রহণ করা এতটা নমনীয়তা যুক্ত করে যে এটি না করার মতো নয়।


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

এটি আমি যে ধরণের ব্যতিক্রম ভেবেছিলাম: আমার ধারণা ncurses এর কাছাকাছি ছিল - সাধারণত, একটি পাঠ্য-পরিবেশের ব্যবহারকারী ইন্টারফেস লাইব্রেরি। যদি এর উদ্দেশ্যটি যদি ব্যবহারকারী ইনপুট পড়তে এবং ব্যবহারকারীর আউটপুট সরবরাহ করা হয় তবে এটি একটি ভাল কারণ।
এসএফ

5
@SF। এমনকি মত একটি লাইব্রেরি ncurses বরং 0 এবং 1 এর ব্যবহার hardcoding চেয়ে আর্গুমেন্ট হিসাবে ফাইল বর্ণনাকারী একজোড়া নিতে হবে আপনি একটি প্রোগ্রাম যেখানে stdin এবং stdout- এ পুনঃনির্দেশিত করা যেতে পারে লিখতে চান পারে এবং এর পরিবর্তে আপনি খুলতে চান /dev/ttyঅর্ডার সাথে যোগাযোগ করার জন্য ব্যবহারকারী। প্রোগ্রামটি এমনকি টার্মিনাল ছাড়াই শুরু করা যেতে পারে এবং এটি ব্যবহার করে নিজস্ব টার্মিনালটি খুলতে পারে xterm -S
ক্যাস্পারড

3
@ ক্যাস্পার্ড: সর্বোত্তম পন্থা হ'ল বুদ্ধিমান ডিফল্ট এবং সেগুলি ওভাররাইড করার ক্ষমতা সরবরাহ করে।
এসএফ

1
এই বিশেষ ক্ষেত্রে, আমি ইনপুট হিসাবে স্ট্রিমের দাবি করার কোনও কারণ দেখছি না । কেন শুধু শুধু গ্রহণ টোকেন প্যারামিটার হিসাবে?
jpmc26

16

আমি এটিকে অ্যান্টি-প্যাটার্ন হিসাবে বিবেচনা করব না, কেবল একটি খারাপ ডিজাইনের লাইব্রেরি। পদ্ধতি প্যারামিটার হিসাবে স্ট্রিং জিজ্ঞাসা করা তুচ্ছ হওয়া উচিত, যেখানে ইনপুটটি সরাসরি প্রবেশ করতে পারে।

যদি এটি এই ব্যবহারের সাথে খাপ খায় না, তবে STDIN পদ্ধতিতে পাস করার সাথে একটি প্যারামিটার স্ট্রিম হতে পারে।

যদি এটি এই ব্যবহারের সাথে খাপ খায় না, তবে লাইব্রেরিটি যথেষ্ট নমনীয় নয়।


4

হয়তো একটি ব্যবহারকারী প্রদত্ত ফাংশন যা থেকে ইনপুট পড়তে হবে একটি কলব্যাক সেট করতে আপনার লাইব্রেরিতে ক্ষমতা থাকার বিবেচনা যেখানেই থাকুন না কেন , এবং তারপর লাইব্রেরির যাই হোক না কেন অংশ ফাংশন ব্যবহার করা হয় যথাযথ মান ফিরে।


1

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

তবে এই ক্ষেত্রে, গ্রন্থাগারের সম্ভবত একটি ইনপুট ফাইল বিবরণী নেওয়া উচিত।


0

@ পল 92 এর উত্তরটি ভাল সাধারণ আলোচনা, তবে আমি এটির জন্য একটি সম্ভাব্য পরিষ্কার (ইশ) সমাধান দিতে চাই:

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

পাইথনে, সম্ভবত সেরা বিকল্পটি হ'ল ফাংশন প্যারামিটার হিসাবে টোকেন আনার কৌশলটি পাস করা। এরকম কিছু:

def stdin_prompt():
    return input("Enter code: ")

def my_library_function(arg1, arg2, ... argn, token_provider = stdin_prompt):
    ...
    token = token_provider()
    ...
    return stuff

# somewhere in the user code
stuff = my_library_function(a1, a2, ... an, lambda: "123456")

এইভাবে ভেবে দেখুন। আপনার প্রয়োজনীয় টোকেনটি লাইব্রেরি ফাংশনের পক্ষে যুক্তি। যেহেতু টোকেনের মান কল সাইটে স্ট্যাটিকভাবে জানা যায় না, আপনি আর্গুমেন্ট হিসাবে সত্যই এটির জন্য জিজ্ঞাসা করতে পারবেন না। পরিবর্তে, কলকারীকে একটি ফাংশন সরবরাহ করতে হবে যা কল করার সময় টোকেন সরবরাহ করার জন্য দায়বদ্ধ হতে চলেছে।

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

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