কোডিং স্টাইল ইস্যু: আমাদের কি এমন ফাংশন থাকতে হবে যা একটি প্যারামিটার নেয়, এটি পরিবর্তন করে এবং তারপরে প্যারামিটারটি ফিরিয়ে দিতে পারে?


19

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

আমাদের একটি ফাংশন রয়েছে যা একটি প্যারামিটার নেয়, এর কোনও সদস্য পূরণ করে এবং তারপরে এটি প্রদান করে:

Item predictPrice(Item item)

আমি বিশ্বাস করি যে এটি যেমন পাস করা একই বস্তুর উপর কাজ করে , আইটেমটি ফেরত দেওয়ার কোনও লাভ নেই। প্রকৃতপক্ষে, যদি কিছু থাকে, কলারের দৃষ্টিকোণ থেকে, এটি বিষয়গুলিকে বিভ্রান্ত করে কারণ আপনি এটি প্রত্যাশা করতে পারেন যে কোনও নতুন আইটেম এটি প্রত্যাখ্যান করে না return

তিনি দাবি করেন যে এটি কোনও পার্থক্য করে না, এবং এটি কোনও নতুন আইটেম তৈরি করে তা ফেরত দিলেও তা বিবেচ্য হবে না। নিম্নলিখিত কারণে আমি দৃ strongly়ভাবে একমত নই:

  • আপনার যদি আইটেমটির একাধিক রেফারেন্স থাকে (বা পয়েন্টার বা অন্য যাই হোক না কেন), এটি কোনও নতুন বস্তু বরাদ্দ করে এবং এটি ফেরত দেওয়া বস্তুগত গুরুত্বের কারণ সেগুলি উল্লেখগুলি ভুল হবে।

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

  • স্তূপে বরাদ্দ করা সম্ভাব্য ব্যয়বহুল, এবং সেইজন্য এটি বলা গুরুত্বপূর্ণ যে ডাকা ফাংশনটি এটি করে কিনা।

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

void predictPrice(Item item)

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

সুতরাং, কোন চিন্তা?


strcat জায়গায় একটি প্যারামিটার পরিবর্তন করে এবং এটি এখনও প্রদান করে। স্ট্রিকাট কি বাতিল হওয়া উচিত?
জেরি যেরেমিয়া

পাসওয়ার্ডগুলির ক্ষেত্রে জাভা এবং সি ++ এর খুব আলাদা আচরণ রয়েছে। যদি Itemতা হয় class Item ...এবং না হয় typedef ...& Itemতবে স্থানীয় item
লোকটি

google.github.io/styleguide/cppguide.html# আউটপুট_প্যারামিটার গুগল আউটপুট জন্য রিটার্ন মান ব্যবহার পছন্দ
ফায়ারগান

উত্তর:


26

এটি সত্যই মতামতের একটি বিষয়, তবে এটির মূল্য কী, আমি আইটেমটি জায়গায় পরিবর্তিত হলে পরিবর্তিত আইটেমটি ফিরিয়ে দেওয়া বিভ্রান্তিকর বলে মনে করি। পৃথকভাবে, যদি predictPriceআইটেমটি সংশোধন করতে চলেছে তবে এর একটি নাম থাকা উচিত যা ইঙ্গিত করে যে এটি এটি করতে চলেছে (যেমন setPredictPriceবা এরকম কিছু)।

আমি পছন্দ করব (ক্রমানুসারে)

  1. এটি predictPriceএমন একটি পদ্ধতি ছিলItem (এটি না হওয়ার জন্য মডুলো একটি ভাল কারণ, যা আপনার সামগ্রিক নকশায় ভালভাবে থাকতে পারে) যা ছিল

    • পূর্বাভাস করা দাম, বা

    • setPredictedPriceপরিবর্তে মত একটি নাম ছিল

  2. এটি predictPrice কোনও সংশোধন করেনিItem , তবে পূর্বাভাসিত মূল্য ফেরত দিয়েছে

  3. এটি predictPriceছিল একটি voidপদ্ধতিsetPredictedPrice

  4. এটি predictPriceফিরে এসেছিল this( যে পদ্ধতিতে এটির একটি অংশের অন্যান্য পদ্ধতিতে শৃঙ্খলাবদ্ধতার জন্য) (এবং বলা হয়েছিল setPredictedPrice)


