এটির অস্তিত্ব না থাকলে কোনও কিছুর জন্য তৈরি করা কোডিং অভ্যাসটি কি খারাপ?

18

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

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

আমি কি ভাবছি এই লাইব্রেরিতে যদি আমি এমন একটি তৈরি করে থাকি getAccount(accountName)যা যদি এটি উপস্থিত থাকে তবে অ্যাকাউন্টটি পেয়ে যায়, এবং যদি এটি তৈরি না করে এবং তথ্যটি ফেরত না দেয়, তবে এটি কি খারাপ কাজ? ব্যতিক্রমগুলি পরিচালনা করতে আমি কি ক্লায়েন্টের কাছে রেখেছি বা কেবল getOrCreateA অ্যাকাউন্ট হিসাবে এর নামকরণ করব? এটা কোন ব্যাপার?

গেট অপারেশনে কিছু তৈরি করা কি খারাপ অভ্যাস?

java code-quality

— মাইক
সূত্র

9

খুব কমপক্ষে, আমি এটির নাম getOrCreateAccountবা অনুরূপ করব।

— টেলাস্টিন

4

অলস সূচনা প্রসঙ্গে এটি বৈধ বলে মনে হচ্ছে। তবে এটি আপনার লাইব্রেরিতে সেই ধরণটি ব্যবহার করার প্রয়োজন আছে কিনা তা নির্ভর করে।

— ক্রিস সি

1

আমি ক্রিয়াটি পছন্দ করি acquire, পছন্দ করি acquireAccount। আমি যে বড় বড় প্রোটোকলগুলির মুখোমুখি হয়েছিল তার কোনও বিদ্যমান অর্থ নেই এবং এটির জন্য এটির একটি আবশ্যক রিং রয়েছে যা এটির পক্ষে উপযুক্ত। "এগুলির মধ্যে একটি অর্জনের জন্য আপনার যা যা করতে হবে তা করুন it

— ড্যান রস

2

"ক্লায়েন্ট সর্বদা একটি অ্যাকাউন্ট তৈরি করতে চাইবে" - এটি অত্যন্ত অস্বাভাবিক বলে মনে হয়। যদি আমি অ্যাকাউন্টটি না পেয়ে পারি কারণ ব্যবহারকারী তাদের ব্যবহারকারী নামটি ভুল টাইপ করে থাকে তবে আমি অবশ্যই ভুল টাইপের নামের সাথে একটি অ্যাকাউন্ট তৈরি করতে চাই না।

— gnasher729

জাভাবেন অনুমান অনুসারে oracle.com/technetwork/articles/javaee/spec-136004.html গেটারদের getSomething() জন্য, এবং সেটারদেরsetSomething() জন্য। Imo, কিছু যে আরো বুদ্ধিজীবী কিছু আছে অন্য কিছু কল করা উচিত, অর্থাত fetchSomething, obtainSomething, computeSomething, অথবা doSomethingElseইত্যাদি

— ccpizza

31

হ্যাঁ, এটা গুরুত্বপূর্ণ। আমার মতে, একটি পদ্ধতিতে এমন কিছু তৈরি করা একটি সাধারণভাবে খারাপ অভ্যাস যা সৃষ্টির ক্ষমতা বলে নথিভুক্ত হয় না। হয় প্রক্রিয়াটির নাম দিন getOrCreate...বা একটি পৃথক create...পদ্ধতি আছে এবং তারপরে আপনি যদি সত্যিই চান তবে getOrCreate...প্রথমে চেষ্টা করুন get..., এবং যদি এটি ব্যর্থ হয়, কল create...এবং তারপরে কল get...।

গ্রন্থাগারের ব্যবহারকারী সম্ভবত get...পদ্ধতিটি ব্যর্থ হলে প্রক্রিয়াটি তৈরির আশা করে না । যদি তারা হঠাৎ করে জানতে পারেন যে তাদের পরীক্ষাগুলি get...পুরো টন ডেটা তৈরি করার আহ্বান জানায় তবে তারা সম্ভবত বিস্মিত হবেন। এবং তারা কীভাবে এটি পরিষ্কার করে? কি হবে যদি তারা কোড চিন্তা যে তারা একটি ত্রুটি যদি পাবেন লিখতে get...ব্যর্থ হয় এবং তারা পরিচালনা করতে চাই তাদের উপায়?

