দীর্ঘ পরামিতি তালিকাগুলিযুক্ত কনস্ট্রাক্টর ব্যবহার না করেই বড়, অপরিবর্তনীয় বস্তু তৈরি করা

Question 1

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

এটি সঠিক বোধ করে না, এটি ব্যবহার করা শক্ত এবং পঠনযোগ্যতা ভোগ করে।

ক্ষেত্রগুলি তালিকার মতো সংগ্রহের ধরণের কিছু হলেও এটি আরও খারাপ। একটি সরল addSibling(S s)বস্তু তৈরিতে এতটা স্বাচ্ছন্দ্য দেয় তবে বস্তুকে পরিবর্তনীয় করে তোলে।

ছেলেরা এরকম ক্ষেত্রে কী ব্যবহার করবেন?

আমি স্কেলা এবং জাভাতে আছি, তবে আমি মনে করি সমস্যাটি ভাষা অজ্ঞাব্যবস্থার যতক্ষণ না ভাষা অবজেক্ট ভিত্তিক হয়।

সমাধানগুলি আমি ভাবতে পারি:

"দীর্ঘ পরামিতি তালিকার সাথে নির্মাণকারী জঘন্যতা"
বিল্ডার প্যাটার্ন

Question 2

ঠিক আছে, আপনি একবারে সহজেই পড়ার সহজ এবং অপরিবর্তনীয় অবজেক্ট দুটি তৈরি করতে চান?

আমি মনে করি একটি সাবলীল ইন্টারফেস সঠিকভাবে সম্পন্ন হয়েছে আপনাকে সাহায্য করবে।

এটি দেখতে দেখতে (নিখুঁতভাবে তৈরি উদাহরণ):

final Foo immutable = FooFactory.create()
    .whereRangeConstraintsAre(100,300)
    .withColor(Color.BLUE)
    .withArea(234)
    .withInterspacing(12)
    .build();

আমি সাহসী "CONRECTLY DONE" লিখেছি কারণ বেশিরভাগ জাভা প্রোগ্রামাররা সাবলীল ইন্টারফেসগুলি ভুল পেয়ে যায় এবং অবজেক্টটি তৈরির জন্য প্রয়োজনীয় পদ্ধতিতে তাদের বস্তুকে দূষিত করে দেয় যা অবশ্যই সম্পূর্ণ ভুল।

কৌশলটি হ'ল কেবল বিল্ড () পদ্ধতিটি আসলে একটি ফু তৈরি করে (অতএব আপনি ফু অপরিবর্তনীয় হতে পারেন)।

FooFactory.create () , যেখানে এক্সএক্সএক্স (..) এবং এক্সএক্সএক্সএক্স (..) সকলেই "অন্য কিছু" তৈরি করে।

অন্য কিছু হতে পারে এটি একটি ফুফ্যাক্টরি, এটি করার একটি উপায় এখানে ...

আপনি ফুফ্যাক্টরিটি দেখতে এমন হবে:

// Notice the private FooFactory constructor
private FooFactory() {
}

public static FooFactory create() {
    return new FooFactory();
}

public FooFactory withColor( final Color col ) {
    this.color = color;
    return this;
}

public Foo build() {
    return new FooImpl( color, and, all, the, other, parameters, go, here );
}

Question 3

স্কেলা ২.৮ এ, আপনি copyকেস ক্লাসে নামযুক্ত এবং ডিফল্ট প্যারামিটার পাশাপাশি পদ্ধতি ব্যবহার করতে পারেন । এখানে কয়েকটি উদাহরণ কোড রয়েছে:

case class Person(name: String, age: Int, children: List[Person] = List()) {
  def addChild(p: Person) = copy(children = p :: this.children)
}

val parent = Person(name = "Bob", age = 55)
  .addChild(Person("Lisa", 23))
  .addChild(Person("Peter", 16))

Question 4

ঠিক আছে, এটিকে স্কেলা ২.৮ এ বিবেচনা করুন:

case class Person(name: String, 
                  married: Boolean = false, 
                  espouse: Option[String] = None, 
                  children: Set[String] = Set.empty) {
  def marriedTo(whom: String) = this.copy(married = true, espouse = Some(whom))
  def addChild(whom: String) = this.copy(children = children + whom)
}

scala> Person("Joseph").marriedTo("Mary").addChild("Jesus")
res1: Person = Person(Joseph,true,Some(Mary),Set(Jesus))

