ইনকামিং প্যারামিটার পরিবর্তন করা কি একটি অ্যান্টিপ্যাটার্ন? [বন্ধ]

60

আমি জাভাতে প্রোগ্রামিং করছি, এবং আমি সবসময় এই জাতীয় রূপান্তরকারী সাজাই:

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

নতুন কর্মক্ষেত্রে প্যাটার্নটি হ'ল:

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

আমার জন্য এটি কিছুটা দুর্গন্ধযুক্ত, কারণ আমি আগত প্যারামিটারগুলি পরিবর্তন না করার অভ্যস্ত হয়ে পড়েছি। এই আগত প্যারামিটার পরিবর্তনটি একটি অ্যান্টিপ্যাটার্ন বা এটি ঠিক আছে? এর কিছু গুরুতর ত্রুটি আছে কি?

java clean-code anti-patterns

— CsBalazsHungary
সূত্র

4

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

— ব্লারফ্ল

1

দ্বিতীয় প্যাটার্নটি কখনও কখনও বস্তুর পুনরায় ব্যবহার করতে দক্ষতার পরিমাপ হিসাবে ব্যবহৃত হয়। ধরে নেওয়া যে এটি ooএমন একটি অবজেক্ট যা পদ্ধতিতে পাস হয়েছে, কোনও পয়েন্টার নয় যা কোনও নতুন অবজেক্টে সেট করা আছে। এখানে ক্ষেত্রে যে কি? এটি যদি জাভা হয় তবে সম্ভবত এটির সি ++ এটি নাও হতে পারে

— রিচার্ড টিঙ্গল

3

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

— কেনে

2

দ্বিতীয় প্যাটার্নটি কার্যকর যখন ফাংশনটিও একটি মান প্রদান করে প্রাক্তন, সাফল্য / ব্যর্থতার জন্য। তবে এর সাথে আসলে 'ভুল' কিছুই নেই। এটি সত্যই নির্ভর করে আপনি কোথায় বস্তুটি তৈরি করতে চান।

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

12

আমি এই দুটি ভিন্ন প্যাটার্ন একইভাবে প্রয়োগের ফাংশনগুলির নাম দেব না।

— কেসি

70

এটি কোনও অ্যান্টিপ্যাটার্ন নয়, এটি একটি খারাপ অভ্যাস।

অ্যান্টিপ্যাটার্ন এবং নিছক খারাপ অভ্যাসের মধ্যে পার্থক্যটি এখানে রয়েছে: অ্যান্টি-প্যাটার্ন সংজ্ঞা ।

আঙ্কেল ববসের ক্লিন কোড অনুসারে আপনি যে নতুন কর্মক্ষেত্রটি দেখান তা হ'ল একটি খারাপ অনুশীলন , অনুসন্ধান বা প্রাক OO বার O

আর্গুমেন্টগুলি কোনও ফাংশনের ইনপুট হিসাবে স্বভাবতই ব্যাখ্যা করা হয়।

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

— তুলিনেস কর্ডোভা
সূত্র

7

আপনি যে সংজ্ঞাটি সংযুক্ত করেছেন তা কেন এটি বিরোধী-নিদর্শন হিসাবে বিবেচিত হবে তা আমি দেখতে পাচ্ছি না।

— স্যামুয়েল এডউইন ওয়ার্ড

7

আমি মনে করি এটি কারণ যে "আমরা নতুন অবজেক্ট তৈরি না করে সিপিইউ / মেমি সঞ্চয় করছি, পরিবর্তে আমাদের থাকা একটিটিকে পুনর্ব্যবহার করা উচিত এবং এটি একটি আর্গ হিসাবে পাস করা উচিত" গুরুতর ওওপি ব্যাকগ্রাউন্ডવાળા প্রত্যেকের পক্ষে স্পষ্টতই ভুল যে এটি হতে পারে না একটি প্যাটার্ন কি কখনো গঠন - তাই কোন উপায় আমরা এটা বিরোধী প্যাটার্ন সংজ্ঞা দ্বারা বিবেচনা পারে ...

— vaxquis

1

ক্ষেত্রে কী হবে যখন কোনও ইনপুট প্যারামিটারগুলি এমন কোনও সামগ্রীর সংশোধন করার দরকার হয়?

— স্টিভ চেম্বার্স

যদিও আমি বিকল্প 1 পছন্দ করি, তবে OtherObjectইন্টারফেস হলে কী হবে ? কেবলমাত্র কলার (আশাবাদী) জানে যে এটি কংক্রিটের ধরণটি কী চায়।

— ব্যবহারকারী949300

