Typescript: स्थिर विधियों को परिभाषित करने के लिए समर्थन इंटरफेस जोड़ें

इससे हासिल करने के लिए आप क्या करना चाहते हैं? आप परिदृश्य पर विस्तृत कर सकते हैं?

मुझे लगता है कि abstract क्लासेस वही हैं जो आप ढूंढ रहे हैं।

@mhegazy
उदाहरण:

interface JsonSerializable {
      public static fromJson(obj: any);
      public toJson(): string;
}

@rozzzly इस उदाहरण में, abstract class मान्य नहीं है।

मुझे लगता है कि यह बहुत अच्छा होगा! जावा ने अंतिम संस्करण में इस कार्यक्षमता को जोड़ा।

@Serginho
मुझे लगता है कि आपको यह दिलचस्प लग सकता है:

interface JsonSerializableStatic<C extends new (...args) => JsonSerializable<C>> {
  fromJson(json: string): JsonSerializable<C>;
}

interface JsonSerializable<C extends new (...args) => any> {
  toJson: () => string;
  constructor: C;
}

interface A extends JsonSerializable<typeof A> { }
class A implements JsonSerializable<typeof A> {

  constructor(readonly id: number, readonly name: string) { }
  toJson() { return JSON.stringify(this); }

  static fromJson(json: string): A {
    const obj = JSON.parse(json);
    return new A(obj.id, obj.name);
  }
}

const a = new A(1, 'Charlize');

const json = a.toJson();

const y = A.fromJson(json);
console.info(a, json, y);
console.info(new a.constructor(1, 'Theron'));
const m = new A.prototype.constructor(1, 'Charlize Theron');
console.info(m);

@aluanhaddad मुझे आपका कोड कुछ ऐसी चीज़ का वर्कअराउंड लगता है जो स्पष्ट है।

interface JsonSerializable {
      public static fromJson(obj: any);
      public toJson(): string;
}

जिसे आप अधिक स्पष्ट रूप से देखते हैं?

@aluanhaddad मुझे आपका कोड कुछ ऐसी चीज़ का वर्कअराउंड लगता है जो स्पष्ट है।

इंटरफ़ेस JsonSerializable {
सार्वजनिक स्थैतिकजसन (obj: any) से;
सार्वजनिक toJson (): स्ट्रिंग;
}
जिसे आप अधिक स्पष्ट रूप से देखते हैं?

वास्तव में, लेकिन मेरा एक वर्कअराउंड नहीं है, यह आपके usecase का औचित्य है। स्थैतिक deserialization और उदाहरण serialization एक वर्ग पर वर्ग के आधार पर लागू किया है और इस तरह समझाया और प्रकार है।
आपकी घोषणा:

interface JsonSerializable {
     public static fromJson(obj: any);
     public toJson(): string;
}

यह अप्रासंगिक है क्योंकि यह मूल रूप से JSON ऑब्जेक्ट के इंटरफ़ेस को फिर से घोषित करता है। यह बिल्कुल किसी भी तरह से स्थिर इंटरफ़ेस विधियों की आवश्यकता नहीं है।

आप इंटरफ़ेस की अवधारणा को खो रहे हैं। class A implements JsonSerializable मुझे दोनों विधियों को लागू करना चाहिए। लेकिन वास्तव में मुझे लागू करने के लिए बनाता है:

toJson: () => string;
constructor: new (...args) => JsonSerializableStatic<C>;

यह एक स्पष्ट समाधान नहीं है।

इंटरफेस पर स्थिर तरीकों को परिभाषित नहीं करने के लिए कोई तकनीकी कारण नहीं है।

@Serginho मैं यह तर्क नहीं दे रहा हूं कि स्थिति आदर्श है। मैं केवल यह बताना चाह रहा था कि इसे व्यक्त किया जा सकता है।

@aluanhaddad चलो! अपना दिमाग खोलो। क्या आपको लगता है कि टाइपस्क्रिप्ट को इंटरफेस में स्थिर तरीकों की अनुमति देनी चाहिए? यह अंतिम संस्करण में जावा 8 में लागू किया गया था, इसलिए मुझे लगता है कि मैं बकवास नहीं कर रहा हूं।

