설정파일을 저장하고 가져오는 라이브러리입니다.
sjava-config는 http://www.jconfig.org/ 의 jconfig를 보고 필요한 형태(xml만 지원)로만 개발했습니다.
여러형태의 설정파일을 읽어올 수 있도록 common한 기능은 추상 클래스로 빼고 설정을 읽는 코드는 하위 클래스에서 구현을 합니다.
System.out.println("- get vlaue test ---");
System.out.println(configHandler.getValue("config", "watch"));
System.out.println(configHandler.getValue("config", "interval"));
System.out.println(configHandler.getValue("log", "host"));
System.out.println(configHandler.getValue("log", "port"));
System.out.println(configHandler.getValue("auth", "host"));
System.out.println(configHandler.getValue("auth", "port"));
System.out.println("- default value test ---");
System.out.println(configHandler.getValue("config", "watch", "false"));
System.out.println(configHandler.getValue("config", "interval", "11"));
System.out.println(configHandler.getValue("log", "host", "222.222.222.222"));
System.out.println(configHandler.getValue("log", "port", "20003"));
System.out.println(configHandler.getValue("auth", "host", "222.222.222.222"));
System.out.println("- array value test ---");
for(int i = 0; i < configHandler.getValues("log", "host").length; i++) {
System.out.println(configHandler.getValues("log", "host")[i].toString());
}
for(int i = 0; i < configHandler.getValues("auth", "host").length; i++) {
System.out.println(configHandler.getValues("auth", "host")[i].toString());
}
System.out.println("- add value ---");
configHandler.addValue("test", "host", "1.1.1.1");
System.out.println(configHandler.getValue("test", "host"));
System.out.println("- modify value ---");
configHandler.setValue("test", "host", "2.2.2.2");
System.out.println(configHandler.getValue("test", "host"));
Reactor 패턴을 이용해서 자바로 네트워크 서버를 개발하다 보면, 하나의 Reactor로는 고 성능이 아니더라도 동접을 2000 이상 붙여보면 성능저하를 눈으로 확인해 볼 수 있습니다.. 그래서 Reator를 Master-Slave의 형태와 Slave Reactor를 cpu 갯수만큼 만들어서 성능을 높일 수 있습니다. 그러한 구조를 한눈에 알 수 있게 보여주는 그림입니다.. ^^
객체가 스스로 참조하는 객체를 생성하지 않고, 외부 환경(컨테이너)에서 삽입 되는 형태를 DI(Dependency Injection)라고 하네요.. ^^
DI 를 구현하는 방법은 2가지가 있네요..
1. Constructor 방식
public class Shop {
private final StockManager stockManager;
private final String shopZipCode;
public Shop(StockManager stockManager, String shopZipCode) {
this.stockManager = stockManager;
this.shopZipCode = shopZipCode;
}
}
2. Setter 방식
public class Shop {
StockManager stockManager;
String shopZipCode;
/**
* @service name="StockManager"
*/
public void setStockManager(StockManager stockManager) {
this.stockManager = stockManager;
}
/**
* @config name="shopZipCode"
*/
public void setStockManager(String shopZipCode) {
this.shopZipCode= shopZipCode;
}
// TODO - Joe - how does setter injector do config ? Same way?
public void initialize() {
// all setXXXs are now done :-)
}
}
흠.. 로그 처리를 위한 파일에 스트링을 추가하는 클래스를 BufferedWriter로 구현을 하다가 갑자기 BufferedOutputStream으로 하는것과의 차이점을 알고 싶어서 아래의 코드로 차이를 살펴봤습니다.
아래의 BufferWriterTest, BufferOutputStream 클래스의 buffersize는 1024로 동일합니다.
Master-Slave Pattern은 Master가 Slave에게 작업을 분산하고, Slave를 통해서 받은 결과를 통해서 최종 결과를 계산해 내는 패턴이라고 하네요.. 따라서, Master는 작업을 쪼개고, Slaver에게 분배하고, 결과를 계산하는 역할을 할 것이고, Slave는 Master의 작업요청을 처리해서 결과를 리턴하면 되겠네요..
제가 생각하는 내용을 아래의 형태별로 간단하게 코드로 끄적여 봅니다.
예는 1부터 10까지의 factorial을 10개의 Job으로 나누고, 그것을 Master가 더하기를 합니다.
아래의 MSClient는 Client와 Master의 역할을 담당하게 되고, JobThread는 Slave의 역할을 담당합니다.
혹시 코드보시고, 틀렸다고 생각이 되시는 부분이 있으면 답글로 끄적여 주시면 감사하겠습니다.
Whole-Part 패턴은 Whole 객체를 구성하는 Part 객체들을 모으고, 그 객체들간의 협력을 통해서 기능을 구현하는 패턴입니다. 그리고, Whole 객체가 클라이언트에 인터페이스를 제공하고 Part 객체들은 Whole객체만을 통해서 접근을 하게 만들어 주는 형태입니다. GOF의 Composite 패턴과 동일한 느낌이네요.. ^^;;
제가 생각하는 내용을 아래의 형태별로 간단하게 코드로 끄적여 봅니다.
아래의 WPClient는 Car라는 Whole 객체를 통해서 앞으로 뒤로 기능을 테스트 합니다.
혹시 코드보시고, 틀렸다고 생각이 되시는 부분이 있으면 답글로 끄적여 주시면 감사하겠습니다.
WPClient.java
package client;
import wp.Car;
import wp.part.*;
public class WPClient {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
Car car = new Car();
car.setEngine(new Engine());
car.setLight(new Light());
car.setWheel(new Wheels());
Presentation Abstraction Control Pattern은 계층 형태의 시스템에서 각 단계별로 Agent를 가지고, Agent들이 계층적(상,하)으로 협력을 하는 구조가 필요할 때 사용할 수 있는 패턴이라고 하네요.. 각 Agent는 계층의 레벨에 맞는 기능을 담당합니다. 그리고 각 Agent는 Presentation, Abstraction, Control을 가질 수 있습니다.
제가 생각하는 내용을 아래의 형태별로 간단하게 코드로 끄적여 봅니다.
아래의 TopAgent는 데이타를 가지고 있고, InterMediateAgent는 mediate 기능을 담당하고 실제로 뷰는 BottomAgent를 통해서 구현을 합니다. 그리고, BottomAgent는 view()는 인터페이스로 뽑고, setter, getter 메쏘드는 Abstract Class를 통해서 여러개의 BottomAgent를 구현하면 좋을듯 합니다.
혹시 코드보시고, 틀렸다고 생각이 되시는 부분이 있으면 답글로 끄적여 주시면 감사하겠습니다
PACClient.java
public class PACClient {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
pac.TopAgent tAgent = new pac.TopAgent();
pac.inter.InterMediateAgent interAgent = new pac.inter.InterMediateAgent();
pac.bottom.BottomAgent bAgent = new pac.bottom.BottomAgent();
@SuppressWarnings("deprecation")
public String getData() {
this.data = "loading data "
+ new java.util.Date().getYear() +", "
+ new java.util.Date().getMonth() +", "
+ new java.util.Date().getDay() +", "
+ new java.util.Date().getHours() +", "
+ new java.util.Date().getMinutes() +", "
+ new java.util.Date().getSeconds();
간단하게 말하면 복잡한 시스템을 레이어로 나눠서 Task를 하위 레이어 또는 상위 레이어로의 Delegation을 통해서 구조화를 하는 패턴이라고 생각이 듭니다.
제가 생각하는 내용을 아래의 형태별로 간단하게 코드로 끄적여 봅니다.
아래의 top-down은 layer별 interface가 필요할 것 같고, 그 인터페이스를 layer에 해당하는 기능 클래스(Level0201, Level0202)가 구현을 해서 상위 Layer가 하위 Layer에 Dependency를 줄이면서 사용하면 될 것 같습니다.
그리고, bottom-up은 상속을 통해서 상위 클래스의 메쏘드를 호출하는 형태로 구현을 해 봤습니다.
혹시 코드보시고, 틀렸다고 생각이 되시는 부분이 있으면 답글로 끄적여 주시면 감사하겠습니다.
1. Top-Down Layer 형태
Level01.java
package layer.down;
import java.nio.ByteBuffer;
public class Level01 {
ByteBuffer buffer;
Level02Interface levelTwo; // Level02-1
public void setByteBuffer(ByteBuffer buffer) {
this.buffer = buffer;
}
public void setLevel() {
this.levelTwo = new Level0201();
}
public void printLevel() {
if(buffer.getInt() == 4)
this.levelTwo = new Level0202();