1
জবাবের জন্য ধন্যবাদ. 1 এর প্রতি শ্রদ্ধা রেখে আমরা আইটেমের ভিতরে ভবিষ্যদ্বাণী দিতে পারিনি। 2 একটি ভাল পরামর্শ - আমি মনে করি এটি সম্ভবত এখানে সঠিক সমাধান।
স্কুইমি

2
@Squimmy এবং এটা নিশ্চিত যথেষ্ট, আমি শুধু 15 মিনিট কেউ ব্যবহার দ্বারা সৃষ্ট একটি বাগ সঙ্গে তার আচরণ অতিবাহিত ঠিক : প্যাটার্ন যে আপনার বিরুদ্ধে তর্ক করছিলে a = doSomethingWith(b) পরিবর্তিত b এবং পরিবর্তন, যা পরে আমার কোড উড়িয়ে চিন্তা উপর এটি কি জানত সঙ্গে এটি ফেরত bছিল এটা. :-)
টিজে ক্রাউডার

11

কোনও অবজেক্ট ওরিয়েন্টেড ডিজাইনের দৃষ্টান্তের মধ্যে জিনিসগুলি বস্তুর বাইরেও কোনও জিনিসকে পরিবর্তন করা উচিত নয়। কোনও অবজেক্টের অবস্থার কোনও পরিবর্তন বস্তুর উপর পদ্ধতিগুলির মাধ্যমে করা উচিত

