গেটারস এবং সিটারগুলি কখন ন্যায়সঙ্গত হয়


175

আগত ও সেটটাররা প্রায়শই যথাযথ ওও না হওয়ায় সমালোচিত হয় are অন্যদিকে আমি দেখেছি বেশিরভাগ ওও কোডটিতে বিস্তৃত গিটার এবং সেটটার রয়েছে।

গেটার্স এবং সিটাররা কখন ন্যায়সঙ্গত হয়? আপনি কি সেগুলি এড়াতে চেষ্টা করবেন? তারা সাধারণভাবে অতিরিক্ত ব্যবহার করা হয়?

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

গেটর / সেটার সমালোচনার উত্স (তাদের আরও ভাল দৃশ্যমানতা দেওয়ার জন্য মন্তব্য থেকে নেওয়া কিছু):

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

এবং কোডের একটি পদ্ধতিগত সংস্করণ।

struct Fridge
{
    int cheese;
}

void go_shopping(Fridge fridge)
{
     fridge.cheese += 5;
}

কোডের পরিবর্তক সংস্করণ:

class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);        
}

প্রযোজক এবং সেটটাররা যথাযথ এনক্যাপসুলেশন না করে কোডটিকে আরও জটিল করে তুলেছিল। কারণ অভ্যন্তরীণ অবস্থা অন্যান্য বস্তুর কাছে অ্যাক্সেসযোগ্য আমরা এই গেটর এবং সেটটারগুলি যুক্ত করে পুরোটা লাভ করি না।

স্ট্যাক ওভারফ্লো নিয়ে প্রশ্নটি আগে আলোচনা করা হয়েছিল:


21
Getters and setters are often criticized as being not proper OO- অনুগ্রহপূর্বক
রবার্ট হার্ভে


45
@ জোব, এর কোড আছে কেন? যদি এটি গুরুত্ব সহকারে নেওয়া হয় তবে এটি একটি ভাল প্রশ্ন এবং পবিত্র যুদ্ধের প্রতীক।
পিটার টার্নার

2
@ উইনস্টন ইওয়ার্ট: "... প্রশ্নটি হল আপনার যদি ক্লাসের অভ্যন্তরে ডেটা অ্যাক্সেস করা উচিত তবেই।": ভাল, নুন আপনাকে সমস্ত সদস্যের ভেরিয়েবলের জন্য গেটার এবং সেটটারগুলি প্রয়োগ করতে বাধ্য করে, আপনি কেবলমাত্র আপনার প্রয়োজনীয়গুলি প্রয়োগ করেন। এজন্য আপনি পাবলিক সদস্য ভেরিয়েবলের পরিবর্তে গেটর এবং সেটার ব্যবহার করেন।
জর্জিও 14

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

উত্তর:


162

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

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

  • কিছু ডেটা সদস্য পুরোপুরি অবজেক্টের অভ্যন্তরীণ হতে পারে এবং এতে গেটর বা সেটটার নাও থাকতে পারে।

  • কিছু ডেটা সদস্যদের কেবল পঠনযোগ্য হওয়া উচিত, সুতরাং সেটারগুলির দরকার নেই তবে সেটারের দরকার নেই।

  • কিছু ডেটা সদস্যকে একে অপরের সাথে সামঞ্জস্য রাখতে হতে পারে। এই জাতীয় ক্ষেত্রে আপনি প্রত্যেকের জন্য একটি সেটার সরবরাহ করবেন না, তবে একই সময়ে সেগুলি সেট করার জন্য একটি একক পদ্ধতি, যাতে আপনি ধারাবাহিকতার জন্য মানগুলি পরীক্ষা করতে পারেন।

  • কিছু ডেটা সদস্যকে কেবলমাত্র নির্দিষ্ট উপায়ে পরিবর্তন করা দরকার যেমন নির্দিষ্ট পরিমাণ দ্বারা বর্ধিত বা হ্রাস করা। এই ক্ষেত্রে, আপনি একটি সেটারের পরিবর্তে একটি increment()এবং / অথবা decrement()পদ্ধতি সরবরাহ করবেন।

  • তবুও অন্যদের আসলে পড়ার-লেখার দরকার হতে পারে এবং এতে একটি গেটর এবং সেটার উভয়ই থাকতে পারে।