@ স্টিভ চ্যাম্বার্স আমি মনে করি, এক্ষেত্রে শ্রেণি বা পদ্ধতির নকশা খারাপ এবং এড়াতে এটি পুনঃসংশ্লিষ্ট হওয়া উচিত।

— পাইওটিআরউইচটেন

16

রবার্ট সি মার্টিনের বিখ্যাত বই "ক্লিন কোড" এর উদ্ধৃতি দিয়ে:

আউটপুট যুক্তি এড়ানো উচিত

ফাংশনে অল্প সংখ্যক তর্ক থাকতে হবে

দ্বিতীয় প্যাটার্ন উভয় নিয়ম লঙ্ঘন করে, বিশেষত "আউটপুট আর্গুমেন্ট" এক। এই অর্থে এটি প্রথম প্যাটার্নের চেয়ে খারাপ।

— claasz
সূত্র

1

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

— সিএস বালাজস হুঙ্গারি

2

যাইহোক আমি সন্দেহ করি এটি একটি কঠোর আইন নয়, তবে একটি শক্তিশালী পরামর্শ। আমি জানি যে এটি আদিম ধরণের সাথে কাজ করবে না, যদি এটি কোনও প্রকল্পে বিস্তৃত প্যাটার্ন হয় তবে কোনও জুনিয়র ধারণা অর্জন করতে পারে এবং এটি অবজেক্টের মতো পরিবর্তিত হবে বলে আশা করে।

— সিএস বালাজস হুঙ্গারি

27

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

— দেনিথ

3

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

— কেসি

2

@ এমোডেনড্রোকেট কিন্তু বাবু, এ তো লোক!

— পিয়ের আরলাড

15

দ্বিতীয় আইডিয়ামটি দ্রুততর হতে পারে, কারণ কলার প্রতিটি পুনরাবৃত্তির পরিবর্তে একটি নতুন পরিবর্তন তৈরির পরিবর্তে লং লুপের উপরে একটি পরিবর্তনশীল পুনরায় ব্যবহার করতে পারে।

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

— user470365
সূত্র

12

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

— সিএস বালাজস হুঙ্গারি

4

@ সিএস বালাজস হুঙ্গারি আমি বিশ্বাস করি যে বিষয়গুলি যখন বস্তু তৈরির বিষয়টি উদ্বেগজনক হয় তখন স্মৃতি বরাদ্দ এবং আবর্জনা সংগ্রহের সাথে সম্পর্কিত হয় যা সম্ভবত অ্যালগরিদমিক জটিলতার (বিশেষত একটি সীমাবদ্ধ-স্মৃতি পরিবেশে, যেমন স্মার্টফোন এবং এর মতো) পরবর্তী স্তরের বাধা হয়ে দাঁড়াবে would ।

— জ্যাব

এটি প্রায়শই পারফরম্যান্সের সমালোচনামূলক হওয়ার কারণে জেমনকিও আমি এটি অনেক দেখেছি। "জাভামনকি" নামে আমি এর আগে কখনও শুনিনি

— রিচার্ড

3

@ জ্যাব: জেভিএমের জিসি বিশেষত সাময়িক অবজেক্টের ক্ষেত্রে দেখা যায়। প্রচুর স্বল্প জীবিত বস্তুগুলির বৃহত পরিমাণে সংগ্রহ করা তুচ্ছ, এবং অনেক ক্ষেত্রেই আপনার সম্পূর্ণ অল্পকালীন প্রজন্ম একক পয়েন্টার পদক্ষেপের সাহায্যে সংগ্রহ করা যেতে পারে।

— ফোশি

2

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

— ভ্যাক্সকুইস

10

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

— euphoric
সূত্র

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

— CsBalazsHungary

@ সি এস বালাজস হুঙ্গারি আমি হ্যাঁ বলব। আপনার প্রদত্ত কোডের ছোট্ট অংশটি বিচার করে।

— ইউফোরিক

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

— সিএস বালাজস হুঙ্গারি

1

@ এস এস বালাজস হুঙ্গারি আদিম যুক্তির ক্ষেত্রে, ফাংশনটিও কাজ করবে না। সুতরাং আপনার যুক্তি পরিবর্তনের চেয়ে খারাপ সমস্যা রয়েছে।

— ইউফোরিক

আমি বলব জুনিয়র আদিম টাইপকে আউটপুট প্যারামিটার বানানোর চেষ্টা করার ফাঁদে পড়বে। সুতরাং আমি বলব যদি সম্ভব হয় তবে প্রথম রূপান্তরকারীকে পছন্দ করা উচিত।