@Serginho मुझे नहीं लगता कि यह टाइपस्क्रिप्ट के लिए विशेष रूप से अच्छा है। इंटरफेस को एक वस्तु प्रदान करने वाली कार्यक्षमता को परिभाषित करना चाहिए। यह कार्यक्षमता अधिक होने योग्य और विनिमेय होनी चाहिए (यही कारण है कि इंटरफ़ेस विधियाँ आभासी हैं)। स्टेटिक्स गतिशील व्यवहार / आभासी तरीकों के लिए एक समानांतर अवधारणा है। दोनों को इंटरव्यू देना मेरे लिए किसी डिज़ाइन पॉइंट से सही नहीं लगता।

जैसा कि @aluanhaddad ने पहले ही लिखा था, टाइपस्क्रिप्ट में वास्तव में पहले से ही एक तंत्र है जो आप चाहते हैं। बड़ा अंतर यह है कि इस मामले में आप कक्षा को एक वस्तु के रूप में मानते हैं, जो तार्किक रूप से सुसंगत है। मेरे दृष्टिकोण से, आपके द्वारा प्रस्तावित प्रस्ताव टाइपस्क्रिप्ट (और जावास्क्रिप्ट विकास) के लिए विशेष रूप से अच्छी तरह से अनुकूल नहीं है क्योंकि कक्षाएं एक हैक / द्वितीय श्रेणी के नागरिकों की तरह हैं। वर्तमान में प्रचलित पैटर्न ducktyping / shape प्रोग्रामिंग पर भरोसा करते हैं, कठोर कक्षाओं पर नहीं।

मुझे लगता है, आप अपने दिमाग को भी खोल सकते हैं और प्रोग्रामिंग की विभिन्न शैलियों की कोशिश कर सकते हैं। दुनिया न तो OOP से शुरू होती है और न ही समाप्त होती है। आपको फ़ंक्शंस, सादे ऑब्जेक्ट्स (और कुछ हद तक) प्रोटोटाइप के साथ प्रोग्रामिंग मिल सकती है, जो सुखद और भी बेहतर है। इस तरह की शैली जावास्क्रिप्ट के साथ शुरू होने के लिए बहुत अधिक है। एक तरफ ध्यान दें, मैं मानता हूं कि जेएस धीरे-धीरे ओओपी-एस्क पैटर्न (कम से कम समिति स्तर पर) की ओर बढ़ रहा है, लेकिन ऐसा इसलिए है क्योंकि लोगों की भारी धक्का-मुक्की विभिन्न प्रोग्रामिंग प्रतिमानों और विकास तकनीकों के साथ सहज नहीं है। मेरे लिए यह बहुत दुखद और निराशाजनक बात है।

जैसा कि @gcnew ने कहा, एक इंटरफ़ेस एक व्यक्तिगत वस्तु के आकार का वर्णन करता है, न कि उसके वर्ग का। लेकिन इसका कोई कारण नहीं है कि हम वर्ग के आकार का वर्णन करने के लिए इंटरफ़ेस का उपयोग नहीं कर सकते हैं, क्योंकि कक्षाएं भी ऑब्जेक्ट हैं।

import assert = require("assert");

interface JsonSerializableStatic<JsonType, InstanceType extends JsonSerializable<JsonType>> {
    fromJson(obj: JsonType): InstanceType;
}
interface JsonSerializable<JsonType> {
    toJson(): JsonType;
}

interface PointJson { x: number; y: number; }
class Point /*static implements JsonSerializableStatic<PointJson, Point>*/ {
    static fromJson(obj: PointJson): Point {
        return new Point(obj.x, obj.y)
    }

    constructor(readonly x: number, readonly y: number) {}

    toJson(): PointJson {
        return { x: this.x, y: this.y };
    }
}
// Hack for 'static implements'
const _: JsonSerializableStatic<PointJson, Point> = Point;

function testSerialization<JsonType, InstanceType extends JsonSerializable<JsonType>>(cls: JsonSerializableStatic<JsonType, InstanceType>, json: JsonType) {
    const instance: InstanceType = cls.fromJson(json);
    const outJson: JsonType = instance.toJson();
    assert.deepEqual(json, outJson);
}
testSerialization(Point, { x: 1, y: 2 });

एक संकलन त्रुटि में toJson या fromJson के हस्ताक्षर को पूरा करने में विफल। (दुर्भाग्य से, विधि के बजाय त्रुटि const _ ।)

संभवतः संबंधित (चूंकि यह स्थैतिक विधियों को टाइप करने से संबंधित है): # 5863।