একটি উদাহরণ বিবেচনা করুন class Person। ধরা যাক যে কোনও ব্যক্তির একটি নাম, একটি সামাজিক সুরক্ষা নম্বর এবং একটি বয়স রয়েছে। আসুন আমরা বলি যে আমরা লোকদের নাম বা সামাজিক সুরক্ষা নম্বরগুলি কখনও পাল্টাতে দিই না। তবে ব্যক্তির বয়স প্রতি বছর 1 বাড়াতে হবে। এই ক্ষেত্রে, আপনি এমন একটি কনস্ট্রাক্টর সরবরাহ করবেন যা প্রদত্ত মানগুলিতে নাম এবং এসএসএন সূচনা করবে এবং যা বয়সটি 0-এ শুরু করবে আপনি একটি পদ্ধতিও সরবরাহ করবেন incrementAge(), যা বয়স বাড়িয়ে দেবে ১. আপনিও সরবরাহ করবেন তিনটি জন্য getters। এক্ষেত্রে কোনও সেটটারের প্রয়োজন নেই।

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

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

উপায় দ্বারা, আপনার উদাহরণে, আমি বর্গ দিতে হবে এবং পদ্ধতি, পরিবর্তে এবং । তারপর আপনি এখনও encapsulation থাকতে হবে।FridgeputCheese()takeCheese()get_cheese()set_cheese()


public class Fridge {
  private List objects;
  private Date warranty;

  /** How the warranty is stored internally is a detail. */
  public Fridge( Date warranty ) {
    // The Fridge can set its internal warranty, but it is not re-exposed.
    setWarranty( warranty );
  }

  /** Doesn't expose how the fridge knows it is empty. */
  public boolean isEmpty() {
    return getObjects().isEmpty();
  }

  /** When the fridge has no more room... */
  public boolean isFull() {
  }

  /** Answers whether the given object will fit. */
  public boolean canStore( Object o ) {
    boolean result = false;

    // Clients may not ask how much room remains in the fridge.
    if( o instanceof PhysicalObject ) {
      PhysicalObject po = (PhysicalObject)o;

      // How the fridge determines its remaining usable volume is a detail.
      // How a physical object determines whether it fits within a specified
      // volume is also a detail.
      result = po.isEnclosedBy( getUsableVolume() );
    }

     return result;
  }

  /** Doesn't expose how the fridge knows its warranty has expired. */
  public boolean isPastWarranty() {
    return getWarranty().before( new Date() );
  }

  /** Doesn't expose how objects are stored in the fridge. */
  public synchronized void store( Object o ) {
    validateExpiration( o );

    // Can the object fit?
    if( canStore( o ) ) {
      getObjects().add( o );
    }
    else {
      throw FridgeFullException( o );
    }
  }

  /** Doesn't expose how objects are removed from the fridge. */
  public synchronized void remove( Object o ) {
    if( !getObjects().contains( o ) ) {
      throw new ObjectNotFoundException( o );
    }

    getObjects().remove( o );

    validateExpiration( o );
  }

  /** Lazily initialized list, an implementation detail. */
  private synchronized List getObjects() {
    if( this.list == null ) { this.list = new List(); }
    return this.list;
  }

  /** How object expiration is determined is also a detail. */
  private void validateExpiration( Object o ) {
    // Objects can answer whether they have gone past a given
    // expiration date. How each object "knows" it has expired
    // is a detail. The Fridge might use a scanner and
    // items might have embedded RFID chips. It's a detail hidden
    // by proper encapsulation.
    if( o implements Expires && ((Expires)o).expiresBefore( today ) ) {
      throw new ExpiredObjectException( o );
    }
  }

