ファクトリに向けたリファクタリング
注意バージョン: 1.0
著者: BlankFox ( CSDN ホームページ)
アーカイブ: リファクタリングとパターン
前に書かれている:
ps:リファクタリングとは、既存のコードを再構築することで、理解しやすく、拡張し、変更しやすくすることです。リファクタリングのプロセスでは、コードを感覚で変更することはできず、多くの問題が発生します。リファクタリング後にコードが実行できなくなり、コードが壊れてしまいます。リファクタリングが必要なコードの複雑な新しい部分。したがって、コードのリファクタリングには、問題を発見するための方法のガイダンスと、いくつかの一般的な手順、段階的なテスト、および段階的なテストが必要です。
ps:既存のコードには、オブジェクト作成コンテンツがたくさんあるはずです。優れたコードは、コンストラクターの詳細を読者に理解させるのではなく、コードの読者に、コードが出現した場合に、どのようなオブジェクトが作成されるのかを明確に伝えます。同じ名前のコンストラクター- リファクタリングを使用してメソッドのカプセル化を作成します。複数のコンストラクターが表示され、元のクラスの責任が不明瞭な場合は、リファクタリングを使用して作成メソッド ラッパーを単純なファクトリに抽出します。同様の関数が表示されますが、作成オブジェクト メソッドが異なります。 - リファクタリングを使用してファクトリメソッドに移行する
ファクトリに向けたリファクタリング
1. コードの問題
どこを最適化できるかを知るために、まず問題を特定します
エラー例 1 - 同じ名前のコンストラクターが多すぎます\color{red}{エラー例 1 - 同じ名前のコンストラクターが多すぎます}エラー例. 1 -同じ名前のコンストラクターが多すぎます
//错误示例.1——太多的同名构造函数
/* 创建一个描述账单的类,该类有多个字段,多个构建函数对应不同的账单 */
class Bill{
/* 全构造函数(包含所有参数) */
public Bill(int id,String name,Type type,int money,Date date,String owner,...){
...}
/* 构造一个普通账单,id以及date等都自动分配 */
public Bill(String name,Type type,int money){
...}
/* 构造一个特殊支出账单,表示该支出是持久的 */
public Bill(String name,int money,Type specialType){
}//这里故意将位置调整一下,模拟错误
...
//more public Bill(){}
}
class Client{
public void useBill(){
/* 该怎么构建Bill呢? 这要求使用者熟悉Bill构建详细内容 */
Bill bill=new Bill(???);
}
}
この問題は、簡素化されたリファクタリングを使用すると、コードを理解するのが難しいと分類できます。中心的なアイデアは、コードを理解しやすく、構造をより合理的にすることであり、その方法の 1 つは、作成メソッドを使用してコンストラクターを同じものでカプセル化することです。 name - 詳細な例 1 - — create メソッドを使用したカプセル化
エラー例 2 - 責任が多すぎて分散している \color{red}{エラー例 2 - 責任が多すぎて分散している}間違いの例. 2 -責任が多すぎて分散している
//错误示例.2——创建职责过多且分散
/* 稍微改进上一个错误示例,简单封装实现了自我工厂(自己负责自己创建) */
class Bill{
/* 全构造函数(包含所有参数) */
private Bill(int id,String name,Type type,int money,Date date,String owner,...){
...}
/* 构造一个普通账单,id以及date等都自动分配 */
public static Bill defaultBill(String name,Type type,int money){
...}
/* 构造一个特殊支出账单,表示该支出是持久的 */
public static Bill staticOutBill(String name,Type specialType,int money){
}//这里故意将位置调整一下,模拟错误
...
//more public static Bill XXXBill(){}——这里你可以创建一些Bill的子类实现更多的功能
}
/* 尽管现在我们将创建函数名称和创建出的Bill描述结合起来了,但是过多的创建函数占用了Bill太多内容,而且static函数?不是很有必要呆在Bill中,这不应该是它的责任 */
作成の責任が多すぎます - クラスが異なる額面の印刷を単独で担当する紙幣と同じくらい奇妙なものになります。単純なファクトリを使用して関数の作成を担当することを考えるのは簡単です - example.2 を参照 - ファクトリを使用して作成の責任を集中化する
ErrorExample. 3 – 同じロジックの重複\color{red}{ErrorExample.3 – 同じロジックの重複}エラー例3 -同じロジックの繰り返し_ _
//错误示例.3——相同逻辑的重复
class RootNodeTest{
public void showRootTest(){
/* 处理代码中创建部分不同之外,其余部分大致相同 */
Node node=new Root();
node.addChild("next1");
node.addChild("next2");
//do other sameWork
node.show();//使用root的show测试结果
}
}
class NomalNodeTest{
public void showNodeTest(){
Node node=new NomalNode();
node.addChild("next1");
node.addChild("next12");
//do other sameWork
node.show();//使用nomalNode的show测试
}
}
繰り返し作業が多すぎると、コードの再利用性が低くなり、各部分を理解するコストが増加します。ファクトリ メソッド メソッドを使用して、相違点を保持しながら共通点を探し、共通部分を親クラスに抽出し、サブクラスに特定の作成メソッドを実装させることができます。
2、対応する再構成方法
例 1 - create メソッドを使用して同じ名前のコンストラクターを「名前変更」する\color{green}{例 1 - create メソッドを使用して同じ名前のコンストラクターを「名前変更」する}例1 - createメソッドを使用して、同じ名前のコンストラクターの「名前を変更」
//示例.1——使用创建方法“重命名”同名构造方法
/* 对于一个简单的类,多个同名的构造方法使得其使用不便,使用创建方法为构造函数加以描述 */
class Bill{
private final int id;
...
public static Bill creatBillByMoney(int i){
/* 使用创建方法包装了很多默认构造选项,使得使用更方便,而且名字更具体 */
return new Bill(getId(),"默认",TYPE.DEFAULT,getDate(),i);
}
public Bill(int id,String name,Type type,Date date,int money){
...}
...
}
class Client{
public void use(){
//Bill b=new Bill(getId(),"默认",TYPE.DEFAULT,getDate(),i);
Bill b=creatBillByMoney(100);
}
}
例 2 - 単純な工場制服オブジェクトを使用した責任の作成\color{green}{例 2 - 単純な工場ユニフォーム オブジェクトを使用した責任の作成}例2 -単純な工場制服オブジェクトを使用した責任の作成_
//示例.2——使用简单工厂统一对象创建职责
class BillFactory extend Factory{
public Bill creatBillByMoney(...){
...};
public Bill creatBillWithTag(...){
...};
//...
/* 封装一些细节处理方法帮助创建对象,这部分功能不应该在原类中提炼 */
private boolean dealDetails(...){
...};
//...
}
例 3 —— ファクトリ メソッドを使用して共通コードを抽出し、多態性の作成を保持\color{green}{Example.3—— ファクトリ メソッドを使用して共通コードを抽出し、多態性の作成を保持する}例3 ——ファクトリメソッドを使用して共通コードを抽出し、多態性の作成を保持する_
//示例.3——使用工厂方法提取共有代码,保留多态创建
abstract class NodeTest{
public void showNodeTest(){
Node node=creatNode();
node.addChild("next1");
node.addChild("next2");
//do other sameWork
node.show();//使用nomalNode的show测试
}
abstract Node creatNode();
}
/* 省去了重复写一大堆逻辑代码,只需要关注其不同的部分即可,下面两个类都相当于一个简单工厂类 */
class RootNodeTest extend NodeTest{
@Override
public Node creatNode(){
return new RootNode();
}
}
class NomalNodeTest extend NodeTest{
@Override
public Node creatNode(){
return new NomalNode();
}
}
3. リファクタリングアイコン
リファクタリング手順:
- 同じ名前の複数のコンストラクターの責任が不明瞭なコード、または長い構築プロセスを含むコードを検索する
- コンストラクターをカプセル化するメソッドを作成し、同じロジックを改良する
- 必要に応じて(作成メソッドが多すぎる、元のクラスが構築を担う必要がない)、単純なファクトリクラスを抽出
- ファクトリが複数あり、一部の処理ロジックが同じ場合はファクトリメソッドクラスを抽出
4. 問題のレビュー
1. 主なアプリケーションシナリオ? \color{blue}{1. 主な応用シナリオは? }1.主なアプリケーションシナリオ? _
回答: オブジェクトの作成に重点を置きます。同じ名前のコンストラクターが多すぎる場合は、使用には適していません。タスクの責任が適切に作成されていない場合は、作成関数パッケージを使用します。作成の責任を一元化するには、ファクトリ クラスを使用します。オブジェクト作成の処理メソッドが繰り返される場合 - ファクトリメソッドクラスを抽出
2. リファクタリングは必要ですか? \color{blue}{2. リファクタリングが必要ですか? }2.リファクタリングは必ず必要ですか?
回答: リファクタリングの目的は、理解を容易にし、コードを拡張しやすくすることです。拡張する必要がまったくない場合、またはコード サイズが小さい場合など、ファクトリ クラスを作成するために個別にラップする必要はありません。責任。ただし、コードを繰り返すと、オブジェクトを作成しすぎるとコードが肥大化し、理解しにくくなります。ためらわずにすぐにリファクタリングを開始し、問題をさらに大きくしないでください。
3. ファクトリ パターンに向けたリファクタリングまたはファクトリ パターンの実装はどのように役立ちますか? \color{blue}{3. トレンドへのリファクタリングやファクトリー パターンの実装はどのように役立ちますか? }3.トレンドへのリファクタリングやファクトリーパターンの実装はどのように役立ちますか? _ _ _ _ _ _
回答: オブジェクトの構築を理解しやすくし、構築と使用を切り離します (オブジェクトの作成プロセスを変更しても、そのオブジェクトを使用するコードに大幅な変更が生じることはありません)。責任の分担をより合理的にし、紙幣も同様にします。自分自身を印刷する責任はありません。解決策の一部は、異なるオブジェクトのコードの重複の問題の構築によるものです。
フォロー&励まし合い大歓迎です⭐️
⭐️⭐️Code Fox⭐️⭐️主な
内容:
- アルゴリズム ソリューション、アルゴリズム、データ構造を随時更新します
- 時々、魂の鶏スープを共有します。詳細は雑談コラムを参照してください
- 現在、私は主に Java の高度な内容 (仮想マシン、フレームワークなど) と、非常に重要なソフトウェア エンジニアリング、リファクタリング、デザイン パターンなどを学習しています。書籍内のナレッジ ポイントを洗練、要約、共有していきます。