@aluanhaddad : आपके उदाहरण में एक गलती है: JsonSerializable constructor सदस्य वास्तव में constructor नामक एक प्रॉपर्टी का उल्लेख करेंगे, जिसे new साथ आह्वान करने पर JsonSerializableStatic । इसका मतलब यह होगा कि (new ((new X()).constructor)).fromJson({}) को काम करना होगा। यह सफलतापूर्वक संकलित करने का कारण यह है कि interface A extends JsonSerializable<typeof A> कार्यान्वयन वास्तव में इसकी जाँच के बिना मान्य होने की घोषणा करता है। उदाहरण के लिए, यह त्रुटि के बिना संकलित है:

interface I { m(): void; }
interface A extends I { }
// No compile error
class A implements I { em() {} }

@Serginho एक जावा उपयोगकर्ता नहीं है, लेकिन यह ऐसा नहीं लगता है कि भाषा आपको एक वर्ग के स्थिर पक्ष के लिए एक इंटरफ़ेस को परिभाषित करने की अनुमति देती है (जिसका अर्थ है कि इंटरफ़ेस को लागू करने वाले वर्ग को एक स्थिर विधि को लागू करने के लिए लागू करना होगा)। जावा आपको इंटरफ़ेस में एक शरीर के साथ एक स्थिर विधि को परिभाषित करने की अनुमति देता है, टाइपस्क्रिप्ट जिसके बराबर होगा:

interface I { ... }
namespace I {
   export function interfaceStaticMethod() {}
}

यदि आप एक सामान्य फैक्टरी बनाने की कोशिश कर रहे हैं तो क्या होगा?

interface Factorizable {
  static factory<U>(str: string): U
}

class Foo {
  private data: string[] = []
  bar<T extends Factorizable>(): T[] {
    return this.data.map(T.factory);
  }
}

class Bar implements Factorizable {
  static factory(str: string): Bar {
    // ...
  }
}

// Usage
var x = new Foo();
var y: Bar[] = x.bar();

मैं यहाँ interface सिंटैक्स के बारे में निश्चित नहीं हूँ जो मैं यहाँ प्रस्तावित कर रहा हूँ लेकिन मुझे पता है कि "उपयोग" सिंटैक्स वही है जिसे मैं प्राप्त करने की कोशिश कर रहा हूँ। यह एक ऐसा पैटर्न है जिसका मैं अक्सर स्विफ्ट ( protocols का उपयोग करके) करता हूं और मुझे लगता है कि यह टाइपस्क्रिप्ट में वास्तव में अच्छा होगा। हालांकि यह एक भाषा डिजाइनर या संकलक कार्यान्वयनकर्ता नहीं है लेकिन मुझे यकीन नहीं है कि यह टाइपस्क्रिप्ट के इच्छित दिशा में फिट बैठता है या इसे लागू करने के लिए यथार्थवादी है।

कक्षा में implement इंटरफ़ेस नहीं है। आप बस इंटरफ़ेस को परिभाषित करते हैं, और संरचनात्मक प्रकार के चेक उपयोग स्थल पर किसी भी मुद्दे को कैश करेंगे, उदाहरण के लिए:

interface Factorizable<U> {
    factory(str: string): U
}

class Foo {
  private data: string[] = []
  bar<T>(factory: Factorizable<T>): T[] {
    return this.data.map(factory.factory);
  }
}

class Bar {
  static factory(str: string): Bar {
    // ...
  }
}

// Usage
var x = new Foo();
var y = x.bar(Bar); // Bar[]

@mhegazy जो अपेक्षाकृत अच्छा समाधान है। प्रदान करने के लिए धन्यवाद! 🙏

अभी भी दो चीजें हैं जो मुझे असुविधा देती हैं (आमतौर पर न तो शो स्टॉपर्स हैं):

1. हम अभी भी उस Bar स्पष्ट रूप से लागू करने में सक्षम नहीं हैं या Factorizable अनुरूप नहीं हैं।

   • व्यवहार में, मुझे लगता है कि यह वास्तव में कोई समस्या नहीं है। चूँकि यह सच होगा कि यदि Factorizable इंटरफ़ेस असंगत तरीके से बदल जाता है तो उपयोग x.bar(Bar) त्रुटि होने लगेगी और फिर आप बहाव परिवर्तन को ठीक कर लेंगे।