  /** This creates a copy of the warranty for immutability purposes. */
  private void setWarranty( Date warranty ) {
    assert warranty != null;
    this.warranty = new Date( warranty.getTime() )
  }
}

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

6
তবে কি ফ্রিজে মেয়াদোত্তীর্ণের তারিখগুলি জানা উচিত নয়, যাতে এটি আপনাকে বলতে পারে যে পনির খারাপ হয়েছে এবং ফেলে দেওয়া উচিত? :) ঠিক আছে, আমাদের এটি বন্ধ করতে হবে! :)
ডিমা

10
ফ্রিজ লজিকের বেশ আকর্ষণীয় আলোচনা আপনি এখানেই চালিয়ে
ম্যাসন হুইলারের

35
হাহাহা, আমি তার জন্য বিজ্ঞাপনটি দেখতে চাই: "এটি একদম নতুন ধরণের ফ্রিজ: সেখানে নেই এমন কোনও জিনিস ধরার চেষ্টা করার সময় এটি আপনার দিকে ছুঁড়ে ফেলে! আপনি কেবল একবার চেষ্টা করে দেখবেন! আপনি উদ্বিগ্ন হন ফ্রিজে স্টাফ করা, এবং ফ্রিজকে অবৈধ আচরণ সম্পর্কে উদ্বিগ্ন হতে দিন! "
গ্যাবলিন

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

41

জাভাতে গেটার এবং সেটটারদের প্রাথমিক কারণটি খুব সহজ:

  • আপনি কেবল ইন্টারফেসে পদ্ধতিগুলি নির্দিষ্ট করতে পারেন ক্ষেত্রগুলি নয়।

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


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

3
@ পিটার টার্নার, স্পষ্টত কিছুই কিছুই ভাষার অন্তর্গত ইন্টারফেস থেকে বাধা দেয় না যাতে বৈশিষ্ট্য অন্তর্ভুক্ত থাকে। কভারগুলির অধীনে যা গেটর / সেটার হিসাবে ভাল প্রয়োগ করা যেতে পারে তবে বৈশিষ্ট্যের জন্য ইন্টারফেস সংজ্ঞাগুলিতে সমর্থন যোগ করা যথেষ্ট সহজ হবে।
উইনস্টন ইওয়ার্ট

2
@ উইনস্টন, আপনাকে শেষ পর্যন্ত ক্লাসগুলিকে একে অপরের মধ্যে তথ্য পাস করার জন্য প্রকৃতপক্ষে কাজ করার অনুমতি দেওয়ার প্রয়োজন হবে। এর পরিবর্তে আপনি কী পরামর্শ করবেন?

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

6
অন্য উদাহরণটি ধরার জন্য, একটি টেট্রিস টুকরো বিবেচনা করুন। টেট্রিস টুকরাটির কিছু অভ্যন্তরীণ অবস্থা রয়েছে যেমন ব্লক_ টাইপ, আবর্তন, অবস্থান। আপনি গেটব্লকটাইপ (), গেটরোটেশন (), গেটপজিশন () এর মতো গিটার পেতে পারেন। তবে আপনার সত্যই করা উচিত নয়। আপনার যা হওয়া উচিত তা হ'ল একটি getSquares () পদ্ধতি যা এই টুকরা দ্বারা দখলকৃত সমস্ত স্কোয়ারের একটি তালিকা ফেরত দেয়। আপনার কাছে সেটপজিশন () বা সেটরোটেশন () এর মতো স্টাফ থাকা উচিত নয়। পরিবর্তে, আপনার মুভলেফ্ট (), মুভরাইট (), ঘোরানো (), পতন () এর মতো অপারেশন থাকা উচিত।
উইনস্টন ইওয়ার্ট

20

Http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_ এবং থেকে

জাভাবিয়ান শৈলী:

connection.setUser("dukie");
connection.setPwd("duke");
connection.initialize();

OO যেমন পণ্য-শৈলী:

connection.connect("dukie","duke");

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

