リファクタリング:ビューの懸念と機能?

このポストはシリーズ「リファクタリング」の更なる議論です.
前のポストでは、これらのポイントを強調しました.
建築目標

これまで重複したコード!

時間、1つの場所、1つの懸念

~機能につきコードの10から20行まで242479182

の入出力は周知で、防弾

です

async最初

オプションの突然変異

今日、我々は1回、場所と懸念について話します.特に懸念部分.
再利用可能な関数とビュー
再利用可能な関数はビューと関連しているか?
それは、懸念の違反でありません;TypesScriptやJavaScriptでは、関数のビューの問題があります.角度、反応またはVueクラスがビューに通常対処する間本当の機能的なファーストクラスの市民は、クラスと同じレベルです.これは、我々は簡単にビューと共存する機能の仕事をステップアップできることを意味します.

_{Java and C# claim methods are first class citizens. This is a lie, because functions there must live under class definitions. C# does have extension methods but this is not the same thing discussed here.}

実際、私たちが全くクラスを必要としないという議論がありました.しかしながら、我々は反応、Vueまたは角度を設計しませんでした、したがって、我々はクラスベースの遺産に強制されます.反応、Vueと角度正しくそれを行っている.
前の記事では、私たちは通常「悪い結合」を発見する方法を学びました.そして、単に「これ」を見て、悪いですコード.その記事では、私たちは、そのコードを新しいモジュールに入れて、すべての「これを交換することによって、リファクタリングする方法を示しました.」パラメータ付きコード.
今日、私たちはここに示すようにさらに一歩を踏み出します.

export function funcSetPerson(vc: ViewComponent) {
   /** True if existing person, false if newPerson */
   return new Promise<boolean>((resolve, reject) => {
      let personID = funcGetRouteId(vc.ar);
      if (personID > 0) {
         ec.httpService.getPersonByID(personID).subscribe(
            (person) => {
               funcHandlePersonResponse(vc, person);
            },
            (error) => {
               vc.es.OpenError(ErrorModel.Error(error));
               reject(error);
            }
         );
         resolve(true);
      } else {
         resolve(false);
      }
   });
}

代わりに、"これ"の代わりにコードは、単にViewComponent自体で渡されます.
この関数は単純に:入力されたルートパラメータに基づいてpersonidが0の場合、HTTP GETリクエストを送信します.それ以外の場合はfalseを返します.
警告
全体のViewComponentで渡すことによって、我々は一般によく考えられない何かを再実装しています;「近いカップリング」.それが本当である間、時々、我々の車の我々の後輪へのドライブ電車のように、「近いカップリング」はよいです.
概要
我々の建築ゴールに続いて:
ViewComponentコードは、このようにして非常にきれいです.そして、我々は防弾して、1つのものに集中する再利用できるパーツを作成しています.これは、我々が部品を交換することができて、何か他に影響を及ぼすことなく彼らを動かすことができる「構成可能な」ソフトウェアをつくっていることを意味します.
“close coupling”(ビュー内のすべてのコード)を使用するときは、このコードから利益を得ることができます.これは、関数が再利用可能なコードに最適な理由です.
リファクタリングII