2. मेरे लिए, असाइनमेंट के दाईं ओर y के प्रकार की घोषणा करना अभी भी एक संज्ञानात्मक बोझ है।

   • वाइडर अभी भी इस वाक्यविन्यास को इस व्यवहार को सक्षम करेगा: var y: Baz[] = x.bar(Bar) । जाहिर है, एक त्रुटि, लेकिन सिंटेक्स डेवलपर को दो स्थानों पर रिटर्न प्रकार को परिभाषित करके समस्या को अधिक-विवश करने में सक्षम बनाता है।

हम अभी भी उस बार को स्पष्ट रूप से लागू करने में सक्षम नहीं हैं या कारक के अनुरूप नहीं हैं।

इसमें दो प्रकार शामिल हैं, 1. कंस्ट्रक्टर फ़ंक्शन (जैसे वर्ग का स्थिर पक्ष), और 2. उदाहरण पक्ष ( new कॉल करते समय क्या निकलता है)। इन दोनों को एक प्रकार में मिलाना सही नहीं है। सिद्धांत रूप में आपके पास implements और static implements लेकिन व्यवहार में, जैसा कि आपने उल्लेख किया है, यह शायद ही कभी इस्तेमाल किया गया हो, और लागू किए गए खंड वास्तव में बहुत कुछ नहीं जोड़ते हैं। चेक का उपयोग साइट पर किसी भी तरह से किया जाता है, भले ही आपके पास implements क्लॉज हो या न हो।

मेरे लिए, असाइनमेंट के दाईं ओर y के प्रकार को घोषित करना अभी भी एक संज्ञानात्मक बोझ है।

दो अलग-अलग चीजों का मतलब है, var y = x.bar(Bar) एक नया चर y x.bar(Bar) के समान प्रकार के साथ घोषित करता है; जहाँ var y: Bar[] = x.bar(Bar) एक नए वैरिएबल y को Bar[] y साथ घोषित करता है और यह पुष्टि करता है कि x.bar(Bar) का प्रकार Bar[] ।

सनद है कि, यह एक शैली मुद्दा है। व्यक्तिगत रूप से, मेरी अनुशंसा है कि जब तक आपको नहीं करना है, स्पष्ट रूप से प्रकार के एनोटेशन का उपयोग न करें; चलो वह प्रणाली के माध्यम से बहती है। मैंने कोड बेस देखे हैं, हालांकि, जहां स्टाइल गाइड विपरीत है, जहां सब कुछ एक स्पष्ट प्रकार का एनोटेशन है।

@mhegazy चर्चा / परिप्रेक्ष्य के लिए धन्यवाद।

@ -y-hanson मुझे सही करने के लिए समय निकालने के लिए धन्यवाद। मैंने अपने उदाहरण में त्रुटि को ठीक किया।

यह भी काम करता है, और बिना किसी अतिरिक्त फ़ंक्शन कॉल के संकलन समय में त्रुटि दिखाता है:

interface Type<T> {
    new (...args: any[]): T;
}

/* static interface declaration */
interface ComparableStatic<T> extends Type<Comparable<T>> {
    compare(a: T, b: T): number;
}

/* interface declaration */
interface Comparable<T> {
    compare(a: T): number;
}

/* class decorator */
function staticImplements<T>() {
    return (constructor: T) => {}
}

@staticImplements<ComparableStatic<TableCell>>()   /* this statement implements both normal interface & static interface */
class TableCell { /* implements Comparable<TableCell> { */  /* not required. become optional */
    value: number;

    compare(a: TableCell): number {
        return this.value - a.value;
    }

    static compare(a: TableCell, b: TableCell): number {
        return a.value - b.value;
    }
}

चर्चा का परिणाम क्या है?

मैं इसमें भाग गया और मैं static interface का उपयोग करना चाहता हूं:

interface IDb {
  public static instance: () => Db,
}

अधिकांश लोग यह भूल जाते हैं कि पहले से ही _static_ इंटरफेस इस अर्थ में है कि एक कंस्ट्रक्टर फ़ंक्शन / क्लास में दो इंटरफेस पहले से ही हैं, कंस्ट्रक्टर इंटरफ़ेस और इंस्टेंस इंटरफ़ेस।

interface MyFoo {
  method(): void;
}

interface MyFooConstructor {
  new (): MyFoo;
  prototype: MyFoo;
  staticMethod(): any;
}

const MyFoo = function MyFoo() {
  this.prop = '';
} as any as MyFooConstructor;

