Sınıf yapıcısına veri (davranış vs) enjekte etmek ne anlama gelir ve bu neden kötü uygulama olarak kabul edilir?

Remo Jansen'in "Learning TypeScript" kitabını okuyorum. Bir bölümde yazar, Modelsınıfın nasıl oluşturulacağı da dahil olmak üzere çok basit bir kavram kanıtı MVC çerçevesinin nasıl oluşturulacağını açıklar ve şunları söyler:

Bir modelin, kullandığı web hizmetinin URL'siyle birlikte sağlanması gerekir. Tüketilecek hizmetin URL'sini ayarlamak için ModelSettings adlı bir sınıf dekoratörü kullanacağız. Hizmet URL'sini yapıcısı aracılığıyla enjekte edebiliriz, ancak bir sınıf yapıcısı aracılığıyla veri (bir davranışın aksine) enjekte etmek kötü bir uygulama olarak kabul edilir .

O son cümleyi anlamadım. Özellikle, "veri enjekte etmenin" ne anlama geldiğini anlamıyorum. Bana öyle geliyor ki, aşırı basitleştirilmiş örnekler kullanan JavaScript sınıflarına neredeyse tüm girişlerde, veriler, yapıcıya parametreleri aracılığıyla ("enjekte edildi"?) Örneğin:

class Person {
  constructor(name) {
    this.name = name;
  }
}

Kesinlikle nameveri olarak düşünürüm, davranış olarak değil ve evrensel olarak bu tür bir örneğe bir yapıcı parametresi olarak dahil edilir ve bunun kötü uygulama olduğuna dair hiçbir söz yoktur. Bu nedenle, ya "veri" ya da "enjekte" ya da başka bir şeyle kastedilen, yukarıdaki alıntıdaki bir şeyi yanlış anladığımı varsayıyorum.

Yanıtlarınız, JavaScript / TypeScript'te dekoratörlerin ne zaman, nerede, nasıl ve neden kullanılacağına ilişkin açıklamaları içerebilir, çünkü bu kavramın aradığım anlayışla yakından bağlantılı olduğundan şüpheleniyorum. Ancak, daha da önemlisi, bir sınıf yapıcısı aracılığıyla veri enjekte etmenin ne anlama geldiğini ve bunun neden kötü olduğunu daha iyi anlamak istiyorum.

Yukarıdaki alıntıya daha fazla bağlam vermek için durum budur: ModelBu örnekte, biri NASDAQ diğeri NYSE için borsa modelleri oluşturmak için kullanılacak bir sınıf yaratılır. Her model, ham verileri sağlayacak web hizmetinin veya statik veri dosyasının yolunu gerektirir. Kitap, bir yapıcı parametresi yerine bu bilgi için bir dekoratörün kullanılması gerektiğini belirtir ve aşağıdakilere yol açar:

@ModelSettings("./data/nasdaq.json")
class NasdaqModel extends Model implements IModel {
  constructor(metiator : IMediator) {
    super(metiator);
  }
...
}

Sadece neden hizmet url'sini sadece kurucu için bir parametre olarak değil dekoratör aracılığıyla eklemem gerektiğini anlamıyordum, örn.