— FrustratedWithFormsDesigner
সূত্র

ধন্যবাদ, তৈরিটি আসলে আইডিটি ফিরিয়ে দেয় যা প্রাপ্তিটিও ফিরে আসবে তাই আমাকে get... create... get...কেবল প্রথম দুটি করতে হবে না । আমি ক্লায়েন্টের সাথে তাদের কথা বলব কিনা তাদের তৈরি করতে চাইলে কেবল getকোনও কল করার দক্ষতার প্রয়োজন হবে কিনা

— মাইকে

6

@ মাইক: আমি এখনও মনে করি এটির createনাম থাকা উচিত , যা ঘটছে সে সম্পর্কে 100% পরিষ্কার হওয়া।

— হতাশাহীন উইথফোর্ডস ডিজাইনার

হ্যাঁ আমি সম্মত, আমি getOrCreate এর ধারায় এটি কিছু তৈরি করার পরিকল্পনা করছিলাম কারণ আমার আসল ধারণাটি কেবল করণীয় ছিল তবে আমি বুঝতে পেরেছিলাম যে এটি অবিলম্বে পরিষ্কার নয় যে এটি ব্যাকগ্রাউন্ডেও কিছু তৈরি করছে

— মাইকে

1

এই সুপার দেরি হয়ে গেছে কিন্তু getOrCreateএকটি জনপ্রিয় ওয়েব কাঠামোর মধ্যে প্রাধান্য রয়েছে: docs.djangoproject.com/en/1.10/ref/models/querysets/...

— টেক্স

18

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

— GrandmasterB
সূত্র

10

ব্যতিক্রম কেবলমাত্র যদি এটি সর্বজনীনভাবে উপলব্ধ API হয় is বৃহত্তর জনগোষ্ঠী ইতিমধ্যে সম্মতি জানিয়েছে যে জিইটি অনির্বাচিত এবং নালিকাবিদ; অন্য কথায়, একই পদক্ষেপটি প্রতিবার সঞ্চালিত হয় এবং এটি একটি নিরাপদ পদ্ধতি যা সার্ভারের অবস্থা পরিবর্তন করে না। এটি রেস্ট উইকিতে রয়েছে । এ ছাড়া, যদি এপিআই কেবল আপনার নিজস্ব সামান্য বিশ্বে উপস্থিত থাকে তবে আপনার গোষ্ঠীটি যা গ্রহণ করবে তা করুন।

— jmort253

9

আমি একমত নই, এমনকি কোনও পাবলিক এপিআইয়ের জন্যও এটির জরিমানা - যতক্ষণ না এটি এপিআই-র যা করা উচিত বলে মনে করা হয় তার প্রসঙ্গে । এপিআইতে একাধিক এন্ট্রি তৈরি করার সামান্য বিন্দু নেই যখন কোনও এককটি কৌশলটি করে।

— গ্র্যান্ডমাস্টারবি

রেকর্ডের জন্য এটি সম্পূর্ণ অভ্যন্তরীণ গ্রন্থাগার এবং এটি কীভাবে কাজ করে তা টিমকে এটি ব্যবহার করে বলার ক্ষমতা আমার রয়েছে

— মাই

1

@ jmort253: কোনও ক্লায়েন্টের কাছে কোনও পার্শ্ব প্রতিক্রিয়া দৃশ্যমান না থাকলে কোনও পরিষেবা নালিকাশক্তিযুক্ত । সার্ভারটি যেমন খুশি তাই করতে পারে।

— কেভিন cline

1

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

— jmort253

10

যদি getAccount()সর্বদা কোনও অ্যাকাউন্ট ফেরত দিতে পারে, তবে কলারের দৃষ্টিকোণ থেকে, অ্যাকাউন্টটি উপস্থিত থাকে এবং সর্বদা বিদ্যমান থাকে। কোনও getAccount()কিছু 'তৈরি' করার দরকার নেই। অ্যাকাউন্টটি ডিফল্ট অ্যাকাউন্ট থেকে আলাদা না হওয়া পর্যন্ত কোথাও সংরক্ষণ করতে হবে না।

