Introduction
Design pattern are reusable solutions to common soft ware design problems.The Spring Framework is a perfect example of how design patterns can be effectively applied to create a robust and flexible application framework. In this article,I'll explore the key design patterns used in my miniSpring implementation.


Core Design Patterns



1. Factory Pattern
The Factory Pattern is central to Spring's IoC container:
⛶public interface BeanFactory {
Object getBean(String beanName) throws BeansException;
boolean containsBean(String name);
boolean isSingleton(String name);
boolean isPrototype(String name);
Class getType(String name);
}Implementation example
⛶public class DefaultListableBeanFactory extends AbstractAutowireCapableBeanFactory
implements ConfigurableListableBeanFactory {
protected MapString, BeanDefinition beanDefinitionMap =
new ConcurrentHashMap(256);

@Override
public Object getBean(String beanName) throws BeansException {
Object singleton = getSingleton(beanName);
if (singleton == null) {
singleton = createBean(beanName);
}
return singleton;
}
}Kay aspects:
Object creation abstraction
Dependency management
Lifecycle control



2. Proxy Pattern
The Proxy Pattern is used extensively in Spring's AOP implementation:
⛶public class JdkDynamicAopProxy implements AopProxy, InvocationHandler {
private Object target;
private PointcutAdvisor advisor;

@Override
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
if (this.advisor.getPointcut().getMethodMatcher()
.matches(method, target.getClass())) {
MethodInterceptor interceptor = advisor.getMethodInterceptor();
MethodInvocation invocation = new ReflectiveMethodInvocation(
proxy, target, method, args, target.getClass());
return interceptor.invoke(invocation);
}
return method.invoke(target, args);
}
}Features:
Dynamic proxy creation
Method interception
Advice application



3. Observer Pattern
The Observer Pattern is implemented in Spring's event mechanism:
⛶public interface ApplicationListenerE extends ApplicationEvent
extends EventListener {
void onApplicationEvent(E event);
}

public class SimpleApplicationEventPublisher
implements ApplicationEventPublisher {
private ListApplicationListener listeners = new ArrayList();

@Override
public void publishEvent(ApplicationEvent event) {
for (ApplicationListener listener : listeners) {
listener.onApplicationEvent(event);
}
}
}Key aspects:
Event publishing
Listener registration
Event handling



4. Template Method Pattern
The Template Method Pattern is used in JDBC operation:
⛶public class JdbcTemplate {
public Object query(String sql, Object[] args,
PreparedStatementCallBack pstmtCallBack) {
Connection con = null;
PreparedStatement pstmt = null;
try {
con = dataSource.getConnection();
pstmt = con.prepareStatement(sql);
ArgumentPreparedStatementSetter setter =
new ArgumentPreparedStatementSetter(args);
setter.setValues(pstmt);
return pstmtCallBack.doInPreparedStatement(pstmt);
} finally {
// Resource cleanup
}
}
}Features:
Algorithm skeleton
Customizable steps
Resource management



5. Strategy Pattern
The Strategy Pattern is used in various parts of Spring:
⛶public interface Pointcut {
MethodMatcher getMethodMatcher();
}

public class NameMatchMethodPointcut implements Pointcut {
private String mappedName = "";

@Override
public MethodMatcher getMethodMatcher() {
return new MethodMatcher() {
@Override
public boolean matches(Method method, Class targetClass) {
return mappedName.equals(method.getName());
}
};
}
}Key aspects:
Algorithm selection
Runtime configuration
Extensibility
## Pattern Integration
### 1. Factory and Proxy Integration

⛶public class ProxyFactoryBean implements FactoryBeanObject {
private Object target;
private PointcutAdvisor advisor;

@Override
public Object getObject() throws Exception {
return createAopProxy().getProxy();
}

protected AopProxy createAopProxy() {
return getAopProxyFactory().createAopProxy(target, this.advisor);
}
}


2. Observer and Template Method Integration
⛶public abstract class AbstractApplicationContext
implements ApplicationContext {
private ApplicationEventPublisher applicationEventPublisher;

public void refresh() throws BeansException {
// Template method steps
initApplicationEventPublisher();
registerListeners();
finishRefresh();
}

protected void finishRefresh() {
// Observer pattern usage
publishEvent(new ContextRefreshedEvent(this));
}
}


Design Pattern Benefits



1. Flexibility