MyFoo.prototype = {
  method() { console.log(this); }
}

MyFoo.staticMethod = function () { /* do something static */ }

यदि आप _abstract_ वर्गों का उपयोग नहीं कर रहे हैं, तो आपके पास पहले से ही शक्ति है।

जवाब देने के लिए @kitsonk का शुक्रिया।

आपका घोषणापत्र लगता है कि काम करना चाहिए, लेकिन यह मामले के लिए बहुत ही महत्वपूर्ण है।

और मैंने सिर्फ _abstract_ क्लासेस की कोशिश की, लेकिन यह static abstract साथ समर्थन नहीं करता।

[ts] 'static' modifier cannot be used with 'abstract' modifier.

@ ज़िक्सिया जो # 14600 जारी है

हाँ, इसे वोट दें।

किसी को मेरे सवाल का हल के साथ जवाब देने के लिए यहां ध्यान दें: http://stackoverflow.com/questions/44047874/dynamically-modify-typescript-classes-through-a-generic-function

मुझे लगता है कि पूरे मुद्दे को इंटरफेस पर स्थिर सदस्यों को निर्दिष्ट करने में सक्षम होने के द्वारा हल किया जाएगा, और अगर यह मुद्दा बंद हो गया है क्योंकि इसकी आवश्यकता नहीं

@grantila मैंने आपके प्रश्न का उत्तर दिया है। जैसा कि इस मुद्दे में पहले उल्लेख किया गया है, जब तक कि आपके पास आगे की आवश्यकताओं का उल्लेख नहीं किया जाता है, तब तक कक्षाओं को वस्तुओं के रूप में मानकर आसानी से हल किया जा सकता है।

@ Enet4 मैंने सवाल को अपडेट किया, यह अत्यधिक सरल था। वास्तविक मुद्दा Object.defineProperty() दुर्भाग्य से तय नहीं किया जा सकता है। जो btw, एक हैक है। मैं मूल रूप से उचित स्थैतिक जाँच - make गलत वर्तनी नहीं होने देना चाहता हूँ।

यह मेरे पास एक वास्तविक समस्या है, कोड जिसे मैंने टाइपस्क्रिप्ट में पोर्ट करना शुरू किया था, लेकिन अब इसे जावास्क्रिप्ट के रूप में रखा गया है, क्योंकि मैं वर्तमान में इतनी बड़ी मात्रा में कोड को फिर से नहीं लिख सकता हूं क्योंकि अन्यथा आवश्यक होता।

मैं मूल रूप से उचित स्थैतिक जाँच - गलत वर्तनी नहीं होने देना सुनिश्चित करना चाहता हूँ।

स्थैतिक जाँच केवल यहाँ तक जा सकती है। लेकिन अगर आपकी एकमात्र चिंता अब यह है कि आप सही संपत्ति सेट कर रहे हैं, तो एक निर्माता प्रकार के लिए कास्टिंग करना और वहां से संपत्ति सेट करना पता लगता है।

@ Enet4 यह एक

आपके जैसे समाधान, प्रकार की कास्टिंग का उपयोग करना, वास्तव में टाइप सुरक्षित नहीं है, और यदि यह क्लास प्रकार के साथ काम करने की स्थिति को एक मूल्य के रूप में हल करने का एकमात्र तरीका है, तो हम एक गतिशील भाषा के लचीलेपन का एक बहुत कुछ खो रहे हैं।

@grantila मेरे बचाव में, यह बहस का मुद्दा है। : विंक: आपका उपयोग मामला इस अंक में प्रस्तुत किए गए लोगों से अलग है, इसमें आपके वर्ग प्रकार रनटाइम स्थितियों के आधार पर एक विधि प्रदान कर सकते हैं (या नहीं)। और IMO जो मेरे उत्तर में प्रस्तुत किए गए प्रकार से अधिक असुरक्षित है, जो केवल एक ऑब्जेक्ट में फ़ील्ड के सम्मिलन की अनुमति देने के लिए प्रदर्शन किया गया था। इस संदर्भ में, जिसके परिणामस्वरूप वर्ग टाइप C & Maker<T> सब कुछ एक पर भरोसा कर के साथ संगत रहना चाहिए C ।