এটি অবশ্যই সমস্যাগুলির অংশীদারি করে। উদাহরণস্বরূপ, উপার্জন চেষ্টা espouseএবং Option[Person], এবং তারপর দুইজনের একে অপরের সাথে বিবাহ বন্ধনে আবদ্ধ হন পেয়ে। আমি private varএবং / অথবা কোনও privateকনস্ট্রাক্টর প্লাস কারখানায় অবলম্বন না করে সমাধানের কোনও উপায়ের কথা ভাবতে পারি না ।

Question 5

এখানে আরও কয়েকটি বিকল্প রয়েছে:

বিকল্প 1

বাস্তবায়নটিকে নিজেই পরিবর্তনযোগ্য করে তুলুন, তবে ইন্টারফেসগুলি পৃথক করুন যা এটি পরিবর্তনযোগ্য এবং পরিবর্তনীয় হিসাবে প্রকাশ করে। এটি সুইং লাইব্রেরি ডিজাইন থেকে নেওয়া হয়েছে।

public interface Foo {
  X getX();
  Y getY();
}

public interface MutableFoo extends Foo {
  void setX(X x);
  void setY(Y y);
}

public class FooImpl implements MutableFoo {...}

public SomeClassThatUsesFoo {
  public Foo makeFoo(...) {
    MutableFoo ret = new MutableFoo...
    ret.setX(...);
    ret.setY(...);
    return ret; // As Foo, not MutableFoo
  }
}

বিকল্প 2

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

Question 6

এটি বিভিন্ন ধরণের অপরিবর্তনীয়তা মনে রাখতে সহায়তা করে । আপনার ক্ষেত্রে, আমি মনে করি "পপসিকল" অপরিবর্তনশীলতা সত্যিই ভালভাবে কাজ করবে:

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

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

Question 7

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

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

উদাহরণস্বরূপ একটি গ্রাফ প্রান্ত যার গন্তব্য নেই এখনও কোনও বৈধ গ্রাফ প্রান্ত নয়।

Question 8

চারটি সম্ভাবনা বিবেচনা করুন:

new Immutable(one, fish, two, fish, red, fish, blue, fish); /*1 */

params = new ImmutableParameters(); /*2 */
params.setType("fowl");
new Immutable(params);

factory = new ImmutableFactory(); /*3 */
factory.setType("fish");
factory.getInstance();

Immutable boringImmutable = new Immutable(); /* 4 */
Immutable lessBoring = boringImmutable.setType("vegetable");

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

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

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

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

Question 9

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

Question 10

আমি সি # ব্যবহার করি এবং এটি আমার পন্থা। বিবেচনা:

class Foo
{
    // private fields only to be written inside a constructor
    private readonly int i;
    private readonly string s;
    private readonly Bar b;

    // public getter properties
    public int I { get { return i; } }
    // etc.
}

অপশন 1. option চ্ছিক পরামিতি সহ নির্মাতা

public Foo(int i = 0, string s = "bla", Bar b = null)
{
    this.i = i;
    this.s = s;
    this.b = b;
}

যেমন ব্যবহার করা হয় new Foo(5, b: new Bar(whatever))। জাভা বা সি # সংস্করণের জন্য 4.0 এর আগে নয়। তবে এখনও দেখানো মূল্যবান, কারণ এটি কীভাবে সমস্ত সমাধান ভাষা অজ্ঞেয় সম্পর্কিত নয়।

বিকল্প ২. একক প্যারামিটার অবজেক্ট গ্রহণকারী কনস্ট্রাক্টর

public Foo(FooParameters parameters)
{
    this.i = parameters.I;
    // etc.
}

class FooParameters
{
    // public properties with automatically generated private backing fields
    public int I { get; set; }
    public string S { get; set; }
    public Bar B { get; set; }

    // All properties are public, so we don't need a full constructor.
    // For convenience, you could include some commonly used initialization
    // patterns as additional constructors.
    public FooParameters() { }
}

ব্যবহারের উদাহরণ:

FooParameters fp = new FooParameters();
fp.I = 5;
fp.S = "bla";
fp.B = new Bar();
Foo f = new Foo(fp);`

On.০ থেকে সি # এটি অবজেক্ট ইনিশিয়ালাইজার সিনট্যাক্সের সাথে আরও সুন্দর করে তোলে (পূর্ববর্তী উদাহরণের সাথে শব্দার্থগতভাবে সমান):

FooParameters fp = new FooParameters { I = 5, S = "bla", B = new Bar() };
Foo f = new Foo(fp);

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