Easy to extend
Loose coupling
Runtime configuration
### 2. Maintainability
Clear structure
Separation of concerns
Reusable components
### 3. Scalability
Modular design
Efficient resource management
Performance optimization



Best Practices



1. Pattern Selection

Match pattern to problem
Consider trade-offs
Avoid over-engineering
### 2. Implementation
Clean interfaces
Proper abstraction
Error handling
### 3. Integration
Pattern combination
Resource management
Performance consideration



Common Challenges and Solutions

Complexity Management


Clear hierarchy
Interface segregation
Documentation


Performance


Caching strategies
Resource pooling
Lazy initialization


Extensibility


Extension points
Plugin architecture
Custom implementations





Conclusion
Understanding design patterns through Spring implementation provides:
Deep insight into pattern usage
Practical application examples
Best practice guidelines
Problem-solving strategies
Key takeaways:
Pattern selection criteria
Implementation techniques
Integration approaches
Performance considerations
This implementation demonstrates how design patterns can be effectively combined to create a robust and flexible framework.

Introduction
Event-driven programming is a powerful paradigm that enables loose coupling between components in an application. In this article, I'll explore how to implement an event publishing and listening mechanism in a Spring-like framework, based on my miniSpring project's implementation.


Core Components
The event mechanism implementation consists of several key components:
⛶src/com/yaruyng/context/
├── ApplicationEvent.java
├── ApplicationListener.java
├── ApplicationEventPublisher.java
├── SimpleApplicationEventPublisher.java
├── ApplicationContextEvent.java
├── ContextRefreshEvent.java
└── ContextRefreshedEvent.java


Event Base Class
The ApplicationEvent class serves as the base for all application events:
⛶public class ApplicationEvent extends EventObject {
private static final long serialVersionUID = 1L;
protected String msg = null;

public ApplicationEvent(Object source) {
super(source);
this.msg = source.toString();
}
}Key features:
Extends EventObject from Java standard library
Serializable support
Source object tracking
Message support



Event Listener Interface
The ApplicationListener interface defines the contract for event listeners:
⛶public interface ApplicationListenerE extends ApplicationEvent extends EventListener {
void onApplicationEvent(E event);
}Features:
Generic type support
Single responsibility principle
Clear event handling contract



Event Publisher
The SimpleApplicationEventPublisher implements the event publishing mechanism:
⛶public class SimpleApplicationEventPublisher implements ApplicationEventPublisher {
ListApplicationListener listeners = new ArrayList();

@Override
public void publishEvent(ApplicationEvent event) {
for (ApplicationListener listener : listeners) {
listener.onApplicationEvent(event);
}
}

@Override
public void addApplicationListener(ApplicationListener listener) {
this.listeners.add(listener);
}
}Key aspects:
Listener management
Event broadcasting
Synchronous event processing



Context Events



1. Context Refresh Event
⛶public class ContextRefreshEvent extends ApplicationContextEvent {
public ContextRefreshEvent(ApplicationContext source) {
super(source);
}
}


2. Context Refreshed Event
⛶public class ContextRefreshedEvent extends ApplicationContextEvent {
public ContextRefreshedEvent(ApplicationContext source) {
super(source);
}
}


Integration with Application Context
The AbstractApplicationContext integrates event support:
⛶public abstract class AbstractApplicationContext implements ApplicationContext {
private ApplicationEventPublisher applicationEventPublisher;

public abstract void registerListeners();
public abstract void initApplicationEventPublisher();

public void refresh() throws BeansException, IllegalStateException {
// Initialize event publisher
initApplicationEventPublisher();

// Register listeners
registerListeners();

// Other initialization steps...

// Publish refresh event
finishRefresh();
}

public void finishRefresh() {
publishEvent(new ContextRefreshedEvent(this));
}
}


Event Processing Flow



1. Event Register
⛶public void registerListeners() {
String[] beanDefinitionNames = this.getBeanFactory().getBeanDefinitionNames();
for (String bdName : beanDefinitionNames) {
Object bean = getBean(bdName);
if(bean instanceof ApplicationListener) {
this.getApplicationEventPublisher()
.addApplicationListener((ApplicationListener) bean);
}
}
}


2. Event Publishing
⛶public void publishEvent(ApplicationEvent event) {
this.getApplicationEventPublisher().publishEvent(event);
}


Usage Example



1. Creating Custom Events
⛶public class UserRegisteredEvent extends ApplicationEvent {
private final User user;

public UserRegisteredEvent(Object source, User user) {
super(source);
this.user = user;
}

public User getUser() {
return user;
}
}