मैंने यह भी चित्रित करने की कोशिश की कि इंटरफेस में स्थिर तरीके यहाँ आपकी मदद कैसे कर सकते हैं, लेकिन मुझे कुछ याद आ रहा है। यहां तक ​​कि अगर आपके पास अपने इंटरफ़ेस में static make?(... args: any[]): self जैसा कुछ था, तो कॉल से पहले इसे अस्तित्व के लिए रनटाइम में जांचना होगा। यदि आप इस चर्चा को जारी रखना चाहते हैं, तो आइए शोर को कम करने के लिए कहीं और करने पर विचार करें। : Slightly_smiling_face:

इसलिए हम क्लास में स्टैटिक फ़ैक्टरी विधियों की जाँच नहीं कर सकते जो समान इंटरफ़ेस को लागू करते हैं?

मेरा उपयोग मामला है:

interface IObject {
    static make(s: string): IObject;
}

class A implements IObject{
    static make(s: string): IObject {
        // Implementation A...
    }
}

class B implements IObject{
    static make(s: string): IObject {
        // Implementation B...
    }
}

A.make("string"); // returns A
B.make("string"); // returns B

मैं इसके लिए एक नया कारखाना वर्ग नहीं लिखना चाहता।

@ tyteen4a03 उस उदाहरण से IObject निकालें, और यह संकलन करेगा। Https://github.com/Microsoft/TypeScript/issues/17545#issuecomment -319422545 भी देखें

@ -y-ms हाँ स्पष्ट रूप से यह काम करता है लेकिन प्रकार की जाँच का पूरा बिंदु है .. जाँच प्रकार। आप हमेशा उपयोग की सुरक्षा को हर मामले में संकलित करने के लिए पर्याप्त प्रकार की सुरक्षा को नीचा कर सकते हैं, लेकिन यह इस तथ्य की अनदेखी कर रहा है कि यह एक सुविधा अनुरोध है और उस पर एक पागल नहीं है।

हां जाहिर है कि यह काम करता है लेकिन टाइप चेकिंग का पूरा बिंदु .. चेक प्रकार है।

यह एक लंबा लंबा थ्रेड है कि कैसे वर्ग का स्थिर पक्ष उदाहरण पक्ष के लिए एक अलग इंटरफ़ेस है और उदाहरण के पक्ष में implements अंक है। @ @ -y -ms

मिक्स्ड क्लास के लिए क्लास जेनेरिक पैरामीटर का उपयोग करने के स्थैतिक तरीकों की अनुमति देने के लिए मेरा उपयोग मामला है। मैं एक इकाई ढांचे का निर्माण कर रहा हूं, जो कॉलम, डेटाबेस आदि को परिभाषित करने के लिए एनोटेशन का उपयोग करता है और मेरी इकाई कक्षाओं में एक स्थिर फ़ंक्शन मिलाया जाएगा जो सही प्रकार से रिपॉजिटरी में सुविधाजनक पहुंच की अनुमति देगा।

class RepositoryMixin<T> {
    public static repository(): EntityRepository<T> {
        return new EntityRepository<T>(Object.getPrototypeOf(this));
    }
}

@mixin(RepositoryMixin)
class Entity implements RepositoryMixin<Entity> {
    public id: number;
}

Entity.repository().save(new Entity());

@rmblstrp क्या आप दिखा सकते हैं कि आप अपने उदाहरण में प्रस्तावित सुविधा का उपयोग कैसे करेंगे? अधिमानतः कुछ सत्यापन के रूप में?

@rmblstrp को इस सुविधा की आवश्यकता नहीं है। वास्तव में, चूंकि आप एक डेकोरेटर का उपयोग कर रहे हैं, आप वास्तव में _its टाइप_ यह सत्यापित करने के लिए कर सकते हैं कि एनोटेट वर्ग आवश्यक स्थिर तरीके प्रदान करता है। आपको दोनों की आवश्यकता नहीं है और यह वास्तव में बेमानी होगा।

नमस्कार, मैं विषय से बाहर या इस बातचीत के दायरे से बाहर नहीं जाना चाहता।
हालाँकि, जब से आप विभिन्न प्रोग्रामिंग प्रतिमानों पर चर्चा करते हैं (क्या हमें OOP या कार्यात्मक का उपयोग करना चाहिए?), मैं विशेष रूप से स्थैतिक कारखानों के बारे में बात करना चाहता हूं, जिनका उपयोग आमतौर पर db से संबंध बनाने या किसी प्रकार की सेवा प्रदान करने के लिए किया जाता है।
PHP और जावा जैसी कई भाषाओं में, स्थैतिक कारखानों को डिपेंडेंसी इंजेक्शन के पक्ष में हटा दिया गया है। डिपेंडेंसी इंजेक्शन और IOC कंटेनरों को सिम्फनी और स्प्रिंग जैसे फ्रेमवर्क के लिए लोकप्रिय बनाया गया है।
टाइपस्क्रिप्ट में एक अद्भुत IOC कंटेनर होता है जिसका नाम InversifyJS होता है।

