抽象化と「抽出メソッド」リファクタリングメソッドについて

プログラミングでは抽象化が非常に重要であり、誰もがそれを知っています。 それらは、私たちが何かの本質的な詳細を非本質的なものから分離するのを助けます。 理想的には、不純物を含まない最も重要なもの、エッセンス、オブジェクトまたはプロセスの最小特性のみを放出する必要がありますが、理想はそれほど一般的ではありません。



プログラマーがコードを書くとき、彼は抽象化で動作します。



「クライアントはサーバーにリクエストを送信します。」



前の文の各単語は、高レベルの抽象化です。 これらの4つの抽象化が同じレベルにあることが重要です。 対応するコードは次のようになります。

client.send(request, server);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

読者には、この行を見ることに疑問はありません。



多くの場合、1行のコードでは不十分であり、プログラマーはさらに行を追加します。 たとえば、入力パラメーターの検証と関数によって返される値の処理には、多くの時間とスペースがかかります。

 void sendRequest(Request request) { if (server->error() != Server::errorOk) { // handle } if (request.userName.empty()) { // handle } //  100 if- client.send(request, server); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はそのようなifを非常に頻繁に見るので、それらをノイズとして知覚します（特にヨーダ条件）。 それらは間違いなく必要ですが、... client.sendはどのServer :: ErrorStateよりも高い抽象化レベルにあるので、このsendRequest関数内にあるべきではないと考えています。 これらのifは低レベルの抽象化であるため、isServerReady（）とisRequestValid（）の別々のメソッドで非表示にする必要があります。 コードは次のようになります。

 void sendRequest(Request request) { if (!isServerReady()) { // handle } if (!isRequestValid(request)) { // handle } //   if' client.send(request, server); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SendRequestは、同じ抽象レベルの関数で動作するようになったため、コードは簡単で読みやすくなりました。 ボーナス-ifsをコピーする代わりに、これらのメソッドを（必要に応じて）再利用できます。 これらのいサーバー->エラー（）！= Server :: errorOkをsendRequest関数で見たくありませんが、必要なときに見たいです。 次に、isServerReady（）の内容を確認します。 感じますか？



または例えば。 大きい、大きいクラス。 すべての方法で、フォームの条件は散在しています

 if (niceNamedContainer.empty()) { // do some logic }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

if (niceNamedContainer.empty())



について初めてコードを見たとき、「niceNamedContainerに何もない場合」としか言えません。 すぐに質問がありますが、これはどういう意味ですか？ 私は自分自身に答えます。彼らはそれをどこかに、他のどこにでも入れませんでしたが、ここには入れませんでした。 どのように動作するかを理解するためにクラスコードの少なくとも100％をシャベルで処理した後、この状態は実際には「データの準備ができている」ことを意味することを理解しています。 やったー しかし、クラスを記述する段階でisDataReady（）メソッドを分離することはまったく難しいことではないと思います。 コードリーダーはまず高度な抽象化を必要とするため、読者にとってははるかに簡単であり、テレパシー能力を使用する必要はありません。 isDataReady（）メソッドは、低レベルの抽象化と高レベルの抽象化を接続するラダーです。 必要に応じて降りることが非常に便利であり、必要でない場合は、降りることはできません。 これにより、他の誰かの古い継承コードをサポートする時間を大幅に節約できると思います。 しかし、メソッドの選択を適用し、1つの機能が1レベルの抽象化でのみ動作することを確認することはビジネスです...まあ、SRPを忘れないでください...まあ、リスコフ...まあ、カプセル化...マッコネルも...もっとよく覚えてください。



これらの例は、原始的ではありますが、現実と思われるほど遠くはありません。 条件付き構成は、いわばコードのロジックを定式化するため、また織りが織り交ぜられているかどうかを判断するのが非常に難しい場合があるため、私はifに注目しました。 ただし、これはExtract Methodを使用する唯一の場所からはほど遠いです。



参照：

en.wikipedia.org/wiki/データ抽象化



参照：

スティーブマッコネル。 完全なコード：ソフトウェア構築の実践的なハンドブック。

ロバートC.マーティン。 クリーンコード：アジャイルソフトウェアのクラフツマンシップのハンドブック。

マーティン・ファウラー リファクタリング：既存のコードの設計の改善