2. Implementing Event Listeners
⛶@Component
public class EmailNotificationListener implements ApplicationListenerUserRegisteredEvent {
@Override
public void onApplicationEvent(UserRegisteredEvent event) {
User user = event.getUser();
// Send welcome email
sendWelcomeEmail(user);
}
}


3. Publishing Event
⛶@Service
public class UserService {
@Autowired
private ApplicationEventPublisher eventPublisher;

public void registerUser(User user) {
// Save user
userRepository.save(user);

// Publish event
eventPublisher.publishEvent(new UserRegisteredEvent(this, user));
}
}


Key Features



1.Event Types

Context events
Custom events
Event hierarchy
### 2. Listener Management
Dynamic registration
Type-safe handling
Multiple listeners
### 3. Event Publishing
Synchronous processing
Error handling
Event ordering



Best Practice

Event Design


Clear event hierarchy
Immutable event data
Meaningful event names


Listener Implementation


Single responsibility
Error handling
Performance consideration


Event Publishing


Appropriate timing
Error propagation
Transaction boundaries





Common Challenges and Solutions

Event Ordering


Listener priority
Synchronous processing
Event queuing


Error Handling


Exception propagation
Listener isolation
Recovery mechanisms


Performance


Asynchronous processing
Event filtering
Listener optimization





Conclusion
Implementing an event mechanism provides:
Loose coupling between components
Asynchronous communication
Extensible architecture
Decoupled business logic
Key takeaways:
Understanding event-driven architecture
Event listener patterns
Event publishing mechanisms
Integration with IoC container
This implementation demonstrates how to create a robust event system while maintaining simplicity and flexibility.

? The Problem
Say Alice wants to send 100,000 sats to Bob.But:
Alice only has on-chain Bitcoin.
Bob only uses the Lightning Network.
They want to swap — but without using a centralized exchange or trusted custodian.
Can they do it trustlessly?Yes — with:

DIDs (Decentralized Identifiers)

Nostr (a decentralized messaging protocol)
Bitcoin + Lightning

HTLCs (Hashed Time-Locked Contracts)



? A Simple Use Case
Let’s walk through a real-world example that almost anyone can understand:


? Scenario: On-chain to Lightning Swap


Alice wants to pay 100k sats on-chain.

Bob wants to receive 100k sats on Lightning.
They don’t trust each other and want to swap trustlessly.



? Enter DID + Nostr + HTLCs



✅ 1. Identity via DIDs on Nostr

Both Alice and Bob have DIDs tied to their Nostr pubkeys.
DIDs make it possible to verify identities and sign messages.
Alice posts a signed message to Nostr offering the swap.

⛶{
"type": "swap-offer",
"from": "did:nostr:pubkeyalice",
"to": "any",
"amount": 100000,
"direction": "onchain-to-lightning",
"hashlock": "abcdef123456...",
"expires_in": 3600
}Bob sees it and replies with a signed acceptance.


? 2. Coordinating via Nostr

The offer and acceptance are broadcast as ephemeral Nostr events.
Both parties agree on:


The amount
The hashlock
Timeouts
Where to send funds





No servers, no intermediaries — just pubkey-signed messages over a decentralized relay network.


? 3. The HTLC Swap
They now execute the swap using the same secret hash:


Alice (on-chain):

Sends 100k sats to a Bitcoin HTLC (can only be claimed with the secret before timeout).



Bob (Lightning):

Sends 100k sats to a Lightning HTLC (also locked with the same hash).
As soon as one party claims the funds, the preimage is revealed, and the other can claim theirs too.


✅ 4. Atomic Swap Complete

Bob claims the on-chain BTC → reveals the secret.
Alice uses the same secret to claim her Lightning BTC.

No one can cheat — it’s enforced by the HTLCs and timeouts.



✨ Why This Matters
This setup gives us:✅ Trustless swaps
✅ No custodians or centralized services
✅ Cross-layer interoperability
✅ Identity-based coordination via Nostr DIDsAnd it all works with:
Bitcoin
Lightning
DID documents
Open message relays



? What’s Next?

Add wallet support for DID-authenticated swap offers over Nostr.
Explore multi-party or ring swaps.



? TL;DR

DID + Nostr + HTLCs = trustless swaps across Bitcoin and Lightning, with identity and coordination baked in.
No middleman. Just keys, hashes, and the open web.