constructor(metiator : IMediator, serviceUrl : string) {...

Yazara şüpheden faydalanacağım ve belki de işler böyle yazmalı, ancak diğer ortamlarda ciddiye alınmaması gereken tamamen asılsız bir iddia.

Başımın üstünden, yapıcı aracılığıyla veri aktarmanın iyi, bazıları nötr olan, ancak kötü olduğu hiçbir durum düşünemiyorum.

Belirli bir sınıf, geçerli bir durumda olmak ve düzgün bir şekilde çalışmak için belirli bir veri parçasına bağlıysa, bu verileri yapıcıda talep etmek mantıklıdır. Seri bağlantı noktasını temsil eden bir sınıf bağlantı noktası adını alabilir, bir dosya nesnesi dosya adını, çözünürlüğünü gerektiren bir çizim tuvalini vb. Gerektirebilir. Verileri yapıcıya aktarmazsanız, nesnenin geçersiz bir durumda olması mümkündür. izlenmeli ve kontrol edilmelidir. Aksi takdirde, yalnızca nesne somutlaştırmasında kontrol edebilir ve daha sonra çoğunlukla çalıştığını varsayabilirsiniz. Yazarlar iddia bu yararlı durumu imkansız hale getirir.

Ek olarak, bir kurucuya veri aktarımını yasaklamaya karar vermek, neredeyse tüm değişmez nesneleri imkansız hale getirir. Değişmez nesnelerin birçok durumda çeşitli yararları vardır ve bunların hepsi yazarın politikası ile atılacaktır.

Değişken nesneler istediğiniz gibi olsa bile, bu kötü uygulama nasıl olur:

var blah = new Rectangle(x,y,width,height);

lehine:

var blah = new Rectangle();
blah.X = x;
blah.Y = y;
blah.Width = width;
blah.Height = height;

Yazar gerçekten ilkinin kötü uygulama olduğunu düşünüyor mu ve ben her zaman 2. seçenekle devam etmeliyim? Bence bu çılgınca konuşma.

Yani, kitabım olmadığı için ve okumasam bile yine de okumadığım için, bu ifadeyi ve hemen hemen tüm genel ifadeleri önemli bir şüphe ile görecektim.

Burada ne tür bir modelin tartışıldığı bağlama bağlı olduğunu düşünüyorum. Remo'nun kitabım yok, ancak modelin uzak bir web servisinden veri alması gereken bir tür hizmet modeli olduğunu tahmin ediyorum. Bu durumda, bir web hizmeti modeli olarak, hizmeti vatansız hale getirerek web hizmetinin yöntemlerinde bağımsız değişken olarak gerekli olan tüm verileri iletmek daha iyidir.

Durum bilgisi olmayan hizmetin çeşitli avantajları vardır, örneğin, bir hizmet yöntemi çağrısını okuyan herkes, hizmetin adı verilen hizmetin ayrıntılarını bulmak için yapılandırıldığında arama yapmasına gerek yoktur. Tüm ayrıntılar, yöntem çağrısında kullanılan bağımsız değişkenlerde gösterilir (uzak url hariç).

Sadece tahmin ediyorum.

Ben 'veri değil davranış enjekte' kulak, ben bunu yapmak yerine, düşünürdüm:

(Sözde koddaki örnek için üzgünüm):

class NoiseMaker{
  String noise;
  NoiseMaker(String noise){
     this.noise = noise;
  }
  void soNoise(){
    writeToOutput(noise)
  }
}

Bunu yapmak için:

interface Noise{
  String getAudibleNoise();
}

class PanicYell implements Noise{
   String getAudibleNoise(){
       return generateRandomYell();
   }
   .....
}



class WhiteNoise implements Noise{
   String getAudibleNoise(){
       return generateNoiseAtAllFrequences();
   }
   .....
}

class NoiseMaker{
  Noise noise;
  NoiseMaker(Noise noise){
     this.noise = noise;
  }
  void soNoise(){
    writeToOutput(noise.getAudibleNoise())
  }
}

Bu şekilde gürültünün davranışını her zaman değiştirebilir, rastgele hale getirebilir, bir iç değişkene bağlı olarak ...

Bence her şey 'miras üzerinde iyilik kompoziti' kuralıyla ilgili. Bu harika bir kural, söylemeliyim.

Bu, 'Kişi' Nesnesine adı 'enjekte edemeyeceğiniz' DEMEKTİR, çünkü bu isim tamamen iş verisidir. Ancak, web hizmetinde verdiğiniz örnekte, URL bir şekilde bir hizmeti bağlayan bir şey oluşturmak için ihtiyacınız olan bir şeydir . Bu bir şekilde bir davranıştır: URL'yi enjekte ederseniz, bir 'davranış' oluşturmak için gerekli 'verileri' enjekte edersiniz, bu durumda davranışı dışarıda yapmak ve kullanılmaya hazır enjekte etmek daha iyidir: Bunun yerine bir URL enjekte etmek kullanılabilir bir bağlantı veya kullanılabilir bir bağlantı oluşturucu.