আপনার প্রশ্নটি হল, কখন একজন গেটার / সেটটার ন্যায়সঙ্গত হয়? সম্ভবত যখন কোনও মোড পরিবর্তনের প্রয়োজন হয়, বা আপনাকে কিছু তথ্যের জন্য কোনও বিষয়টিকে জিজ্ঞাসাবাদ করতে হবে।

myObject.GetStatus();
myObject.SomeCapabilitySwitch = true;

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


6
ওও-স্টাইলটি কেন "সমস্ত আর্গুমেন্টকে প্যারামিটার হিসাবে দেয়"?

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

1
@TheLQ: সি # 4.0 কনস্ট্রাক্টর এবং পদ্ধতি কলগুলিতে alচ্ছিক এবং নামযুক্ত পরামিতিগুলিকে অনুমতি দিয়ে এটিকে আরও সহজ করে তোলে।
রবার্ট হার্ভে

7
@TheLQ ফ্লুথ সিনট্যাক্স সহ নির্মাতা এর জন্য, উদাহরণস্বরূপ পেয়ারা এর ম্যাপমেকার দেখুন
মার্টিনাস

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

13

গেটার্স এবং সিটাররা কখন ন্যায়সঙ্গত হয়?

আচরণটি "get" এবং "সেট" আসলে আপনার মডেলের আচরণের সাথে মিলে যায়, যা ব্যবহারিকভাবে কখনও হয় না

ব্যবসায়ের ডোমেনের আচরণ পরিষ্কার নয় বলে অন্য প্রতিটি ব্যবহার কেবল একটি প্রতারণা।

সম্পাদন করা

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

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

বাস্তবতা হ'ল আপনার ডোমেন স্পেসের যে কোনও সিস্টেমে গিটার এবং সেটটার রয়েছে এটি অত্যন্ত সম্ভাবনা নয়। আপনি বেতন বাছাইয়ের জন্য দায়বদ্ধ সেই পুরুষ বা মহিলার কাছে যেতে পারবেন না এবং কেবল "এই বেতনটি এক্সে সেট করুন" বা "আমাকে এই বেতনটি পান" বলতে পারবেন না । এ জাতীয় আচরণের সহজলভ্যতা নেই

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

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

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


এটি পূর্বের 17 উত্তরগুলিতে তৈরি এবং ব্যাখ্যা করা পয়েন্টগুলির
gnat

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

set/getবেতন হিসাবে না পেলে পে-রোলের ইন্টারফেসটি কী বলে আপনি কেবল মনে করেন ?
উইনস্টন ইওয়ার্ট

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

3
বা অন্যভাবে বলতে গেলে সেট_সালারি (নতুন_সালারি, কর্মচারী_আইডি) এবং অনুমোদিত_সালারি_আপডেট (কর্মচারী_কন্ট্র্যাক্ট, অথরিজিং_ম্যানেজার) এর মধ্যে বেশ পার্থক্য রয়েছে। প্রক্রিয়াটির অভ্যন্তরীণ ব্যবসায়ের প্রক্রিয়াটির মডেল করা উচিত
Cormac Mulhall

11

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

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


6
একজন গেটর এবং সেটারের অর্থ হ'ল বৈশিষ্ট্যটি, ক্ষেত্র নয়, ইন্টারফেসের অংশ। ধরুন গেটবার্থডেট () এবং সেটবার্থডেট () "yyyy / মিমি / ডিডি" নেয় তবে সঞ্চিত ক্ষেত্রটি 01/01/1000 থেকে দিনের সংখ্যা। আপনি এটি 01/01/0001 এ পরিবর্তন করতে পারেন এবং গেটর এবং সেটার ইন্টারফেসটি একই রাখবে। বিশেষত 'পাবলিক' অর্থ পাবলিকভাবে ট্র্যাশযোগ্য, ভেরিয়েবলগুলি কখনই সর্বজনীন হওয়া উচিত নয়; ইনকামিং মানটি যাচাই করতে, সম্পর্কিত সম্পর্কিত ক্ষেত্রগুলি আপডেট করতে, প্রয়োজনীয় হিসাবে রূপান্তর করা ইত্যাদি জন্য সর্বদা একটি সেটার ব্যবহার করুন the অভ্যন্তরীণ স্টোরেজ পরিবর্তনের ক্ষেত্রে গেটর ব্যবহার করার চেষ্টা করুন।
অ্যান্ডি ক্যানফিল্ড

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

