이 글에서는 스토리텔링이라는 형태로 사물을 관리하는 방법을 알려드리는데, 관심 있는 친구들이 함께 살펴보며 수업에 대해 더 깊이 이해할 수 있기를 바랍니다.
어느 날 밤 갑자기 내 마음 속에 "우리 코드에서 개체를 관리하는 방법"이라는 질문이 떠올랐습니다.
Xiao Yi는 제가 처음 일을 시작했을 때의 나였습니다. New를 통해 객체를 만들고 직접 사용하면 됩니다.
public class HelloWorld { public void hello() { System.out.println("hello world!"); } } HelloWorld helloWorld = new HelloWorld(); helloWorld.hello();
보세요, HelloWorld 클래스가 있습니다. new를 사용하여 개체를 직접 만든 다음 이 개체의 모든 메서드를 사용할 수 있습니다.
에리는 2년째 일을 하고 있는 나야. 샤오이에게 경멸하는 표정으로 하루종일 헬로월드 하지 말라고 했어. 그리고 넌 신입 외에는 아무것도 모르잖아? 좀 쫓아다녀?
Xiao Yi가 Er Yi에게 말했습니다. 새로운 것 외에 또 무엇을 할 수 있나요?
Eryi는 Class의 newInstance나 Constructor의 newInstance를 통해 객체 인스턴스를 생성할 수 있다고 말했습니다.
하지만 Class의 newInstance는 액세스 가능한(Accessible) 매개변수 없는 생성자가 있는 클래스에 대해서만 객체를 인스턴스화할 수 있지만 Constructor에는 이러한 제한이 없다는 점을 기억해야 합니다.
3년 동안 일한 Da Yi는 당신의 방법을 사용하여 객체를 만들 수 있지만 모두 수동으로 생성되므로 너무 원시적이고 생산성이 너무 낮다고 말했습니다.
일꾼이 일을 잘하려면 먼저 도구를 갈고 닦아야 하며 효율적인 생산성 도구도 찾아야 합니다. IOC 컨테이너에 대해 알고 계시나요?
과거에는 객체에서 다른 객체의 메소드를 호출하고 싶을 때 New나 Reflection을 통해 수동으로 객체를 생성했는데, 매번 이렇게 하는 것이 너무 힘들고, 클래스 간의 결합도도 매우 높았습니다.
IOC 컨테이너를 통해 모든 객체를 컨테이너에 넘겨 관리할 수 있습니다. 객체를 사용하기 전에 객체를 정의하기만 하면 객체를 사용할 때 IOC 컨테이너가 객체를 초기화하는 데 도움이 됩니다. 응? 뭐가 더 편리해?
Da Yi는 말하기를 마친 후 다음과 같은 예를 들었습니다.
@Bean public class RegisterService { public void register() { // do register } } @Bean public class LoginService { public void login() { // do login } } @Bean public class HelloWorld { @Autowired private RegisterService registerService; @Autowired private LoginService loginService; public void hello() { // 注册 registerService.register(); // ... // 登录 loginService.login(); } }
IOC 컨테이너는 Bean이라는 주석을 사용하여 시스템이 시작될 때 Bean으로 주석이 달린 모든 클래스를 스캔하고 이러한 클래스를 인스턴스화한 다음 모든 개체를 컨테이너에 저장합니다. 그런 다음 Autowired로 표시된 모든 속성이나 메서드를 검색하고 컨테이너에서 일치하는 개체(이름이나 유형 등으로)를 찾은 다음 특정 개체를 이러한 속성에 할당합니다. 이런 식으로 우리는 이러한 물건을 직접 사용할 수 있습니다. 손을 잡고 파티를 하는 것이 정말 행복하지 않나요?
Lao Yi는 5년 동안 일해 온 Dayi의 말을 듣고 의문을 제기했습니다. 새로운 프로젝트에는 이런 IOC 컨테이너를 사용할 수 있지만 기존 프로젝트에는 IOC를 사용해야 합니다. 변형은 그다지 현실적이지 않습니다.
예를 들어 보겠습니다. 오래된 레거시 프로젝트에는 핵심 인터페이스인 Handler가 있습니다.
public interface Handler<REQ, RES> { RES handle(REQ request); }
Handler 인터페이스에는 다양한 요청에 대해 서로 다른 Handler 구현 클래스를 호출해야 합니다. 처리 전에 어떤 핸들러 구현 클래스를 사용할지 모르기 때문에 IOC 컨테이너를 사용하여 이러한 구현 클래스를 관리하는 데 적합합니다.
Da Yi는 핸들러 인터페이스에 고정된 구현 클래스가 몇 개만 있고 하나만 처리에 사용된다면 시작하기 전에 구성을 통해 사용할 핸들러를 결정할 수 있다고 생각했습니다. 예를 들어 @Conditional을 사용하여 특정 조건에 따라 로드할 특정 객체를 결정하지만 Handler 객체를 사용할 때 유형을 결정하는 것은 정말 까다롭습니다.
라오 이는 모두가 침묵하는 것을 보고 말을 이었다.
메서드 호출 시 서로 다른 핸들러를 사용하여 서로 다른 요청을 처리하려면 두 클래스, 즉 요청 클래스와 처리 클래스를 결정해야 하며 요청 클래스와 처리 클래스를 서로 매핑해야 합니다. 하나.
요청 클래스가 Packet 클래스이고 각 특정 요청 클래스가 이 기본 클래스에서 상속된다고 가정합니다.
따라서 각 특정 패킷의 유형을 확인하려는 경우 다음과 같이 각 패킷에 고유한 이름을 지정할 수 있습니다.
public abstract class Packet { public abstract String name(); }
다음과 같이 각 패킷에 플래그를 지정할 수도 있습니다.
그러나 어떤 방법이든 각 패킷 구현 클래스는 그것이 어떤 종류의 패킷인지 "표시"하기 위해 추상 클래스의 메서드를 구현해야 합니다. 두 개의 특정 패킷이 있다고 가정하고 두 번째 방법을 예로 들어 보겠습니다.public abstract class Packet { public abstract int symbol(); }이러한 방식으로 요청 개체를 받으면 request.symbol()을 호출하여 요청이 어떤 유형의 패킷인지 알 수 있습니다. 현재로서는 이를 처리할 특정 Handler 구현 클래스만 찾으면 됩니다. 이제 요청 클래스가 결정되었으므로 핸들러 처리 클래스를 어떻게 결정합니까? 다음과 같이 Handler 인터페이스에 기호 메서드를 정의할 수도 있습니다.
public class RegisterPacket extends Packet { // 注册所需要的其他参数 int symbol() { return 1; } } public class LoginPacket extends Packet { // 登录所需要的其他参数 int symbol() { return 2; } }이 경우 핸들러가 처리하는 데 사용되는 요청 종류를 표시하기 위해 모든 구현 클래스에서 기호 메서드만 구현하면 됩니다.
public interface Handler<REQ, RES> { int symbol(); RES handle(REQ request); }마지막으로 모든 Handler 구현 클래스를 인스턴스화하고 이를 HandlerProvider에 저장합니다. 이를 사용하려면 HandlerProvider에서 가져올 수 있습니다.
public RegisterHandler implements Handler<RegisterPacket, RES> { int symbol(){ return 1; } RES handle(RegisterPacket request){ // 具体的处理方法 } } public LoginHandler implements Handler<LoginPacket, RES> { int symbol(){ return 2; } RES handle(LoginPacket request){ // 具体的处理方法 } }그렇다면 모든 Handler 구현 클래스를 가져오는 방법에는 두 가지가 있습니다. 방법.
一种是通过 ServiceLoader.load(Handler.class) 的方式来获取,不过这种通过 spi 的方式需要在项目的 resources/META-INF/services/ 目录下创建一个 xxx.Handler 的文件,并在文件中将所有 Handler 的实现类的完全类限定符列出来。
另一种比较简单的方式是通过扫描的方式,获取到所有 Handler 的实现类。
到现在为止,我们的实现还算可以,但是有一个问题,那就是在 Handler 接口中我们增加了一个方法,这样做就对原来的代码进行了侵入。
为了让原来的代码保持不变,我们可以定义一个注解来标注在所有的 Handler 实现类上,比如这样:
@Symbol(1) public RegisterHandler implements Handler<RegisterPacket, RES> { RES handle(RegisterPacket request){ // 具体的处理方法 } } @Symbol(2) public LoginHandler implements Handler<LoginPacket, RES> { RES handle(LoginPacket request){ // 具体的处理方法 } }
这样就将 Handler 的实现和标注进行了解耦了,也可以通过扫描 @Symbol 注解来获取到所有的 Handler 实现类,不过这样做的缺点就是假如我忘记对某个 Handler 实现类添加 @Symbol 注解,到时候就获取不到该 Handler 了。
大家听完老弈的话之后,都陷入了沉思,我靠,还可以这么玩,真有趣。
这时候现在的我,也就是逅弈,说了一句,如果我有一个接口,他只有几个固定的实现类,我不想搞那一套那么重的实现方式,但是我也需要动态的获取实现类来对请求进行处理,那我该怎么办呢?
比如我有一个序列化的接口,如下所示:
public interface Serializer { byte[] serialize(Packet packet); }
然后只有五种具体的序列化的实现类,如下所示:
public class JdkSerializer implements Serializer { @Override public byte[] serialize(Packet packet) { // 具体的序列化操作 } } public class FastJsonSerializer implements Serializer { @Override public byte[] serialize(Packet packet) { // 具体的序列化操作 } } public class HessianSerializer implements Serializer { @Override public byte[] serialize(Packet packet) { // 具体的序列化操作 } } public class KryoSerializer implements Serializer { @Override public byte[] serialize(Packet packet) { // 具体的序列化操作 } } public class ProtoStuffSerializer implements Serializer { @Override public byte[] serialize(Packet packet) { // 具体的序列化操作 } }
那么我们该怎么确定使用哪种序列化方式对参数 packet 进行序列化呢?
使用老弈刚刚说的那一套也确实能够实现,不过太麻烦了,又得对 Packet 定义 symbol,又得对 Hander 实现类进行标注,还得扫描所有的实现类。
我只有五个实现类,不需要搞那么麻烦的。
其实很简单,只需要定义一个枚举类,表示序列化的算法,然后对 Packet 增加一个 algorithm 方法用来表示,使用何种序列化算法,如下所示:
public enum SerializeAlgorithm { JDK((byte) 1), FAST_JSON((byte) 2), HESSIAN((byte) 3), KRYO((byte) 4), PROTO_STUFF((byte) 5); private byte type; SerializeAlgorithm(byte type) { this.type = type; } } public abstract class Packet implements Serializable { public abstract byte algorithm(); }
然后定义一个 SerializerChooser 根据不同的算法选择不同的 Serializer 实现类即可:
public interface SerializerChooser { Serializer choose(byte algorithm); }
因为根据算法是可以知道对应的序列化接口的,所以就没有必要去扫描了,直接把几种序列化的实现类枚举出来即可,对象的实例可以使用单例模式,如下所示:
public class DefaultSerializerChooser implements SerializerChooser { private DefaultSerializerChooser() { } public static SerializerChooser getInstance() { return Singleton.get(DefaultSerializerChooser.class); } @Override public Serializer choose(byte algorithm) { SerializeAlgorithm serializeAlgorithm = SerializeAlgorithm.getEnum(algorithm); switch (serializeAlgorithm) { case JDK: { return Singleton.get(JdkSerializer.class); } case FAST_JSON: { return Singleton.get(FastJsonSerializer.class); } case HESSIAN: { return Singleton.get(HessianSerializer.class); } case KRYO: { return Singleton.get(KryoSerializer.class); } case PROTO_STUFF: { return Singleton.get(ProtoStuffSerializer.class); } default: { return null; } } } }
我说完后,大家又一次陷入了沉思,我知道大家都在思考,他们会在每一次思考中获得进步和成长,正如我在思考后得到成长一样。
小鸟总有一天会成长为老鸟,我还走在成长的路上。
위 내용은 Java에서 객체를 더 잘 관리하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!