Clean Code第10章クラス

コードの表現力とそれが構成する関数をどのように気にしても、もっと注意しないで、もっと高いレベルに注意しないと、きれいなコードを得るのは難しいです.

クラス・スキーマ📝

Java標準クラス定義の変数順
1.静的公開定数
2.静的非公開変数
3.専用インスタンス変数
4.公開変数(必要に応じてほぼx)
5.公開関数
6.非公開関数(自分の公開関数を呼び出した後)
抽象化段階は順次手配される

カプセル化🔗

変数とユーティリティ関数はできるだけ公開しないほうがいいが、隠さなければならない法則もない.必要に応じてカプセル化を解除することもあります.しかし、その前に、非公開状態を維持する方法を考えなければならない.

カプセル化の決定はいつも最後の手段だ

等級が小さい。

クラスを作成するとき、最初のルールはサイズです。レベルが小さい！

等級の大きさを測定する基準は、等級が負う責任の数です.クラスで定義されたメソッドの数が小さいということは、クラスのサイズが小さいという意味ではありません.
クラスのサイズを減らす方法(責任を減らす方法)

クラス名はクラスの責任を記述する必要があります

簡潔な名前がなければ、クラスは大きすぎます.

クラス名に曖昧な単語マネージャ、Superなどが含まれている場合、クラスは多くの責任を負います.

授業の説明は、もし、そして、-、しかし、使わないで、35語ぐらいしかありません.

ex)SuperDashboardは、最後にフォーカスを取得した構成部品にアクセスする方法を提供し、バージョンとバージョン番号を追跡するメカニズムを提供します.

単一責任の原則🔗

単一責任原則(SRP)

クラスまたはモジュールを変更する理由は1つだけです.

等級は1つの責任を負うだけです.

責任、すなわち変更の原因を特定しようとすると、コードの抽象化が容易になります.
いくつかの大きなクラスではなく、いくつかの小さなクラスからなるシステムが望ましい.

ぎょうしゅうど🔗

クラスには、インスタンス変数の数が小さい必要があります.通常、メソッドで使用される変数が多ければ多いほど、メソッドとクラスの凝集力が高くなります.
関数が小さくなり、パラメータリストが短くなるポリシーに従うと、いくつかのメソッドのみを使用するインスタンス変数が多くなる場合があります.これは新しいレベルに分ける信号です.凝集度を高めるために,変数と方法を適切に分離し,2,3つの新しいクラスに分けた.

凝集度を保つと、多くの小さなクラスが現れます🔗

大きな関数を小さな関数に分割する場合、必要な変数をクラスインスタンスに変換すると、関数の分割が容易になります.しかし,1つの関数ではいくつかの変数しか使用されないため,クラスの凝集度は低下する.
凝集度が下がると、1つのレベルではなく、いくつかのレベルに分けられます.したがって,大きな関数を複数の小さな関数に分解すると,小さな関数を複数の小さなクラスに分解する機会が生じることが多い.

変更しやすいクラス💡

クリーンなシステムは、システム的に等級を整理し、変更に伴うリスクを低減します.新しい機能を変更したり、既存の機能を変更したりする場合は、タッチコードを最小限に抑えるシステム構造を使用することをお勧めします.
オープン-クローズの原則(OCP)

拡張は、開放性と閉鎖性の原則

の修正に従うべきである.

は、既存のコードを変更せずに機能を追加するように設計されるべきである.

変更から分離🔗

詳細な実装に依存するクライアントクラスは、変更を実装する際に大きな影響を受けます.したがって,インタフェースと抽象クラスを用いて実装の影響を分離する.
より低いシステム結合度

は、各システム要素が他の要素からよく分離されていることを意味します.

システム要素が互いによく分離されている場合、各要素の理解は

より容易になる.

柔軟性と再利用性が向上

依存-逆転の原則(DIP)

クラスは、詳細な実施の原則

ではなく抽象に依存しなければならない.

インタフェースまたは抽象クラス

に依存する.
ex)自動車を実施する際、どんなタイプのタイヤを持たせますか?

class TestCar {
	private SandTire tire;
	
	public void testSetTire(SandTire tire) {
		this.tire = tire;
	}
	
	public String getTireType() {
		return tire.getType();
	}
}

class SandTire {
	public String getType() {
		return "SandTire";
	}
}

テストカーのタイヤは特定のSandTireに依存しているため、タイヤタイプを交換しようとするたびにコードが変化していく.この場合、OCPの原則だけでなくDIPの原則にも違反します.レイヤインタフェースを使用して変更できます.

class Car {
	private Tire tire;  
	public void setTire(Tire tire) {
		this.tire = tire;
	}
	
	public String getTireType() {
		//System.out.println(this.tire.getType());
		return this.tire.getType();
	}
}

interface Tire {
	public String getType();
}

class SandTire implements Tire {

	@Override
	public String getType() {
		// TODO Auto-generated method stub
		return "SandTire";
	}
	
}

class SnowTire implements Tire {

	@Override
	public String getType() {
		// TODO Auto-generated method stub
		return "SnowTire";
	}
	
}

class NormalTire implements Tire {

	@Override
	public String getType() {
		// TODO Auto-generated method stub
		return "NormalTire";
	}
	
}

このようにレイヤインタフェースを使用して実装する場合は、Carクラスでタイヤタイプを変更し、使用したいクライアントクラスで変更するだけでよい.そのため、簡単に修正できます.また、異なるタイプのタイヤを使用したい場合は、層インタフェースが実現されるため、特定のタイヤクラスを簡単に追加することができる.したがって,OCPの原則とDIPの原則を満たすことができる.

に感銘を与える🙊

クラスはプログラム設計の重要な部分である.駄作を書くときは自らクラスを設計した経験があるが、一つの責任だけをクラスに入れるのは容易ではない.しかし、作ったプロジェクト自体は特に大きくないので、作ったクラス自体もそれほど大きくありません.
実は最大の問題はOCPの原則です.変更時に既存のコードを変更できないという原則は、コードを変更する際に違反するルールです.これは、コードを初めて作成するときに変更を考慮しないことを示しています.
これでは,変更を行う際にコード全体を覆すことが起こる.ハハハハ.逆に最初からやるほうがやりやすいと思う.ハハハハ.最初の設計ミスは、こんな大きなショックがあっても分かる時間でした.そのため、最近では長い時間がかかっても符号化の前に構造が作られている.作成する機能が何であるかを確認し、実装に必要な機能を書きます.そして,首都コードを記述し,論理を創造し,詳細に実施する.
長い時間がかかるが,コード構造全体をすばやく記述でき,理解しやすく,私の考えに合わない部分を正確に知ることができるという利点がある.だからその部分を修正して、それを熟知するために努力するしかありません.
前学期はデザインを学んだので、この本を読んでいるうちにSRP、OCP、DIPが出てくるものがまた重要だと気づきました.コードを書くときにそれを適用するように努力し続けるべきだと思います.