— সিএস বালাজস হুঙ্গারি

7

এটি আসলে ভাষার উপর নির্ভর করে।

জাভাতে দ্বিতীয় ফর্মটি একটি অ্যান্টি-প্যাটার্ন হতে পারে তবে কিছু ভাষাগুলি প্যারামিটারকে আলাদাভাবে আচরণ করে। আদা এবং উদাহরণের জন্য VHDL, পাস পরিবর্তে মান দ্বারা বা রেফারেন্স দ্বারা সালে পরামিতি মোড থাকতে পারে in, outঅথবা in out।

inপ্যারামিটারটি পরিবর্তন করতে বা পরামিতি পড়তে ত্রুটি হয় outতবে প্যারামিটারে যে কোনও পরিবর্তন in outহয় তা কলারের কাছে ফিরে যায়।

সুতরাং অ্যাডায় দুটি ফর্ম (এগুলিও আইনী ভিএইচডিএল)

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

এবং

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

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

— ব্রায়ান ড্রামন্ড
সূত্র

3

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

প্রথমত, এটি আংশিক রূপান্তর বাস্তবায়নের একটি সংক্ষিপ্ত উপায় বা রূপান্তর ব্যর্থ হলে ফলাফলকে ডিফল্ট মান সহ রেখে যায়। এটি আপনার কাছে থাকতে পারে:

public void ConvertFoo(Foo from, Foo to) {
    if (can't convert) {
        return;
    }
    ...
}

Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged

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

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

জাভা একাধিক আউটপুট মোকাবেলায় দুর্দান্ত নয় - এতে কিছু ভাষার মতো আউটপুট-প্যারামিটার থাকতে পারে না বা অন্যের মতো একাধিক রিটার্ন মান থাকতে পারে - তবুও আপনি রিটার্ন অবজেক্ট ব্যবহার করতে পারেন।

ধারাবাহিকতার কারণটি বরং খোঁড়া তবে দুঃখজনকভাবে এটি সবচেয়ে সাধারণ হতে পারে।

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

— congusbongus
সূত্র

2

দ্বিতীয় প্যাটার্নের সুবিধা হ'ল এটি কলারকে তৈরি করা সামগ্রীর মালিকানা এবং দায়িত্ব নিতে বাধ্য করে। পদ্ধতিটি বস্তুটি তৈরি করেছে বা পুনঃব্যবহারযোগ্য পুল থেকে পেয়েছে কিনা সে বিষয়ে কোনও প্রশ্ন নেই। কলকারী জানে যে তারা নতুন জীবনব্যাপী আজীবন ও নিষ্পত্তি করার জন্য দায়বদ্ধ।

এই পদ্ধতির অসুবিধাগুলি হ'ল:

কারখানার পদ্ধতি হিসাবে ব্যবহার করা যাবে না, কলকারীকে অবশ্যই তার সঠিক উপ টাইপটি জানতে OtherObjectহবে এবং এটি আগে থেকেই তৈরি করতে হবে।
যদি সেই প্যারামিটারগুলি আসে তবে তাদের নির্মাণকারীর পরামিতিগুলির প্রয়োজন হয় এমন অবজেক্টগুলির সাথে ব্যবহার করা যাবে না MyObject। OtherObjectসম্পর্কে না জেনে অবশ্যই গঠনমূলক হতে হবে MyObject।

উত্তরটি সি # তে আমার অভিজ্ঞতার ভিত্তিতে তৈরি, আমি আশা করি যুক্তিটি জাভাতে অনুবাদ করেছে।

— Rotem
সূত্র

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

— সিএস বালাজস হুঙ্গারি

এই আমি ভাবছিলাম। আদিম ধরণের নির্ভরতা ইনজেকশন

— লন্ডন হোয়াইট

অন্য সুবিধাটি হ'ল যদি অন্যান্যঅবজেক্টটি বিমূর্ত বা একটি ইন্টারফেস হয়। ফাংশনটি কোন ধরণের তৈরি করতে হবে তার কোনও ধারণা নেই তবে কলার হতে পারে।

— user949300

2

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

তবে, যদি পদ্ধতির নামটি ছিল Convert(যদি আমরা "... ... রূপান্তরটি কর" অংশটি দেখি তবে এটি হওয়া উচিত), আমি বলতাম দ্বিতীয় পদ্ধতিটি কোনও অর্থবোধ করবে না। আইএমও, আপনি ইতিমধ্যে বিদ্যমান একটি মানকে অন্য মানতে রূপান্তর করবেন না।

— guillaume31
সূত্র