— কেভিন ক্লাইন
সূত্র

+1 সাধারণত, GetOrCreateভুল অর্থবোধক তবে এমন একটি বস্তু পাওয়া যা "যুক্তিসঙ্গতভাবে" থাকতে পারে যা এটি ফিসিকালি বিদ্যমান কিনা ঠিক আছে কিনা। উদাহরণস্বরূপ, পরিবর্তনীয় আইটেমগুলির একটি বিচ্ছিন্ন অ্যারেতে 1,841,533 এলিমেন্টের জন্য বরাদ্দ থাকা কোনও স্টোরেজ নাও থাকতে পারে, তবে তারপরেও নতুন উপাদান তৈরি করে, সংরক্ষণ করে এবং একটি রেফারেন্স ফিরে দিয়ে সেই উপাদানটিকে "পুনরুদ্ধার" করার অনুমতি দেয়।

— সুপারক্যাট

4

এটি 3 টি পদ্ধতি তৈরি করতে সর্বাধিক জ্ঞান অর্জন করে:

getAccount -> যা কেবল অ্যাকাউন্টটি পায়।

createAccount -> একটি অ্যাকাউন্ট তৈরি করে।

getAccountAndCreateIfNeeded -> আপনার নিজের নামকরণ চয়ন করুন;)

কেন বিচ্ছেদ: পাওয়ার এবং তৈরি করার জন্য আপনার কাছে একটি সহজ পদ্ধতি রয়েছে। এটি উভয়ের জন্য একটি পরিষ্কার পরীক্ষাযোগ্য পদ্ধতি। GetA অ্যাকাউন্ট এর জন্য অ্যাকাউন্টটি না পাওয়া এটি ব্যতিক্রম নয় । সুতরাং ঠিক মিথ্যা বা এরকম কিছু ফিরে আসুন, এটি প্রত্যাশিত।

তারপরে আপনি সেই রিটার্ন মানটি আপনার গোষ্ঠীযুক্ত ফাংশনে ব্যবহার করতে পারেন: getAccountAndCreateIfNeeded যা এখন পরীক্ষাযোগ্য, এটি সর্বদা একটি অ্যাকাউন্ট ফেরত দেওয়া উচিত। তুমি যা চাও।

এই 3 টি পদ্ধতি পরিষ্কার, তারা কী করে এবং তারা কী ফিরে আসে তা একেবারে স্পষ্ট। আপনি এখন আপনার দলের সাথে চুক্তি করতে পারেন তবে এই ধরণের ব্যতিক্রমগুলি দীর্ঘমেয়াদে ভয়াবহ। কেবল এগুলিকে খুব পরিষ্কার করুন এবং আপনার কোনও সমস্যা হবে না।

— লুস ফ্রাঙ্কেন
সূত্র

এছাড়াও, ক্লিন কোড থেকে: "যদি আপনার পদ্ধতিটি এর নামটি বোঝায় তেমন করতে না পারে তবে একটি ব্যতিক্রম নিক্ষেপ করুন।" আমার 'getOrCreateIfneeded' এর ভিতরে একটি চেষ্টা / ক্যাচ ব্লক থাকতে হবে যা একটি ব্যর্থ জিইটি-র উপর ফেলে দেয় এবং তারপরে ব্যর্থতার জন্য যে ধরনের ব্যতিক্রম টাইপ ফিরে আসে তার জন্য থ্রো-এর ভিতরে 'ক্রিয়েটঅ্যাকউন্ট' থাকে।

— গ্রাহাম 19

আমি একটি চতুর্থ পদ্ধতি প্রস্তাব করতে পারি:, getAccountIfExistsযা হয় একটি অ্যাকাউন্ট পেতে বা বোঝায় যে এটি একটি নতুন তৈরি না করেই নেই। getAccountপদ্ধতি নিজেই লওয়া উচিত যে অ্যাকাউন্ট বিদ্যমান, এবং একটি ব্যতিক্রম যদি না নিক্ষেপ।

— সুপারক্যাট

2

এটা পরিস্থিতির উপর নির্ভর করে।

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

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

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

— GordonM
সূত্র