সুতরাং, void predictPrice(Item item)অন্য কোনও শ্রেণীর সদস্য হিসাবে কাজটি ভুল । সি এর দিনগুলিতে গ্রহণযোগ্য হতে পারত, তবে জাভা এবং সি ++ এর জন্য কোনও সামগ্রীর পরিবর্তনগুলি বস্তুর সাথে আরও গভীর মিলন বোঝায় যা সম্ভবত অন্যান্য নকশার সমস্যাগুলি রাস্তায় নামিয়ে আনতে পারে (যখন আপনি শ্রেণিটি রিফেক্টর করে এর ক্ষেত্রগুলি পরিবর্তন করেন, এখন সেই 'প্রেডিক্ট প্রাইস' কে অন্য কোনও ফাইলে পরিবর্তন করা দরকার।

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

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


যদি কোনও হ্যাশের কোনও কিছুর ক্ষেত্রগুলি নিয়ে ঝাঁকুনি দেয় তবে কী ঘটে তা দেখা যাক। কিছু কোড নেওয়া যাক:

import java.util.*;

public class Main {
    public static void main (String[] args) {
        Set set = new HashSet();
        Data d = new Data(1,"foo");
        set.add(d);
        set.add(new Data(2,"bar"));
        System.out.println(set.contains(d));
        d.field1 = 2;
        System.out.println(set.contains(d));
    }

    public static class Data {
        int field1;
        String field2;

        Data(int f1, String f2) {
            field1 = f1;
            field2 = f2;
        }

        public int hashCode() {
            return field2.hashCode() + field1;
        }

        public boolean equals(Object o) {
            if(!(o instanceof Data)) return false;
            Data od = (Data)o;
            return od.field1 == this.field1 && od.field2.equals(this.field2);

        }
    }
}

ideone

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

এই কোডের আউটপুট হল:

true
false

যা ঘটেছে তা হ্যাশকোডটি সন্নিবেশ করানোর সময় ব্যবহৃত হ'ল বস্তুটি হ্যাশটিতে রয়েছে। হ্যাশকোড গণনা করতে ব্যবহৃত মানগুলি পরিবর্তন করা হ্যাশটির পুনরায় সংশোধন করে না। এটি হ্যাশটির চাবি হিসাবে কোনও পরিবর্তনযোগ্য বস্তু স্থাপনের একটি বিপদ ।

সুতরাং, প্রশ্নের মূল দিকটিতে ফিরে গিয়ে, পদ্ধতিটি বলা হচ্ছে "প্যারামিটার হিসাবে এটি কীভাবে বস্তুটি পাচ্ছে তা কীভাবে" জানে না। এটি করার একমাত্র উপায় হিসাবে "অবজেক্টটিকে রূপান্তর করতে দেয়" এর অর্থ হ'ল এমন অনেকগুলি সূক্ষ্ম বাগ রয়েছে যেগুলি ক্রাইপ করতে পারে a একটি হ্যাশের মান হারাবার মতো ... আপনি যদি আরও যুক্ত না করেন এবং হ্যাশ পুনরায় সংশোধন না করেন - আমাকে বিশ্বাস করুন , শিকার করতে একটি বাজে বাগটি দেয় (হ্যাশম্যাপে আরও 20 টি আইটেম যোগ না করা পর্যন্ত আমি মানটি হারাতে থাকি এবং হঠাৎ এটি আবার প্রদর্শিত হয়)।

  • যদি না হয় খুব , বস্তুর পরিবর্তন ফিরে একটি নতুন অবজেক্ট করতে সবচেয়ে নিরাপদ জিনিস ভাল কারণ।
  • যখন হয় বস্তু পরিবর্তন করতে একটি ভাল কারণ, যে পরিবর্তন বস্তুর নিজেই (invoking পদ্ধতি) বরং কিছু বহিরাগত ফাংশন যে তার ক্ষেত্র অলসভাবে ঘোরানো ফেরানো করতে মাধ্যম ছাড়া দ্বারা সম্পন্ন করতে হবে।
    • এটি কম রক্ষণাবেক্ষণ ব্যয়ের সাথে অবজেক্টটিকে রিফেক্টর করতে দেয়।
    • এই অবজেক্ট নিশ্চিত করুন যে মান যে তার হ্যাশকোড গনা করতে পারবেন না পরিবর্তন (বা তার হ্যাশকোড হিসাব অংশ নয়)

সম্পর্কিত: ওভাররাইটিং এবং যদি একটি বিবৃতি শর্তসাপেক্ষ হিসাবে ব্যবহৃত আর্গুমেন্টের মান ফেরত, যদি বিবৃতি একই হয়


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

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

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

2

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

নিম্নলিখিত ডেটা ক্লাস দেওয়া:

class Item {
    public double price = 0;
}

এটা ঠিক আছে:

class Foo {
    private Item bar = new Item();

    public void predictPrice() {
        bar.price = bar.price + 5; // or something
    }
}

// Elsewhere...

Foo foo = Foo();
foo.predictPrice();
System.out.println(foo.bar.price);
// Since I called predictPrice on Foo, which takes and returns nothing, it's
// apparent something might've changed

এবং এটি খুব স্পষ্ট:

class Foo {
    private Item bar = new Item();
}
class Baz {
    public double predictPrice(Item item) {
        return item.price + 5; // or something
    }
}

// Elsewhere...

Foo foo = Foo();
Baz baz = Baz();
foo.bar.price = baz.predictPrice(foo.bar);
System.out.println(foo.bar.price);
// Since I explicitly set foo.bar.price to the return value of predictPrice, it's
// obvious foo.bar.price might've changed

তবে এটি আমার স্বাদগুলির জন্য খুব কাদামাটি এবং রহস্যজনক:

class Foo {
    private Item bar = new Item();
}
class Baz {
    public void predictPrice(Item item) {
        item.price = item.price + 5; // or something
    }
}

// Elsewhere...

Foo foo = Foo();
Baz baz = Baz();
baz.predictPrice(foo.bar);
System.out.println(foo.bar.price);
// In my head, it doesn't appear that to foo, bar, or price changed. It seems to
// me that, if anything, I've placed a predicted price into baz that's based on
// the value of foo.bar.price

দয়া করে কোনও মন্তব্য সহ কোনও ডাউনভোটের সাথে থাকুন যাতে আমি জানি ভবিষ্যতে আরও কীভাবে আরও ভাল উত্তর লিখতে হবে :)
বেন লেগজিও

1

সিনট্যাক্স বিভিন্ন ভাষার মধ্যে পৃথক, এবং কোডের একটি অংশ দেখানো অর্থহীন যা কোনও ভাষার জন্য নির্দিষ্ট নয় কারণ এর অর্থ বিভিন্ন ভাষায় সম্পূর্ণ ভিন্ন জিনিস।

