1.シングルトンデザインパターン
- シングルトンデザインパターン：クラスのメモリにオブジェクトが1つしかないことを確認します。
- クラスのメモリにオブジェクトが1つしかないことを確認するにはどうすればよいですか？
（1）クラスの作成を制御し、他のクラスがこのクラスのオブジェクトを作成しないようにします。それはコンストラクターを私有化することです。
private
（2）このクラスでこのクラスのオブジェクトを定義します。
Singleton s;
（3）パブリックアクセス方法を提供します。
public static Singleton getInstance(){return s}
1つのケースを作成する方法は2つあります。（1）空腹の中国人このように開発する。
public static void main(String[] args) {
/*
* Singleton s1=Singleton.s;
* Singleton.s =null;
* Singleton s2=Singleton.s;
* //如果下面设置public属性，
* 此时两个对象一个是调用了Single的成员变量，
* 一个是设置成了null。这样对象会进行修改
*/
//使用饿汉式创建对象,此时我们才分为一个对象
Singleton s1=Singleton.getSingleton();
Singleton s2=Singleton.getSingleton();
System.out.println(s1==s2);
}
class Singleton{
//1.私有构造方法，其他类不能访问该构造方法
private Singleton() {
}
//2.创建本类对象，如果该处使用public方式的话，会出现
private static Singleton s =new Singleton();
//3.对外提供公共访问发给发
public static Singleton getSingleton() {
//获取实例
return s;
}
}
出力結果は次のとおりです。True。現時点では同じオブジェクトだからです。
（2）怠惰な男 このように書くインタビュー
最初にオブジェクトを作成するのではなく、ユーザーが必要なときにのみ作成してください。目的はスペースを節約することです
class Singleton{
//懒汉式,单例的延迟加载模式
//1,私有构造函数
private Singleton () {
}
//2,声明一个本类的引用
private static Singleton s;
//3,对外提供公共的访问方法
public static Singleton getSingleton() {
if (s==null) {
s=new Singleton();
}
return s;
}
}
このメソッドには特定の欠陥があります。複数のスレッドからアクセスしても安全であり、複数のオブジェクトが作成されます。
空腹の人と怠惰な人の違いは何ですか？
- 空腹の人のタイプは時間の空間であり（メモリ空間が現れると開かれるため）、怠惰な人のタイプは空間の時間です。（判断する必要があります）
- マルチスレッドアクセスでは、空腹の人は複数のオブジェクトを作成しませんが、怠惰な人は複数のオブジェクトを作成する可能性があります。
（3）3番目の方法：
sの値を変更しない限り、目的は非常に明確です。
class Singleton {
private Singleton() {
}
public static final Singleton s = new Singleton();
//final是最终的意思,被final修饰的变量不可以被更改
}
2.装飾的なデザインパターン
public static void main(String[] args) {
// TODO Auto-generated method stub
SmartStudent smartStudent =new SmartStudent(new Student());
smartStudent.code();
}
}
interface Coder{
public void code();
}
class Student implements Coder{
@Override
public void code() {
System.out.println("JavaSE");
}
}
class SmartStudent implements Coder{
//1.获取被装饰类的引用
private Student student;
//2.在构造方法中传入被装饰类的对象
public SmartStudent(Student student) {
this.student = student; //获取学生引用
}
//3.对原有的功能进行升级
@Override
public void code() {
student.code();
System.out.println("数据库");
System.out.println("SSH");
}
装飾デザインパターンの利点は、結合が強くなく、装飾クラスの変更が装飾クラスの変更とは関係がないことです。
3、テンプレート（テンプレート）デザインモード
- テンプレートデザインパターンの概要
テンプレートメソッドのパターンは、アルゴリズムのスケルトンを定義し、特定のアルゴリズムをサブクラスに遅延させて実装することです。
- 長所と短所
利点
- テンプレートメソッドモードを使用すると、アルゴリズムスケルトンを定義しながら、特定のアルゴリズムを柔軟に実装して、ユーザーの柔軟なニーズを満たすことができます。
不利益
- アルゴリズムスケルトンが変更された場合は、抽象クラスの
ケースを変更する必要があります（一定期間実行するプログラムを計算します）
public class Demo1_Template {
public static void main(String[] args) {
Demo demo =new Demo();
System.out.println(demo.getTime());
}
}
abstract class GetTime{
public final long getTime() {
long start=System.currentTimeMillis();
Code();
long end=System.currentTimeMillis();
return end-start;
}
public abstract void Code();
}
class Demo extends GetTime{
@Override
public void Code() {
for (int i = 0; i < 100000; i++) {
System.out.println("x");
}
}
}
4.シンプルなファクトリーモデル
静的ファクトリメソッドパターンとも呼ばれ、一部のクラスのインスタンスの作成を担当する特定のファクトリクラスを定義します
利点：
クライアントはオブジェクトの作成に責任を持つ必要がないため、各クラスの責任が明確になります
短所：
この静的ファクトリクラスは、すべてのオブジェクトの作成を担当します。新しいオブジェクトが追加されたり、一部のオブジェクトが異なる方法で作成されたりした場合、ファクトリクラスは常に変更する必要があり、その後のメンテナンスには役立ちません。
ケース：
ステップ1：インターフェースを作成する
public abstract class Animal {
public abstract void eat();
}
ステップ2：動物インターフェースメソッドを実装するための猫と犬のクラスを書く
public class Dog extends Animal {
@Override
public void eat() {
System.out.println("狗吃肉");
}
}
public class Cat extends Animal {
@Override
public void eat() {
System.out.println("猫吃鱼");
}
}
ステップ3：ファクトリを実装する（ユーザーがオブジェクトを作成する）
public class AnimalFactory {
//用于创建对象
//public static Dog createDog() {
// return new Dog();
//}
//public static Cat createCat() {
// return new Cat();
//}
//但是该工厂会定义很多方法，需要创建很多对象。复用性太差
//改进2.0版本
public static Animal createAnimal(String name) {
if ("dog".equals(name)) {
return new Dog();
}
else if ("cat".equals(name)) {
return new Cat();
}else {
return null;
}
}
}
ステップ4：テストを行う
public class Test {
public static void main(String[] args) {
//Dog d =AnimalFactory.createDog();
Dog dog =(Dog) AnimalFactory.createAnimal("dog");
dog.eat();
}
}
単純なファクトリデザインパターンには明らかな欠点があります。ファクトリに必要なオブジェクトがない場合、空のオブジェクトが返され、ポインタの例外が発生します。
ファイブ、ファクトリーメソッドモデル
概要：
ファクトリメソッドパターンの抽象ファクトリクラスは、オブジェクトを作成するためのインターフェイスを定義する役割を果たし、具象オブジェクトの作成は、抽象ファクトリを継承する具象クラスによって実装されます。
利点
クライアントはオブジェクトの作成を担当する必要がないため、各クラスの責任が明確になります。新しいオブジェクトを追加する場合は、特定のクラスと特定のファクトリクラスのみを追加する必要があります。これは、既存のコードに影響を与えず、後で簡単に保守できます。システムのスケーラビリティを強化するため
不利益
追加のコードを記述し、作業負荷を増やす必要があります
ケース：
ステップ1：動物のインターフェースを作成する
public abstract class Animal {
public abstract void eat();
}
手順2：インターフェイスメソッドを実装するエンティティクラスを作成する
public class Cat extends Animal {
@Override
public void eat() {
System.out.println("猫吃鱼");
}
}
public class Dog extends Animal {
@Override
public void eat() {
System.out.println("狗吃肉");
}
}
ステップ3：ファクトリメソッドを定義する
public interface Factory {
public Animal createAnimal();
}
ステップ4：工場を開いて猫工場と犬工場を実現する
public class CateFactory implements Factory {
@Override
public Animal createAnimal() {
return new Cat();
}
}
public class DogFactory implements Factory {
@Override
public Animal createAnimal() {
return new Dog();
}
}
テストを行う：
public class TEST {
public static void main(String[] args) {
DogFactory dogFactory =new DogFactory();
Dog dog =(Dog) dogFactory.createAnimal();
dog.eat();
CateFactory cateFactory =new CateFactory();
Cat cat =(Cat) cateFactory.createAnimal();
cat.eat();
}
}