n.関数


オブジェクト向けのプログラム設計の世界は、それぞれの役割と責任を持つオブジェクトが協力し、要求し、応答する世界です.
さらに、オブジェクトにはステータス(フィールド)があり、動作(関数)によって要求に応答し、コラボレーションします.
したがって,行動(関数)は対象世界における協力に向けた重要なキーワードである.
では、重要なキーワード行動(関数)をきれいなコードにするにはどうすればいいのでしょうか.
cleanコードで与えられたクリーン関数のルールを見てみましょう.

クリーン関数のルール
1.小さくなる!
関数を作成する最初のルールは「小さく!はい.
関数が小さいほど良いという証拠はないが,著者らの経験によれば,小さな関数が良い.
私も完全に同意して、小さい機能の関数に細分化すればするほど、読むほど良くて、機能を修正するのも便利です.
[原句]一つだけやる!
2つ目のルールは「1つだけ!」はい.
関数が「一つのこと」しかできないかどうかを判断する方法は、関数から他の関数を抽出できるかどうかを見ることです.
意味のある名前で別の関数を抽出できれば、多くの仕事をしたことになります.
例えば、次のコード
	public static Car makeCar(String carName, int position){
    	boolean hasCarName = NameValidator.hasName(carName);
        
        if (hasCarName) {
        	return new Car(carName, position);
        }
        return null;
    }
以上のコードは,Carオブジェクトの静的ファクトリメソッドを作成するコードである.
△これは単独でチェックしたことのないコードで、構文エラーがある可能性があります.
簡単な段落で関数を見る機能は以下の通りです.
TOmakeCarは、自動車名が確認された後、自動車名がある場合は、自動車オブジェクトを作成して戻ります.
一見上の段落を見ると、Carオブジェクトを作るという良いことをしたようです.
ただし、関数をよく観察すると、makeCar関数は車名をチェックし、Carオブジェクトを返します.
makeCar関数は検証と返却の2つをしています!
もしそうなら、以下のように修正してみてください.
	public static Car makeCar(String carName, int position){
        if (hasCarName(carName)) {
        	return new Car(carName, position);
        }
        return null;
    }