জাভাতে, Itemএটি একটি রেফারেন্স টাইপ - এটি হ'ল অবজেক্টগুলির দিকে নির্দেশকের ধরণ Item। সি ++ এ, এই ধরণের হিসাবে লেখা হয় Item *(একই জিনিসের বাক্য গঠন ভাষার মধ্যে আলাদা হয়)। সুতরাং Item predictPrice(Item item)জাভাতে Item *predictPrice(Item *item)সি ++ এর সমতুল্য । উভয় ক্ষেত্রেই এটি একটি ফাংশন (বা পদ্ধতি) যা কোনও বস্তুর কাছে পয়েন্টার নিয়ে যায় এবং কোনও বস্তুর কাছে পয়েন্টার দেয়।

সি ++ এ, Item(অন্য কিছু ছাড়াই) হ'ল একটি অবজেক্ট টাইপ (ধরে Itemনেওয়া একটি শ্রেণীর নাম)। এই ধরণের একটি মান হ'ল "একটি বস্তু, এবং এমন Item predictPrice(Item item)একটি ক্রিয়াকলাপ ঘোষণা করে যা একটি অবজেক্ট নেয় এবং কোনও বস্তুকে ফেরত দেয়। যেহেতু &ব্যবহৃত হয় না, এটি পাস করে এবং মান দিয়ে ফিরে আসে। এর অর্থ পাস করার সময় অবজেক্টটি অনুলিপি করা হয় এবং ফিরে আসার সময় অনুলিপি করা হয়। জাভাতে কোনও সমতুল্য নেই কারণ জাভাতে বস্তুর ধরণ নেই।

তাহলে এটি কোনটি? আপনি যে প্রশ্নটিতে জিজ্ঞাসা করছেন তার বেশিরভাগ জিনিস (যেমন "আমি বিশ্বাস করি যে এটি একই বস্তুতে যেভাবে পাশ করা হয় ...") এখানে কী পাস হয়েছে এবং কী ফিরে আসবে তা ঠিক বোঝার উপর নির্ভর করে।


1

আমি যে কনভেনশনটি কোডবেসগুলি মেনে দেখেছি তা হ'ল সিন্টেক্স থেকে পরিষ্কার একটি স্টাইল পছন্দ করা। যদি ফাংশনটি মান পরিবর্তন করে তবে পয়েন্টার দিয়ে পাস করতে পছন্দ করুন

void predictPrice(Item * const item);

এই শৈলীর ফলাফল:

  • এটিকে কল করে দেখছেন:

    predictPrice (& my_item);

এবং আপনি জানেন যে শৈলীর সাথে আপনার আনুগত্যের দ্বারা এটি সংশোধিত হবে।

  • অন্যথায় কনস্ট রেফ বা মানটি পাস পছন্দ করুন যখন আপনি ফাংশনটি সংশোধন করতে চান না।

এটি লক্ষ করা উচিত যে এটি যদিও আরও পরিষ্কার বাক্যবিন্যাস, এটি জাভাতে অনুপলব্ধ।
বেন লেগিগিরো

0

যদিও আমার দৃ strong় অগ্রাধিকার নেই, আমি ভোট দিয়ে দেব যে বস্তুটি ফেরত দেওয়া কোনও এপিআইয়ের জন্য আরও নমনীয়তার দিকে নিয়ে যায়।

দ্রষ্টব্য যে এটির বুদ্ধি কেবল তখনই রয়েছে যখন পদ্ধতিটিতে অন্য অবজেক্ট ফেরত দেওয়ার স্বাধীনতা রয়েছে। যদি আপনার জাভাদোক বলে @returns the same value of parameter aতবে এটি অকেজো। তবে আপনার জাভাদোক যদি বলেন @return an instance that holds the same data than parameter a, তবে একই উদাহরণ বা অন্য কোনওটি প্রত্যাবর্তন একটি বাস্তবায়ন বিশদ।