3

ক্ষেত্রটি সরাসরি বা পদ্ধতির মাধ্যমে অ্যাক্সেসযোগ্য কিনা তা গুরুত্বপূর্ণ নয়।

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

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

BTW। আমি সর্বজনীন চূড়ান্ত ক্ষেত্রগুলির সাথে সাধারণ অপরিবর্তনীয় মান হোল্ডিং ক্লাস ব্যবহার করতে চাই।


এটি বেশ কয়েকটি বিষয় যা এড়ানো উচিত। ক্ষেত্র থেকে সম্পত্তি / গেটর / সেটারে যাওয়া বেশিরভাগ ভাষায় একটি ব্রেকিং পরিবর্তন।
মিঃডোসু

2

ইন্টারফেস একই রাখার সময় আপনি নিজের ইন্টার্নালগুলি যা কিছুতে পরিবর্তন করতে চাইতে পারেন। যদি আপনার ইন্টারফেসগুলি পৃথক না হয়, আপনার কোডগুলি সেগুলি ভঙ্গ করবে না। আপনি এখনও নিজের ইন্টেরালগুলি নিজের ইচ্ছামত পরিবর্তন করতে পারেন।


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

0

আমার দৃষ্টিভঙ্গি এটি -

আমি পরে যখন ডেটা দিয়ে হাতছাড়া করার প্রত্যাশা করি তখন একজন গিটার / সেটারটি ন্যায়সঙ্গত হয়। এছাড়াও, যদি পরিবর্তনটি ঘটে থাকে তবে আমি প্রায়শই ডেটাটিকে একটি গিটার / সেটারের মধ্যে ঠেলা দিয়ে থাকি।

যদি এটি পিওডি কাঠামো হয় তবে আমি স্লট উপলব্ধ রাখি।

আরও বিমূর্ত স্তরে প্রশ্নটি হল "কে ডেটা পরিচালনা করে" এবং এটি প্রকল্পের উপর নির্ভর করে।


0

যদি গেটার এবং সেটটারগুলি ব্যবহার করে জটিল মনে হয় তবে সমস্যাটি ভাষা হতে পারে, ধারণাটি নয় itself

এখানে রুবিতে লেখা দ্বিতীয় উদাহরণের কোডটি :

class Fridge
  attr_accessor :cheese
end

def go_shopping fridge
  fridge.cheese += 5
end

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

class Fridge
  attr_accessor :cheese

  def cheese
    @cheese || 0
  end
end

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


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

0

Sizeপ্রস্থ এবং উচ্চতা encapsulates যা একটি শ্রেণীর বিবেচনা করুন । আমি কনস্ট্রাক্টর ব্যবহার করে সেটারগুলি মুছে ফেলতে পারি তবে কীভাবে এটি আমাকে আয়তক্ষেত্র আঁকতে সহায়তা করে Size? প্রস্থ এবং উচ্চতা শ্রেণীর অভ্যন্তরীণ ডেটা নয়; তারা ভাগ করা ডেটা যা অবশ্যই আকারের গ্রাহকদের জন্য উপলব্ধ।

বস্তুগুলি আচরণ এবং রাষ্ট্র - বা বৈশিষ্ট্যগুলি নিয়ে গঠিত। যদি কোনও উন্মুক্ত রাষ্ট্র না থাকে তবে কেবল আচরণগুলি সর্বজনীন।