上記の例に示すように、関数の内部から他の関数を抽出できるかどうかを確認すると、関数が「1つ」しか得意ではないかどうかを知ることができます.
3.各関数の抽象度は1です!
関数内部で呼び出される関数の抽象レベルは、それぞれ異なることはできません.
抽象レベルの異なる関数が1つの関数に混在している場合、コードを読む人は混同されます.
特定の表現が根本的な概念なのか細部なのかを区別するのは難しいからだ.
では、抽象レベルを一致させる方法は何でしょうか.
上から下へのコードを実現することです.1つの関数の後に抽象化の程度が低い関数があります.つまり、上から下へ読むと、関数抽象レベルが1つ低下します.
コードでは、これを降格ルールと呼びます.
4.記述名を使用!
前回のリリースで説明したように、名前はクリーンなコードにとって非常に重要です.
これは関数にも適用されます.(ルールリンクを記事の下部に添付して良い名前を取得します)
関数のしたことをよりよく表現するためには、記述的な名前を使うべきです!
関数の機能をうまく表現できれば良いのですが、不可能な場合が多いです.
したがって,長い場合でも,関数に関数機能をうまく記述できる名前を付けなければならない.
名前をつけるのに時間がかかっても大丈夫!
良い名前は後でプログラムのメンテナンス時間を大幅に短縮します!
5.関数パラメータ
関数の理想的な因数はゼロです.次は1つ、次は2つです.
3つは避けたほうがいいですが、4つ以上は特別な理由が必要です.
なぜ関数の因数が少ないのが良いのでしょうか
パラメータが少なければ少ないほど、関数を理解しやすくなります.
たとえば、車の名前を入力するには、inputCarName関数を呼び出す必要があります.
Scannerを使用して入力を受信すると、
InputCarName(スキャナー)よりも、InputCarName()を呼び出してScannerを内部で使用する方が読者にとって分かりやすいです.
InputCarName(スキャナー)には、コードを読み取る人が名前入力関数を呼び出すときにあまり重要ではない詳細Scannerを知る必要があるという問題もあります.
テストの観点から,因数が高いのは問題がある.
様々なパラメータの組合せで関数を検証するテストケースを記述する場合、パラメータが多ければ多いほど、テストが必要な組合せが多くなるからです.
従って、入力因数がない場合が好ましく、次いで入力因数が1つしかない場合がある.
関数を実装するときに、パラメータを減らしてみましょう!
一般的な単一フォーマット
いくつかの一般的な状況は、1つの因数を関数に渡すことです.
一つは買収に問題を提起することである.boolean fileExists(「MyFile」)は良い例です.
もう1つのケースは、結果を返すためにパラメータを変換することです.例えば、int parseStringToInt(「2022」)である.
また,単項関数の形式がイベントである場合がある.
上記でない場合は、できるだけ単抗関数の使用を避けましょう.
フラグパラメータ
ブール係数を関数に渡すのは恐ろしい!
なぜなら、関数は一度に多くのことを処理するので(boolean因数は本当にこれをして、偽物ならそれをします)、これははっきり言っています!
にこうかんすう
因数2の関数は因数1の関数よりも理解しにくい.例:
writeField(name)はwriteField(outputStream,name)よりも理解しやすい.どちらの意味もはっきりしていますが、前者は読みやすく、理解が早いです.逆に、後者は初買収を無視すべきだと意識するのに時間がかかる.また、無視した買収も間違いの原因になります!
プログラミングの過程で、この関数が避けられないことがありますが、できるだけ避けましょう.
さんこうかんすう
3つの因数の関数は2つの因数の関数よりも理解しにくい.これは,順序の理解と無視に多くの時間が必要であることを認識し,誤りを無視するリスクも高いためである.
だから3つの関数を作るには慎重に考えなければなりません!
動詞とキーワード
関数の意図やパラメータの順序や意図を表示するには、良い関数名が必要です!
また、単項関数の関数/引数は、動詞/名詞のペアにする必要があります.
関数に名前をつけるときは、関数、引数の意図を明らかにします!
6.付随効果を生み出さない!
前述したように、関数は「一つのことしかしない」はずです.
付随効果は、一つのことだけをして、こっそり別のことをすることを承諾することです.
だから関数をしっかり表現して、付随効果をもたらさないでください!
7.コマンドとクエリーの分離!
関数は、アクションを実行するか、アクションに答えるか、いずれかのアクションのみを実行する必要があります.しかし、どちらも同時にすることはできません.
関数は、オブジェクトのステータスを変更したり、オブジェクト情報を返したりすることができます.
二つのことを一つの関数でやると混乱します!
コマンド/クエリーを分離する関数を構築しましょう.
8.エラーコードではなく例外を使用します.
コマンド関数がエラーコードを返す方法は、コマンド/クエリー分離規則に微妙に違反しています.これはif文でコマンドを式として簡単に使用できるためです.
さらに、エラー・コードを返すことは、クラスでも列挙変数でもエラー・コードをどこでも定義することを意味します.
これにより,エラーコードを用いたクラスはエラーコードに依存する.エラーコードを変更した場合は、エラーコードを使用するすべてのクラスを再コンパイルする必要があります.したがって、エラーコード(クラスまたは列挙型)を変更するのは難しい.
エラーコードではなく例外を使用するべきです!
例外を使用すると、コマンド/クエリー分離ルールを遵守し、エラーコードを元のコードから分離できます.
また、例外が有効になっている場合、新しい例外を追加してもExceptionクラスから例外が派生します.したがって、新しい例外クラスを再コンパイルまたは再配置する必要はありません.
エラーコードではなく、例外を使用して関数を実装します.
9.繰り返さない!
コードの重複はソフトウェアの万悪の根源です!
コードの重複する部分を見つけて、それを関数にして、重複を解消する必要があります.
に感銘を与える
オブジェクト向けの世界では、関数はオブジェクト間のコラボレーションを実現する重要なツールです.
これらの関数をきれいにすることが大切です!
これからは符号化を行うとともに、きれいな関数のルールを守り、符号化に努めます!😤😤
clean code-有意義なネーミング記事リンク
https://velog.io/@gudonghee2000/%ED%81%B4%EB%A6%B0%EC%BD%94%EB%93%9C-%EC%9D%98%EB%AF%B8-%EC%9E%88%EB%8A%94-%EC%9D%B4%EB%A6%84