ये ऐसी फाइलें हैं, जहां आप देख सकते हैं कि कैसे पूरी चीज को संभाला जाता है।
https://github.com/Deviad/virtual-life/blob/master/models/generic.ts
https://github.com/Deviad/virtual-life/blob/master/service/user.ts
https://github.com/Deviad/virtual-life/blob/master/models/user.ts
https://github.com/Deviad/virtual-life/blob/master/utils/sqldb/client.ts
https://github.com/Deviad/virtual-life/blob/master/bootstrap.ts

मैं यह नहीं कह रहा हूं कि यह एक सही समाधान है (और शायद यह कुछ परिदृश्यों को उजागर करता है), लेकिन यह रिएक्ट के साथ भी काम करता है, कुछ उदाहरण पहले से ही आप देख सकते हैं।

इसके अलावा, मैं आपको इस वीडियो को कार्यात्मक प्रोग्रामिंग के बारे में देखने के लिए सुझाव देता हूं जो इस पहलू को कवर करता है जिसके बारे में एक बेहतर है: https://www.youtube.com/watch?v=e-5obm1G_FY&t=1487s
जासूस: कोई भी बेहतर नहीं है, यह उस समस्या पर निर्भर करता है जिसे आप हल करना चाहते हैं। यदि आप उपयोगकर्ताओं, कक्षाओं, शिक्षकों के साथ व्यवहार करते हैं, तो OOP ऑब्जेक्ट्स का उपयोग करके आपकी समस्या को मॉडल करना बेहतर होगा।
यदि आपको किसी ऐसे पार्सर की जरूरत है जो किसी वेबसाइट को स्कैन करता हो तो फंक्शनल जनरेटरों का उपयोग करने के लिए बेहतर हो सकता है जो आंशिक परिणाम देते हैं, आदि :)

@Deviad @aluanhaddad अपनी पोस्ट के बाद से मैं InversifyJS का उपयोग कर रहा हूं और यह बिल्कुल शानदार है और निश्चित रूप से बहुत बेहतर तरीका है। अपनी पोस्ट के समय मैंने PHP / C # पहले होने के बाद सिर्फ टाइपस्क्रिप्ट / नोड का उपयोग करना शुरू किया था। पर्यावरण और उपलब्ध पैकेज से परिचित होने में अभी थोड़ा समय लगा है।

इसकी स्थिति क्या है? आप रेपो में अनसुलझे मुद्दों को बंद क्यों रखते हैं?

मेरा मानना ​​है कि यह उन मामलों में से एक है जहां इस मुद्दे को "वॉन्टफिक्स" के साथ स्पष्ट रूप से लेबल किया जाना चाहिए, क्योंकि इंटरफेस में स्थिर तरीकों के न होने का विकल्प डिजाइन द्वारा है।

@ enet4 , मैं एक नवागंतुक हूं, लेकिन यह बिल्कुल स्पष्ट नहीं था। इसे और अन्य संबंधित मुद्दों को पढ़ते हुए, ऐसा लगता है कि यह ज्यादातर निम्नलिखित मुद्दे हैं:

A. यह कठिन है
B. हमें (प्रत्येक) विशिष्ट सिंटैक्स पसंद नहीं है जो हमने अब तक देखा है।
C. एक छोटा अल्पसंख्यक यह नहीं मानता है कि यह बिल्कुल भी उचित होना चाहिए, और इसे करने के लिए वर्तमान अजीब तरीके को हटा देगा।

यदि यह वास्तव में डिज़ाइन द्वारा है, और जो प्रभारी नहीं चाहते हैं, तो उन्हें एक सार्वजनिक दस्तावेज़ लिखना चाहिए, और इसे और अन्य थ्रेड्स में लिंक को पार करना चाहिए। यह हमें सीमित रखने में बहुत समय बचाएगा।

हम पहले ही इस धागे में # 14600 लिंक कर चुके हैं और यह सुविधा अनुरोध का पालन करने का मुद्दा है।