রাষ্ট্র ব্যতীত আপনি কীভাবে সামগ্রীর সংগ্রহকে বাছাই করবেন? আপনি কীভাবে কোনও বস্তুর নির্দিষ্ট উদাহরণ অনুসন্ধান করবেন? আপনি যদি কেবল কনস্ট্রাক্টর ব্যবহার করেন, যখন আপনার অবজেক্টের গুণাবলীর দীর্ঘ তালিকা থাকবে তখন কী হবে?

কোনও পদ্ধতির প্যারামিটার কখনই বৈধতা ছাড়াই খাওয়া উচিত নয়। তাই লিখতে অলসতা:

setMyField(int myField){
    this.myField = myField;
}

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

গেটার্স, সেটটার্স, প্রপার্টি, মিউটররা, আপনি যা চান তা তাদের কল করুন তবে সেগুলি প্রয়োজনীয়।


তবে কমপক্ষে আপনার কাছে একটি সামঞ্জস্যপূর্ণ পাবলিক ইন্টারফেস রয়েছে যা আপনি ফিরে এসে আপনার গ্রাহকদের কোড ভঙ্গ না করে বৈধতা বিধিগুলিতে স্থাপন করতে পারেন। এটা সত্যি না. রাস্তার নিচে আরও বৈধতার বিধি যুক্ত করা খুব ভাল "আপনার গ্রাহকদের কোড ভঙ্গ" করতে পারে। intউদাহরণস্বরূপ একটি ভেরিয়েবল নিন , এবং কল্পনা করুন যে আপনি কেবল অবৈধিক মানগুলি গ্রহণ করার জন্য একটি বৈধতা রুল যুক্ত করার সিদ্ধান্ত নিয়েছেন। সমস্যাটি হ'ল আপনার গ্রাহকের কোডটি ইতিমধ্যে এটি একটি নেতিবাচক মান সেট করার সম্ভাবনা উপর নির্ভর করতে পারে ...
jub0bs

0

যদি গেটার্স এবং সেটটাররা এনক্যাপসুলেশন এবং সত্য ওও লঙ্ঘন করে তবে আমি গুরুতরভাবে সমস্যায় আছি।

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

আমি জাভাতে মাজেস তৈরি করে এমন একটি প্রোগ্রাম লিখতে পেরেছি এবং আমার ক্লাস রয়েছে যা "ম্যাজ স্কয়ার্স" উপস্থাপন করে। এই শ্রেণিতে আমার কাছে ডেটা রয়েছে যা স্থানাঙ্ক, দেয়াল এবং বুলিয়ান ইত্যাদি উপস্থাপন করে etc.

আমার এই ডেটাটি পরিবর্তন / কৌশল / অ্যাক্সেস করার কিছু উপায় থাকতে হবে! গেটার এবং সেটটার ছাড়া আমি কী করব? জাভা বৈশিষ্ট্যগুলি ব্যবহার করে না এবং আমার সমস্ত শ্রেণীর ডেটা সেট করে যা এই শ্রেণীর কাছে স্থানীয় হয় এটি অবশ্যই এনক্যাপসুলেশন এবং ওওর লঙ্ঘন।


6
এখানে প্রশ্নটি রয়েছে: আপনি যদি এই সমস্ত ক্ষেত্রগুলি সর্বজনীন করে থাকেন, এবং আপনার কোডটি কীভাবে আলাদা হবে তা উত্স এবং সেটটারগুলি ব্যবহার বন্ধ করে দিয়েছেন?
উইনস্টন ইওয়ার্ট

তত্ত্বগতভাবে, এটি না। এমনকি এই সময়ে একটি ক্লাস করা কেন? একই যুক্তি কিছু দিয়ে তৈরি করা যেতে পারে। তবে আমার নীচের পোস্টটি মনে হয় এটি আরও মার্জিতভাবে বলেছে। (Getters এবং setters একটি উপায় নিরাপদে একটি বস্তু একটি মান হাতে, অথবা যে বস্তুর থেকে একটি মান পুনরুদ্ধার করতে হয়।) পোস্টে যায় ..
ব্রায়ান হ্যারিংটন

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

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

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

