ㅋㅋㅋ Inversion of Control(Inversion of Control, 영어로 IoC로 약칭)은 프레임워크의 중요한 기능이며 객체 지향 프로그래밍을 위한 특별한 용어는 아닙니다. DI(종속성 주입) 및 종속성 조회와는 아무런 관련이 없습니다. ㅋㅋㅋ Spring을 사용해 본 개발자들은 모두 ioc 제어 반전 기능에 대해 모두 알고 있습니다.
IOC 구현을 위한 종속성 주입종속성 주입은 IOC의 가장 기본적인 구현 방법이자 가장 일반적으로 사용되는 객체지향 설계 방법 중 하나입니다. 제어 효과 반전을 달성하기 위해 종속성을 주입하는 방법은 다음 예제로 시작합니다.
public interface UserQueue {void add(User user);void remove(User user); User get(); }public abstract class AbstractUserQueue implements UserQueue {protected LinkedList<User> queue = new LinkedList<>(); @Overridepublic void add(User user) { queue.addFirst(user); } @Overridepublic void remove(User user) { queue.remove(user); } @Overridepublic abstract User get(); }public class UserFifoQueue extends AbstractUserQueue {public User get() {return queue.getLast(); } }public class UserLifoQueue extends AbstractUserQueue {public User get() {return queue.getFirst(); } }
UserQueue
인터페이스는 대기열에 사용자 개체를 저장하기 위한 공용 메서드를 정의합니다. AbstractUserQueue는 후속 상속 클래스에 대한 몇 가지 공통 메서드 구현을 제공합니다. 마지막 UserFifoQueue
및 UserLifoQueue는 각각 FIFO 및 LIFO 대기열을 구현합니다.
이것은 하위 클래스 다형성을 달성하는 효과적인 방법입니다. UserQueue
接口定义了公共的方法,用于在一个队列中去存放User对象。AbstractUserQueue则是为后续的继承类,提供了一些公用的方法实现。最后的UserFifoQueue
和 UserLifoQueue,则是分别实现了FIFO 和 LIFO 队列。
这是实现子类多态性的一种有效方式。
通过创建一个依赖于UserQueue抽象类型(也称为DI术语中的服务)的客户端类,可以在运行时注入不同的实现,无需会重构使用客户端类的代码:
public class UserProcessor {private UserQueue userQueue;public UserProcessor(UserQueue userQueue) {this.userQueue = userQueue; }public void process() {// process queued users here } }
UserProcessor展示了依赖注入确实是IOC的一种方式。
我们可以通过一些硬编码方式 如 new 操作,直接在构造函数中实例化在UserProcessor中获取对队列的依赖关系。但这是典型的代码硬编程,它引入了客户端类与其依赖关系之间的强耦合,并大大降低了可测性。
该类在构造函数中声明对抽象类 UserQueue
的依赖。也就是说,依赖关系不再通过在构造函数中使用 new 操作, 相反,通过外部注入的方式,要么使用依赖注入框架,要么使用factory或builders模式。
使用依赖注入,客户端类的依赖关系的控制,不再位于这些类中;而是在注入器中进行,看如下代码:
public static void main(String[] args) { UserFifoQueue fifoQueue = new UserFifoQueue(); fifoQueue.add(new User("user1")); fifoQueue.add(new User("user2")); fifoQueue.add(new User("user3")); UserProcessor userProcessor = new UserProcessor(fifoQueue); userProcessor.process(); }
上述方式达到了预期效果,而且对UserLifoQueue的注入也简单明了。
UserQueue 추상 유형(DI 용어로 서비스라고도 함)에 의존하는 클라이언트 클래스를 생성하면 클라이언트 클래스를 사용하는 코드를 리팩터링하지 않고도 런타임에 다양한 구현을 삽입할 수 있습니다.
public interface SubjectObserver {void update(); }
이 클래스는 생성자의 추상 클래스 UserQueue
에 대한 종속성을 선언합니다. 즉, 종속성은 더 이상 생성자에서 new를 사용하여 작동되지 않으며 대신 종속성 주입 프레임워크를 사용하거나 팩토리 또는 빌더 패턴을 사용하여 외부적으로 주입됩니다.
종속성 주입을 사용하면 클라이언트 클래스 종속성에 대한 제어가 더 이상 이러한 클래스에 위치하지 않고 대신 인젝터에서 수행됩니다. 다음 코드를 참조하세요.
public class User {private String name;private List<SubjectObserver> observers = new ArrayList<>();public User(String name) {this.name = name; }public void setName(String name) {this.name = name; notifyObservers(); }public String getName() {return name; }public void addObserver(SubjectObserver observer) { observers.add(observer); }public void deleteObserver(SubjectObserver observer) { observers.remove(observer); }private void notifyObservers(){ observers.stream().forEach(observer -> observer.update()); } }
위 방법은 예상한 효과를 달성합니다. UserLifoQueue의 주입도 간단하고 명확합니다.
Observer 패턴을 통해 IOC를 직접 구현하는 것도 일반적이고 직관적인 방법입니다. 대체로 IOC는 관찰자를 통해 구현됩니다. 관찰자 패턴은 일반적으로 모델 뷰의 컨텍스트에서 모델 개체의 상태 변경을 추적하는 데 사용됩니다.
public static void main(String[] args) { User user = new User("John"); user.addObserver(() -> System.out.println("Observable subject " + user + " has changed its state.")); user.setName("Jack"); }
값이 변경되면 위에서 언급한 매우 간단한 관찰자에 대한 호출이 트리거됩니다. 실제 상황에서는 저장해야 할 인스턴스를 변경하거나 기존 값과 새 값을 변경하는 등 좀 더 풍부한 기능을 갖춘 API를 제공하는 경우가 많지만, 이는 액션(행동) 모드를 관찰할 필요가 없으므로 여기서는 최대한 간단하게 예제를 작성합니다. .
user.addObserver(() -> System.out.println("Observable subject " + user + " has changed its state."));
public abstract class EntityProcessor {public final void processEntity() { getEntityData(); createEntity(); validateEntity(); persistEntity(); }protected abstract void getEntityData();protected abstract void createEntity();protected abstract void validateEntity();protected abstract void persistEntity(); }
上述用例,简要说明了为什么观察者模式是实现IoC的一种非常简单的方式。正是以这种分散式设计软件组件的形式,使得控制得以发生反转。
模板方法模式实现的思想是在一个基类中通过几个抽象方法来定义一个通用的算法,然后让子类提供具体的实现,这样保证算法结构不变。
我们可以应用这个思想,定义一个通用的算法来处理领域实体,看例子:
public abstract class EntityProcessor {public final void processEntity() { getEntityData(); createEntity(); validateEntity(); persistEntity(); }protected abstract void getEntityData();protected abstract void createEntity();protected abstract void validateEntity();protected abstract void persistEntity(); }
processEntity()
方法是个模板方法,它定义了处理实体的算法,而抽象方法代表了算法的步骤,它们必须在子类中实现。通过多次继承 EntityProcessor 并实现不同的抽象方法,可以实现若干算法版本。
虽然这说清楚了模板方法模式背后的动机,但人们可能想知道为什么这是 IOC 的模式。
典型的继承中,子类调用基类中定义的方法。而这种模式下,相对真实的情况是:子类实现的方法(算法步骤)被基类的模板方法调用。因此,控制实际是在基类中进行的,而不是在子类中。
总结:
依赖注入:从客户端获得依赖关系的控制不再存在于这些类中。它存由底层的注入器 / DI 框架来处理。
观察者模式:当主体发生变化时,控制从观察者传递到主体。
模板方法模式:控制发生在定义模板方法的基类中,而不是实现算法步骤的子类中。
위 내용은 IOC 제어 반전 예제에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!