উদাহরণস্বরূপ, আমার বর্তমান প্রকল্পে (জাভা ইই) আমার একটি ব্যবসায় স্তর রয়েছে; কোনও কর্মচারী ডিবিতে সঞ্চয় করতে (এবং একটি স্বয়ংক্রিয় আইডি নির্ধারণ করুন), বলুন, আমার কাছে এমন কিছু কর্মচারী রয়েছে

 public Employee createEmployee(Employee employeeData) {
   this.entityManager.persist(employeeData);
   return this.employeeData;
 }

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

 public Employee createEmployee(Employee employeeData) {
   PreparedStatement ps = this.connection.prepareStatement("INSERT INTO EMPLOYEE(name, surname, data) VALUES(?, ?, ?)");
   ... // set parameters
   ps.execute();
   int id = getIdFromGeneratedKeys(ps);
   ??????
 }

এখন, ????? আমার কাছে তিনটি বিকল্প আছে।

  1. আইডির জন্য একটি সেটার সংজ্ঞা দিন এবং আমি একই জিনিসটি ফিরিয়ে দেব। কুরুচিপূর্ণ, কারণ setIdসর্বত্র পাওয়া যাবে।

  2. কিছু ভারী প্রতিবিম্ব কাজ এবং আইডি আইটেম সেট করুন Employee। নোংরা, তবে কমপক্ষে এটি createEmployeeরেকর্ডের মধ্যেই সীমাবদ্ধ ।

  3. এমন একটি কনস্ট্রাক্টর সরবরাহ করুন যা আসলটি অনুলিপি করে Employeeএবং idসেটটিও গ্রহণ করে ।

  4. ডিবি থেকে অবজেক্টটি পুনরুদ্ধার করুন (কিছু ক্ষেত্রের মান যদি ডিবিতে গণনা করা হয়, বা আপনি যদি রিলেশনশিপটি স্থাপন করতে চান তবে সম্ভবত প্রয়োজন)।

এখন, ১ এবং ২ এর জন্য আপনি একই উদাহরণটি ফিরে আসতে পারেন তবে ৩ এবং ৪ এর জন্য আপনি নতুন উদাহরণগুলি ফিরে আসবেন। প্রিন্সিপালের কাছ থেকে যদি আপনি আপনার এপিআইতে স্থির করে থাকেন যে "আসল" মানটি পদ্ধতি দ্বারা ফিরে আসবে তবে আপনার আরও স্বাধীনতা রয়েছে।

এর বিপরীতে আমি ভাবতে পারি একমাত্র আসল যুক্তি হ'ল, বাস্তবায়ন 1 বা 2 ব্যবহার করে, আপনার এপিআই ব্যবহার করা লোকেরা ফলাফলের কার্যভারটি উপেক্ষা করতে পারে এবং আপনি যদি 3. বা 4. প্রয়োগকরণে পরিবর্তন করেন তবে তাদের কোডটি ভেঙে যাবে)।

যাইহোক, আপনি দেখতে পাচ্ছেন যে, আমার পছন্দ অন্যান্য ব্যক্তিগত পছন্দগুলিতে (যেমন আইডির জন্য কোনও সেটারকে নিষিদ্ধ করার) উপর ভিত্তি করে, তাই সম্ভবত এটি সবার জন্য প্রযোজ্য হবে না।


0

জাভাতে কোডিং করার সময়, দুটি পরিবর্তনগুলির মধ্যে একটির সাথে মিউটেবল টাইপের প্রতিটি বস্তুর ব্যবহারের চেষ্টা করা উচিত:

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

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

আমি পদ্ধতিগুলি অন্তর্নিহিত অবজেক্টটিকে রূপান্তর করতে এবং কোনও রেফারেন্স ফিরিয়ে দিতে পছন্দ করি না, কারণ তারা উপরের দ্বিতীয় প্যাটার্নটি ফিট করার চেহারা দেয়। কয়েকটি ক্ষেত্রে যেখানে পদ্ধতির সহায়ক হতে পারে, কিন্তু কোড যা পরিবর্তন ঘটান বস্তু যাচ্ছে উচিত চেহারা মত সে কি এটি করতে যাচ্ছে; কোডটি myThing = myThing.xyz(q);দেখতে অনেকটা কম দেখায় যেমন এটি myThingসহজেই চিহ্নিত করা বস্তুটিকে পরিবর্তিত করে myThing.xyz(q);

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