-1

প্রথমত দুটি ধরণের অবজেক্ট রয়েছে যার বিষয়ে আমি মন্তব্য করব, মান এবং পরিষেবার ধরণ।

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

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


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

-1

গেটার / সেটারকে যেমন অন্য কোনও পাবলিক পদ্ধতি ন্যায়সঙ্গত বলে ন্যায়সঙ্গত করা হয়। ন্যায্যতা মূলত কারণ আমরা বাইরের বিশ্বের একটি ইন্টারফেস সরবরাহ করতে চাই যা আমাদের শ্রেণিটি অন্যান্য শ্রেণীর সাথে কীভাবে ইন্টারঅ্যাক্ট করে তা নির্ধারণ করে। আমরা মূলত এটি করি কারণ আমরা পৃথক সংস্থার মধ্যে সংযোগ কমাতে চাই। সংযুক্তি হ্রাস অনেক কারণেই ভাল জিনিস:

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

-1

হ্যাঁ, গেটার্স এবং সেটটারগুলি অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংয়ের একটি বিরোধী নিদর্শন এবং এটি কখনই ব্যবহার করা উচিত নয় : http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html । সংক্ষেপে, তারা বস্তু-ভিত্তিক দৃষ্টান্তের সাথে খাপ খায় না কারণ তারা আপনাকে কোনও ডেটা স্ট্রাকচারের মতো কোনও অবজেক্টের সাথে আচরণ করতে উত্সাহিত করে। যা একটি বড় ভুল ধারণা।


2
এটি পূর্বের 18 টি উত্তরগুলিতে তৈরি এবং ব্যাখ্যা করা পয়েন্টগুলির চেয়ে বেশি কিছু দেওয়ার প্রস্তাব দিচ্ছে না
gnat

4
এটি কখনও বলার অপেক্ষা রাখে না
উইনস্টন ইওয়ার্ট

-4

আমি আশাবাদী যে আইডিই আপনার প্রোগ্রামিং ল্যাঙ্গুয়েজ অটো তৈরি করে এমন সংস্থা কর্তৃক বিকাশিত যে কোনও কিছুই "অবজেক্ট ওরিয়েন্টেশনের মূলনীতি" লঙ্ঘন করে না।

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

এগুলি ব্যবহারের কারণ হ'ল যথাযথ এনক্যাপসুলেশন হতে পারে এবং এতক্ষণ আপনি যে স্তরটি সরিয়ে ফেলেছেন যা আপনার জিনিসটির সাথে বানর রাখে এমন ব্যক্তিকে আপনার বস্তু অনুভব করতে দেয়, আপনি সঠিকভাবে না জেনেও তাকে সেই জিনিসটি সরিয়ে নিতে পারেন?

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


4
এবং আমি যখনই ভেরিয়েবলটি ডিল করি তখন সেটফু () এবং getFoo () কল করতে প্রচুর কোড যুক্ত করে আমি কী পেয়েছি?
উইনস্টন ইওয়ার্ট

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

2
এনক্যাপসুলেশনটির সুবিধা হ'ল নির্দিষ্ট মানগুলির সাথে সম্পর্কিত সমস্ত যুক্তি এক জায়গায় (কম বেশি) থাকে) আমি এটি গেটর এবং সেটটারগুলির সাথে পাই না। সুতরাং, আমি মনে করি না যে আমি তাদের জন্য প্রচুর উপকার পেয়েছি।
উইনস্টন ইওয়ার্ট

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

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

-4

আমি ভেবেছিলাম আমাদের এখানে আরও সাধারণ উত্তর হবে?

গেটার্স এবং সেটটাররা সাধারণভাবে অত্যন্ত ওওপি (অন্য যে কোনও কিছু বললে ভুল, সে হিসাবে সহজ)।

