Java 자바 웹 프로그래밍: <켄트 벡의 구현패턴> 데이터 오브젝트 DTO, VO

Java 자바 웹 프로그래밍: <켄트 벡의 구현패턴> 데이터 오브젝트 DTO, VO

 

 

<켄트 벡의 구현패턴> 서적 참조

데이터 오브젝트 DTO, VO

 

	프레젠테이션 Layer	비즈니스 데이터	퍼시스턴스 Layer
사용자	UI	비즈니스 객체	영속객체
		B.O	DAO(Data Access Object
	--DTO->		파일 IO

 

분석 -> 설계 -> 구현 -> 테스트 -> 분석 (일반적인 최근의 방식) 애자일 방법론.

분석 -> 설계 -> 구현 -> 테스트 (폭포수형, Top Down방식)

애자일 소프트웨어 개발 선언.

애자일 소프트웨어 개발 선언   우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:   공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를   가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

 

트리형 클래스 설계는 변화에 대응하기 어려웠다. 때문에 Look up 구조(중앙에 하나에서 모든걸처리)와 injection 구조가 생겼다.

패키지명은 도메인의 역순.

double도 Double로 쓴다. int 도 Integer로 쓴다. 만들면, 0이 아니라 null 값을 가진다. 이런 값들은 식별키를 가진다.

기본 클래스의 변수 선언 -> getter /setter -> 해쉬코드와 equals를 만든다. -> toString 만든다.

FoodStore 기준으로 코딩 설명.

Lng, Lat를 그냥 받지 말고 Location 이라는 클래스를 하나 만들어서 구현. 왜냐하면 위도와 경도는 떨어지지 않는 변수이기 때문에.

상위 클래스에서 상속 같은거 하지 않고 Location 이라는 클래스를 하나 생성.

# 해쉬코드 공부할 것.

코딩을 할 때 가능하면 상위 타입을 쓰면 쓸수록 코드는 유연해진다. ArrayList 쓰지 않고 List를 사용한다.

인젝션 설계. UI쪽에선 인터페이스만 보도록 설계한다. 실제로 구현된 것은 참조하지 않는다.

UI쪽도 인터페이스로 뺄 수 있지 않았을까? 웹UI따로 안드로이드 UI따로 이런식으로....

 

(if ~ else를 쓰지 않는다 -> HashMap를 사용

while 루프 없앤다)

UI의 가장 큰 특징은 루프에요.

public class FoodStoreUI

private FoodStoreService service; // FoodStore의 interface

private Scanner scanner;

public FoodStoreUI (FoodStoreService service){

this.service = service;

}

코딩을 하다가 중복되는 코드가 있으면 abstract class(추상클래스)로 빼준다.

doJob(); 은 예외처리가 되어있지. 문제가 생기면 반드시 내게 메시지를 던져주기로 되어있지.

첫 번째 비즈니스 오브젝트에서 인터페이스를 빼서 설계하는 방법을 보여주고 싶었고, 코딩을 하면서 추상클래스로 언제 빼는지를 알려주고 싶었다.

패키지명.원하는기능메소드명

String name = “org.thinker.fs.SearchNearStoreUI”

Class clz = Class.forName(name);

Task object = (Task)clz.newInstance();

다운캐스팅은 인터페이스와 추상클래스에서만 사용하도록.

자바의 동적로딩

클래스를 실시간으로 동적으로 컴파일 해서 사용할 수 있도록.

파일을 로딩할 때, properity를 사용할 거에요. 원리는 InputStream이랑 같아요. 잘라내는 것 밖에 차이점이 없어요

Map은 딕셔너리에요. 어떠한 키로 객체를 찾는거에요. 가장 많이 쓰는게 해쉬맵이에요.

소스코드를 보면 인터페이스를 얼마나 효과적으로 쓰는가를 보면 알 수 있어요

좋은 코드의 기준. 한 번 만들어 놓고 바꾸지 않으면 좋은코드에요.

엄밀하게 말하자면, 인터페이스를 활용하는 방식이 접근 제한이라고 할 수 있다.

예를 들어, 아이폰의 OS를 만들고 아이팟에서는 전화기능에 관한 기능을 인터페이스에서 삭제한다.

함수로 만드는 경우와 객체로 만드는 경우의 기준? Math.random();이 있고 new Random();이 있다.

데이터를 유지하는 경우에는 객체로 만든다. 데이터를 유지하지 않는 경우 함수로 설계하는 경우가 대부분. 함수는 side effect가 없다.

디자인 패턴에서는 각각의 UI기능을 뺀 것을 worker라고 부르고, 이를 총괄하는 것을 worker handler라고 부른다.

동적로딩의 이유. 안드로이드, Servlet. 설정파일을 만들기 위해.

equals와 hashcode를 예전에 오버라이딩 한 적이 있다.

# 내일 이걸 이용해서 모든 프로그램을 완성시키는 것이 과제. (오늘~내일)

싱글턴 Singleton 패턴. 이런 설계를 더 편하게 하려고 사람들이 고안해낸 설계패턴

객체생성을 막는 패턴. 객체가 하나 밖에 없다. 언제 어디서나 동일한 객체를 사용한다.

객체를 여러개를 만들다 보면 데이터가 똑같은 데이터가 아닐 수 있다.

객체를 만들 때, 데이터 때문에 만드는 경우도 있지만, 메모리 때문에 만드는 경우가 있다. 객체를 하나만 만들면 메모리가 절약된다.

클래스명 Singleton

1. 생성자를 private으로 만든다.

2. 클래스 내부에 private static Singleton instance = new Singleton(); 으로 객체를 만들어준다.

3. public static 으로 getter를 만든다.

4. 호출시, Singleton.getter 호출

메모리 공부. 구분되어 있다.

class영역 메모리

객체 영역 메모리

int, String, double, 이런 것들은 imutable 이라고 한다. 한 번 만들면 값을 바꿀 수가 없다.

또 다른 방법. 인터페이스에는 상수가 있습니다.

FoodStore instance = new FoodStoreDAOImpl();

위의 코드를 인터페이스에 선언하면, 하나의 객체만 계속 쓸 수 있다. 이 패턴은 권장사항은 아니다.

이 전체 패턴은 headfirst design 패턴 책에 보면 전략패턴으로 나온다. 중급개발자끼리는 이 패턴 전략패턴으로 구현했어요 라고 하면 이야기가 끝나요. 전략패턴에 대해 찾아보세요.

# 오늘 과제. 오늘 코딩 리뷰. 동적로딩을 활용해서 계산기를 제작. UI만 제작. 사칙연산 기능 분리. store.txt파일 만들었던 것처럼 파일만 수정하면 동작할 수 있도록.

인터페이스 잡고. 짜요. 짜다가 겹쳐, 그럼 추상클래스로 빼.

# 오늘 과제2. 파워포인트 조별 과제. 내용. 자바의 자료구조. 자바의 자료구조는 무엇무엇이 있고 특징이 있고, 장단점이 있다. 똑같은 자료구조인데 구현된 자료구조는 특징이 다를 수 있어요. 이를테면, List라는 자료구조가 있는데 ArrayList와 LinkedList는 각자 특징이 다르다. 이번 발표를 못하면 다음주 내내 시달릴 것이니 준비 단단히 할 것!

Iterator names = prop.keySet().iterator();

while(names.hasNext()){

String key = (String)names.next();

String value = (String)prop.get(key);

System.out.println(key +":" + value);

Task obj = (Task)Class.forName(value).newInstance();

obj.setService(service);

taskMap.put(key, obj);

}

return taskMap;

// Iterator는 자바의 반복자. (반복자는 외부반복자와 내부반복자로 나뉘는데, 자바는 외부반복자만 존재) 개체의 요소들을 출력할 때, 기존의 인덱스 값을 이용한 호출이 불편하다고 생각해서 생긴 편리한 방식이다.

하지만, 주의 사항이 있다. Iterator는 지시하고자 하는 대상과 대상의 사이를 가리키지만 인덱스 호출방식은 그 대상을 직접 지시한다.

Iterator의 경우 hasNext( ) 메소드를 이용해서 다음 요소가 있는지 확인을 해야하는데 확장된 for 루프문(foreach)은 이런 과정을 우리가 수동으로 체크하지 않아도 되도록 만들어놨기 때문에 단순 리스트 출력은 이것을 사용하는 것이 편하다.