-
Notifications
You must be signed in to change notification settings - Fork 7
[4주차] BLINK-ONCE #27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4주차] BLINK-ONCE #27
Changes from all commits
e7aaa17
47749ce
dbdfab2
5080475
8f6c2ff
61bda2c
b509a6c
c1a5aee
c7913a5
b9baf15
9ccc811
a5809a2
5789ea4
ebef17f
9fc1970
e93eaf1
7019086
63d8a8b
b7d3bfa
4ee0538
c3e9034
07951bb
1f255c1
867a5bd
d4d9fa5
2a9c710
4f4bbf4
2db0c07
b9ca082
cdbdfcf
0277af4
ebc32fb
1a8fcac
f54d3f5
347cff0
10c416e
b450a45
4097c58
7ca6941
348ead2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
*.gradle | ||
*.idea | ||
build | ||
gradle | ||
out | ||
gradlew | ||
*.bat |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,182 @@ | ||
# 자바 코드 실습 | ||
|
||
|
||
## 협업 | ||
|
||
- 합의에 도달하기 위한 갈등 과정은 자연스러운 것임을 받아들인다. | ||
|
||
- 서로에게 기대하는 바를 명확히 한다. 무루숭실한 표현은 추후 갈등이나 키운다. 따라서 기대한 산출물이 있다면 그것이 무엇인지 명확히 하고, 변경 가능성이 있는 것들은 그 내용이 무엇인지 미리 알려주는 것이 좋다. | ||
|
||
- 내 의견과 다른 의견, 원래 계획에서 달라진 상항들을 포용하려고 노력한다. 전문 분야, 경험, 개인적 목표가 다르기 때문에 다른 의견이 나오는 것은 당연하다. 자신의 의견만 관철시키려 하기보다 조직의 목표 달성을 위해 구성원이 합의할 수 있는 사항을 정의해가는 것이 중요하다. 또한 상황 변화에 따른 계획 변경에 대해서도 유연하게 대처하는 자세가 필요하다. | ||
|
||
- 다른 구성원과 유대감을 형성하거나 유지하기 위해 지속적으로 커뮤니케이션한다. 업무와 관련된 것뿐 아니라, 상대방이 관심을 보이는 정보를 공유하는 것도 한 방법이다. 예를 들면, 세미나 정보나 뉴스링크를 이메일로 보내주는 것이다. 때로 개인적인 경험을 공유하는 경우도 있으나 이것은 유대감의 긴밀도나 상대방의 특성에 따라 결정해야 할 문제다. | ||
|
||
- 상호 신뢰는 협업에서 가장 중요한 부분이다. 신뢰를 쌓으려면 말뿐 아니라 행동으로 보여야 한다. 약속이나 기한을 잘 지키는 것이 대표적인 예다. 문제가 생겼을 때 바로 공유하고 이를 해결하기 위해 도움을 주고 받는 것도 신뢰를 쌓는 방법이 될 수 있다. | ||
|
||
- 협업 도구를 적극적으로 활용하라. 구글 드라이브, 에버노트, 트렐로, 레드 펜, 인비전, 마인드 마이스터, 깃허브 등. 프로젝트의 성격과 산출물의 유형에 따라 적합한 도구를 이용하는 것도 협업의 성과에 큰 도움을 준다. | ||
|
||
- 협업에 방해되는 요인이 있다면, 구성원 또는 당사자와 공유하고 정정될 수 있도록 초기에 노력하는 것이 중요하다. 단, 특정 구성원이 다른 구성원 앞에서 당황스러움을 느끼게 해서는 안 된다. | ||
|
||
|
||
## 역할, 책임, 협력(Role, Responsibility, collaboration) | ||
|
||
### 객체지향 | ||
1. 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 **협력**이라고 한다. | ||
2. 객체가 협력에 참여하기 위해 수행하는 로직은 **책임**이라고 한다. | ||
3. 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 **역할**을 구성한다. | ||
|
||
### 역할 | ||
- 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라 한다. | ||
- 협력이라는 문맥 안에서 필요한 책임을 추렸다면, 해당 책임을 가지고 있어야 할 역할이 무엇인지 개념을 뽑아내고 그 다음에 역할에 맞는 이름을 부여하여 클래스로 만든다. | ||
#### 유연하고 재사용 가능한 협력 | ||
- 역할을 통해 유연하고 **재사용 가능한 협력**을 얻을 수 있다. | ||
- 역할에 집중하면 추상적인 네이밍을 가져도 문맥은 유지가 되고, 비슷한 구현의 다른 객체를 추가하는 데 큰 비용이 들지 않는다. | ||
- 객체에게 중요한 것이 행동임은 변함이 없다. 역할은 동일한 협력을 수행하는 객체들을 추상화할 수 있다. | ||
|
||
### 책임 | ||
#### 하는 것 | ||
- 객체를 생성하거나 계산 수행하는 등의 스스로 하는 것 | ||
- 다른 객체의 행동을 시작시키는 것 | ||
- 다른 객체의 활동을 제어하고 조절하는 것 | ||
#### 아는 것 | ||
- 사적인 정보에 대해 아는 것 | ||
- 관련된 객체에 대해 아는 것 | ||
- 자신이 유도하거나 계산할 수 있는 것에 대해 아는 것 | ||
|
||
|
||
- 객체에 의해 정의되는 응집도 있는 행위의 집합이자, 객체가 유지해야 하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 문장을 책임이라고 한다. | ||
- 책임은 메시지보다 추상적이고 개념적으로도 더 크다. | ||
- 객체지향 설계에서 책임을 얼마나 적절한 객체에게 할당하느냐가 설계가의 전체적인 품질을 결정한다. | ||
#### 책임주도 설계 | ||
- 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다. | ||
- 시스템이 책임을 더 작은 책임으로 분할한다. | ||
- 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다. | ||
- 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다. | ||
- 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다. | ||
#### 메시지가 객체를 결정 | ||
- 객체가 최소한의 인터페이스를 가질 수 있게 된다. | ||
- 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다. | ||
- 객체가 충분히 추상적이면서 미니멀리즘을 따르는 인터페이스를 가지게 하고 싶다면 메시지가 객체를 선택하게 하자. | ||
Comment on lines
+56
to
+59
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 메시지가 제일 중요하다! 라는 말의 정리본이라 볼 수 있겠네요 |
||
|
||
### 협력 | ||
협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다. 두 개개체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 할 때 시작된다. **메시지 전송**은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다. | ||
|
||
객체가 객체에게 무언가를 요청하는 것이고 다른 객체가 필요할 때 위임하거나 협력한다. | ||
|
||
- 어떤 객체가 다른 객체에게 무엇인가를 요청하는 것 | ||
- 한 객체는 어떤 것이 필요할 때 다른 객체에게 전적으로 위임하거나 서로 협력한다. | ||
- 두 객체가 상호작용을 통해 더 큰 책임을 수행하는 것이다. | ||
- 협력이 설계를 위한 문맥을 결정한다. | ||
- 상태는 객체가 행동하는 데 필요한 정보에 의해 결정되고, 행동은 협력 안에서 객체가 처리할 메시지로 결정된다. | ||
- 따라서 협력은 객체를 설계하는 데 필요한 일종의 문맥(context)를 제공한다. | ||
|
||
|
||
객체 지향 프로그래밍에서 객체는 하나의 책임을 가진 역할로서 협력에 참여하여 소프트웨어의 목적을 달성한다. | ||
|
||
책임은 메시지보다 더 큰 개념으로 객체가 직접 수행하는 행동들에 대한 추상적이고 응집도 있는 집합이라고 할 수 있다. 개발을 할 때는 아래와 같이 협력 관계를 먼저 파악하고 필요한 책임들을 추린 뒤, 역할별로 객체를 설계하면 된다. 객체의 상태(데이터)를 기반으로 설계하는 것은 올바른 역할을 추리지 못할 가능성이 높다. | ||
|
||
## 메시지와 행동 | ||
|
||
### 메시지가 객체를 결정한다. | ||
메시지가 객체를 선택해야 하는 이유는 아래와 같다. | ||
|
||
- 객체가 최소한 인터페이스를 가질 수 있게 된다.(필요한 크기의 퍼블릭 인터페이스를 가질 수 있음) | ||
- 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.(외부 객체가 요청하는 무언가를 의미하기 때문에 메시지를 먼저 식별하면 무엇을 수행할지에 초점을 맞추는 인터페이스를 얻을 수 있다.) | ||
|
||
### 행동이 상태를 결정한다. | ||
개체의 내부 구현에 초점을 맞춘 설계 방법을 데이터 주도 설계라 부르기도 했다. 캡슐화를 위반하지 않도록 구현에 대한 결정을 뒤로 미루면서 객체의 행위를 고려하기 위해서는 항상 협력이라는 문맥 안에서 객체를 생각해야 한다.(얻고 제공하는 것) | ||
|
||
|
||
## DTO(Data Transfer Object) | ||
데이터가 포함된 객체를 한 시스템에서 다른 시스템으로 전달하는 작업을 처리하는 객체이다. (레이어 간의 통신용도로 오가는 객체를 DTO라 하고, 특정한 비즈니스 값을 담는 객체를 VO라 한다.) | ||
|
||
|
||
데이터를 오브젝트로 변환하는 객체이다.(주체가 누구인가를 아는 것이 중요하다) | ||
|
||
DTO에서 Object는 우리가 만드는 DTO클래스이다. 아래는 PersonDTO 예시이다. | ||
```java | ||
class PersonDTO | ||
private String name; | ||
private int age; | ||
|
||
public void setName(String name){ | ||
this.name = name; | ||
} | ||
|
||
public String getName(){ | ||
return this.name; | ||
} | ||
|
||
public void setAge(int age){ | ||
this.age = age; | ||
} | ||
|
||
public int getAge(){ | ||
return this.age; | ||
} | ||
} | ||
``` | ||
|
||
Comment on lines
+90
to
+119
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. GOOOD There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 근데 GET, SET을 다여는건 좋진 않아요. 상황에 따라 하는 것이 좋습니다. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 넵 |
||
위 클래스에는 getter와 setter(name, age필드에 데이터를 읽고 쓰는 역할)가 존재한다. getter와 setter에서 get과 set이후에 나오는 단어(혹은 단어들)을 property라고 해보자. 즉, 위 클래스에서 name과 age를 property라 가정하는 것이다. | ||
|
||
여기서 property는 멤버변수 name, age로 결정 되는 것이 아닌 getter, setter에서의 name과 age이다. 멤버변수의 변수명은 아무렇게나 지어도 영향이 없고 getter, setter로 property를 표현한다는 것이다. <br> | ||
|
||
자바는 다양한 프레임 워크에서 데이터 자동화 처리를 위해 리플렉션 기법을 사용한다. 데이터 자동화 처리에서 가장 중요한 것은 표준규격이다. 예로, 위 클래스 DTO에서 property가 name, age라면 name, age의 키 값으로 들어온 데이터는 리플렉션 기법으로 setter를 실행시켜 데이터를 넣을 수 있다. | ||
|
||
우리가 setter를 요청하는 것이 아닌, 우리 눈에 보이지 않는 프레임워크단에서 setter가 실행된다. 데이터가 자동으로 클래스화가 되기 때문에 layer간에 데이터를 넘길 때 DTO를 사용하면 편하다. | ||
|
||
예로, form에서 name필드 값을 property에 맞춰서 값을 다른 페이지로 넘겼을 때, 값을 받아야할 페이지에서는 값을 하나씩 일일이 받는 것이 아니라 name 속성의 이름과 매칭 되는 property에 자동적으로 DTO가 인스턴스화 되어 PersonDTO를 자료형으로 값을 받을 수 있다는 것이다. 즉, key & value로 존재하는 데이터는 자동화처리된 DTO로 변환되어 우리는 손쉽게 데이터가 세팅된 오브젝트를 받을 수 있다. | ||
|
||
## VO(Value Object) | ||
- 필요성: network traffic 감소 | ||
- 장점: 비 서버 측 클라이언트도 네트워크 오버헤드 없이 영속성 데이터에 엑세스 할 수 있다. 데이터 전달을 위해 가장 효율적인 방법이다. | ||
- 단점: 클래스의 선언을 위해 많은 코드가 필요하다. 따라서 파일 수가 많아지고 관리도 힘들다. | ||
|
||
|
||
간단히 말하면 값을 위해 쓴다. 자바는 값 타입을 표현하기 위해 불변 클래스를 만들어 사용한다. (불변 클래스는 readOnly 특징을 가진다. 예로, String, Integer, Color 클래스가 있다.) 이런 클래스는 중간에 값을 바꿀 수 없고 새로 만들어야 한다. (Color클래스의 경우 Red라는 값을 표현하기 위해 Color.RED처럼 호출했을 때 값을 표현하기 위해 getter 기능만이 존재한다.) | ||
|
||
|
||
Comment on lines
+130
to
+138
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 살짝 부족한 설명. |
||
## VO와 DTO의 비교 | ||
DTO는 메소드 호출 횟수를 줄이기 위한 데이터를 담고 있는 것이고, VO는 값이 같으면 동일 오브젝트라고 볼 수 있는 것이라고 보통 표현한다. | ||
|
||
```java | ||
DTO a = new DTO(1); | ||
DTO b = new DTO(1); | ||
// a != b | ||
``` | ||
|
||
```java | ||
VO a = VO(1); | ||
VO b = VO(1); | ||
// a == b | ||
``` | ||
|
||
|
||
|
||
## 역할, 책임,협력(객체지향의 사실과 오해)->제일중요한 것은 메시지다. | ||
|
||
## vo(value object) | ||
|
||
## 문자열 계산기(프로그래밍 과제 1) | ||
|
||
|
||
# 자바 기초 | ||
|
||
### 학습할 것 | ||
- 산술 연산자 | ||
- 비트 연산자 | ||
- 관계 연산자 | ||
- 논리 연산자 | ||
- instanceof | ||
- aggignment operator(=) | ||
- 화살표 연산자(->) | ||
- 3항 연산자 | ||
- 연산자 우선 순위 | ||
- (optional) Java 13. swithch operator | ||
|
||
|
||
# Reference | ||
- [역할, 책임, 협력 1](https://velog.io/@ljinsk3/%EC%97%AD%ED%95%A0-%EC%B1%85%EC%9E%84-%ED%98%91%EB%A0%A5) | ||
- [역할, 책임, 협력 2](https://namget.tistory.com/entry/%EC%98%A4%EB%B8%8C%EC%A0%9D%ED%8A%B8-%EC%97%AD%ED%95%A0-%EC%B1%85%EC%9E%84-%ED%98%91%EB%A0%A5) | ||
- [DTO와 VO란?](https://mommoo.tistory.com/61) | ||
- [DTO, VO 차이점](https://itmore.tistory.com/entry/%EC%9E%90%EB%B0%94-VO-DTO-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B0%A9%EC%8B%9D%EC%9D%B4-%EA%B0%99%EB%8B%A4%EA%B3%A0-%EB%98%91%EA%B0%99%EB%8B%A4%EA%B3%A0-%EC%83%9D%EA%B0%81%ED%95%98%EC%A7%80-%EB%A7%90%EC%9E%90) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
좋은 의견.