যদিও আপনাকে ওভার ইঞ্জিনিয়ার না রাখার কথা মনে করতে হবে, কখনই কোনও গেটর বা সেটার তৈরি করবেন না যা প্রয়োজন নেই। যে কোনও তথ্য যা আপনি অন্য শ্রেণীর দ্বারা ব্যবহার করা হচ্ছে না তার জন্য আপনার কোনও গেটর বা সেটটার না থাকা উচিত।

যদিও, আপনি ক্ষেত্রগুলি সর্বজনীন না করে পরিবর্তে গিটার এবং সেটারগুলি রাখার কারণটি বেশিরভাগ ক্ষেত্রে:

  • ক্ষেত্রগুলি ব্যবহার করে সঠিক পরীক্ষা করা সম্ভব নয়। প্রযোজক / সেটাররা সে ক্ষেত্রে আরও ভাল।

  • রিয়েল টাইম প্রোগ্রামিং সেটিংয়ে ক্ষেত্রগুলি সঠিকভাবে ব্যবহার করা অসম্ভব। সিঙ্ক্রোনাইজড গেটার্স / সেটারগুলি যাওয়ার উপায়।

  • ইন্টারফেসের বিষয় (ইতিমধ্যে ব্যাখ্যা করা হয়েছে তাই আমি করব না)।

  • সিস্টেমটি সঠিকভাবে পুনরায় ব্যবহার করার সময় এটি ব্যবহার করা সহজ।

  • কোন ক্লাসটি আপনার ক্লাসটি ব্যবহার করছে এবং আপনি যদি গেটর / সেটারের তুলনায় কোনও ক্ষেত্র পরিবর্তন করেন তবে কোনটি ভাঙ্গবে তা জানা অনেক কঠিন।

আপনি যখন কোনও অফিশিয়াল প্রজেক্ট তৈরি না করে কেবল মজাদার জন্য করছেন এবং গিটার / সেটটারদের বিরক্ত করতে না পারছেন কেবল তখনই আপনি গিটার / সেটারের পরিবর্তে কোনও সর্বজনীন ক্ষেত্র ব্যবহার করেন।


2
পরীক্ষার জন্য +1। হতবাক যে কেউ এর আগে উল্লেখ করেনি। বৈশিষ্ট্যের আরেকটি দরকারী বৈশিষ্ট্য সেগুলি ডিবাগ করছে। (ক্ষেত্রগুলির জন্য হার্ডওয়ার / মেমরি ব্রেকপয়েন্টগুলির প্রয়োজনের চেয়ে কোডে একটি ব্রেকপয়েন্ট সন্নিবেশ করা অনেক সহজ)।
মার্ক এইচ

9
গেটার্স এবং সেটারদের আপত্তি হ'ল চেতনা এবং অভিপ্রায় উপেক্ষা করার সময় তারা প্রায়শই ওওপি আইনের চিঠিটি অনুসরণ করতে ব্যবহৃত হয়। ওওপি বলছে যে আপনি অন্য বস্তুগুলিকে আপনার অভ্যন্তরীণ সাথে মেক করার অনুমতি দেবেন না। আপনি যদি গেটারস এবং সেটটারগুলি সংজ্ঞায়িত করেন যা আপনাকে যেভাবেই করতে দেয় তবে আপনি OOP লঙ্ঘন করবেন।
উইনস্টন ইওয়ার্ট

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

4
@ সিকিওরিয়ান: আমি আপনার উত্তরের সাথে একমত নই আপনি দুটি বিকল্প উপস্থাপন করছেন বলে মনে হচ্ছে: হয় গিটার / সেটার ব্যবহার করে বা ক্ষেত্রগুলি সর্বজনীন করে তোলা। তবে তৃতীয় বিকল্প রয়েছে: গেটার / সেটার বা এক্সপোজিং ফিল্ডগুলি ব্যবহার করে না! অভ্যন্তরীণ ক্ষেত্রের অবস্থার জন্য কেন আপনাকে পরীক্ষা করতে হবে? আপনি কি আপনার বস্তুর পাবলিক এপিআই পরীক্ষা করা উচিত নয়?
আন্দ্রেস এফ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.