1. 브랜드 : 폭스바겐, 나이키

<<폭스바겐은 왜 고장난 자동차를 광고했을까?>> 책의 제목이지만 266 페이지중, 단 3 페이지만 차지한, 수많은 이야기 중 하나다. 광고는 보통 자사의 장점 만을 얘기한다. 폭스바겐은 불량이 난 차를 광고했다. 폭스바겐의 품질검사에서 어떻게 이 차량이 불량 판정을 받았는지, 어떤 검사원이 이 불량을 발견했는지 광고했다. 자사의 엄격한 품질검사 과정을 보여줌으로써 소비자들의 신뢰를 얻었다. 책 제목으로 선정된 것에 비해 매우 짧은 스토리였지만, 제목만으로 소비자(=나)의 관심을 끌은 것에 대해 마케팅에 대한 이야기를 소개하는 책 답다는 생각이 들었다.

<<나이키: 저스트 두 잇 의 탄생>> 댄은 밤늦도록 나이키의 광고 카피를 고민했다. 그러다 사형수의 마지막 유언이 스쳐 지나갔다. 죽기전, 마지막으로 하고 싶은 말이 있냐는 질문에 사형수는 답했다. 'Let's do it.(자, (사형집행을) 시작합시다)' 댄은 다시 광고 카피를 생각했다. 사형수의 최후진술이 마음에 들지 않았다. 다시 고쳐서 적었다. 'Just do it.' 생뚱맞은 상황을 떠올리며 얻게된 슬로건. 영감은 언제나 예기치 않은 순간에 떠오른다. 계속 코딩에 대한 생각을 하며 산책을 하면 퍼뜩(!) 해결방법이 떠오르는 것처럼.

2. 혁신 : 튜브(영국지하철), 에이비스

<<튜브 : 영국의 지하철이 최악에서 최고가 된 작은 비밀>> 세계 최초의 지하철인 영국의 튜브 지하철. 평판은 좋지 못했다. 여러 투자로 지하철 환경을 개선해도 부정적인 평가가 많았다. 취한 전략은 '무소식이 희소식 안내방송 전략.' 이전의 안내방송은 정류장과 방향을 알려주거나 안전에 유의하라는 방송, 혹은 문제상황을 알려주는 방송이 다였다. 좋은 이야기에 대한 방송은 없었다. 그래서 좋은 소식을 알리기 시작했다. 우수한 서비스를 알리는 방송, 지하철이 문제없이 운행되고 있다는 방송. 승객 만족도가 점차 올라갔고 파리와 마드리드를 이기고 최고의 지하철이 되었다. 회사에서 보고를 할때도 마찬가지일 것이다. 프로젝트가 문제없이 진행되고 있다는 보고. 이미 앞서서 버그를 고쳐두었기 떄문에 다른 문제들이 생기지 않았다는 보고. 너무 자주하면 안되겠지만 무소식이 희소식 전략이 중요한 것 같다.

<<에이비스 : 렌터카 넘버2 업체의 생존전략>> 에이비스는 심각한 적자 상황이었다. 이를 타개하기 위해 회사에 긍정적인 이미지가 필요했다. 2등 전략의 광고를 통해 성공했다. "에이비스는 업계 2위에 불과합니다. 그러므로 우리는 더욱 노력합니다." 업계 2위임을 선언하며, 소비자들에게 최선을 다하겠다고 전했다. 실제로도 소비자들에게 향상된 서비스를 제공하기 위해 노력했다. '1등만 기억하는 더러운 세상' 이라는 유행어가 있다. 수능을 보면 그 해 1등이 누구인지 궁금해한다. 브랜드에서도 oo업계 1위 를 홍보한다. 그러나 생각을 바꾸어 보면, 우리가 기억하는 2등도 있다. '만년 2등 홍진호.' 브랜딩을 하는데 있어서는 2등의 효과(라이벌 효과)도 중요하다고 생각한다. 사람들이 1등을 기억할때 자연스럽게 2등도 따라올테니.

3. 아이디어, 실행, 리더 : 굿럭 마가린, 토이스토리

<<굿럭 마가린 : 퍼스트레이디의 마가린 광고는 왜 실패했을까?>> 미국 전대통령 루스벨트의 영부인인 엘리너 루스벨트. 엘리너를 모델로 마가린 광고를 했으나 광고효과는 부진했다. 모델 자체가 워낙 유명인이기에 엘리너가 광고를 했다는 사실만 사람들에게 기억되었다. 마가린 제품 자체는 관심에 없었다. 무조건 유명한 사람을 쓴다고 제품홍보가 되지는 않는다. 무언가를 광고하려면 항상 유념해야 할 사항이다. 목적은 제품을 광고하는 것이다. 그 목적을 이룰 수 있을지 고민하며 광고를 진행하자.

<<토이스토리 : 스티브 잡스의 철학, 토이스트리의 탄생>> 잡스는 픽사 직원에게 당부했다. 우수한 품질을 보장해야 한다. 대중이 브랜드에 대해 느끼는 방식은 은행 계좌와 같다. 예금을 할 수도, 인출을 할 수도 있다. 인출 계좌가 되는 일이 없도록 하자. 애플에서 컴퓨터를 만들면 컴퓨터의 수명은 고작 4~5년 이지만, 영화들은 이 세상에 영원히 남게된다. 잡스는 언제나 더 높은 수준을 추구하고 도달하도록 유도했고, 이를 바탕으로 픽사의 토이스토리가 탄생했다. 잡스가 말한 '브랜드는 은행 계좌' 라는 점이 와닿았다. 소비자들이 브랜드에 흥미가 떨어지고 신뢰를 잃게되면 계좌는 바닥날 수 있다. 언제나 브랜드의 평판을 유지하기 위해 애써야 하고 품질을 최상으로 보장하도록 해야 한다.

나의 주저리

재미있었다. 짧은 이야기들로 구성되어 있어 쉽게 읽혔다. 당시 기업들이 직면한 세세한 상황을 알 수는 없지만 다양한 기업들이 생사의 과정에서 취한 전략들을 읽었다. '브랜드' 라는 것은 참 어렵다. 이미지를 쌓아가는 것도, 유지하는 것도 어렵지만, 특히, 브랜드의 가치가 훼손되었을때 다시 신뢰를 회복하는 것도 무척이나 어렵다. 내가 한 기업을 운영하는 것은 아니지만 '나'라는 사람을 운영하는 기업가(?)로써 자신을 어떻게 브랜딩해야 하는가에도 접목시켜볼 만한 책인 것 같다.

1. 못난 게 아니라 마음이 힘든 겁니다.

파트 1 에서 가장 공감 갔던 사례는 학습된 무기력과 적응장애, 목적 없는 질주이다.

이직하고 회사에 다니면서, 그 팀에서 내가 가장 못하는 사람 같았다. 다들 너무나도 잘하고 어나더레벨처럼 보였다. 면접 볼 때는 열심히 하겠다고 잘할 수 있다고 해놓고서는, 막상 회사에 다니면서 자신감이 엄청나게 떨어졌다. 내가 못 하는 일을 시킬까 봐 전전긍긍 하기도 하고 학습된 무기력 수준이 아니라 그냥 나는 뭘 할 수 있나…? 어떻게 해야 하나…? 나랑 맞지 않은 회사를 온 것 같았다.

책에서는 학습된 무기력일 때, 내가 아무것도 할 수 없는 하찮은 존재라 느껴질 때, 작은 것부터 시도하라고 한다. 운동이라도 요리라도. 나는 이것을 잘하는 사람이구나. 이렇게 하나씩 긍정적인 경험을 다시 학습해야 한다고. 적응장애를 겪을 땐, 자신을 이해하라고 한다. 힘들어하고 있는 자기 자신을 깨닫고 이해하고 지지해주라고. 나를 응원해주라고 한다. 목적 없는 질주하고 있다면? 당연히 목적을 찾아야겠지.버킷리스트든, 무엇이든 목적을 가지라 한다.

나는 힘들었을 때, 블라인드 댓글에 있던 책 구절로 위로받았다. 회사에서의 모습이 당신의 전부는 아니라고. 어쩌면 회사에서 당신은 무능할 수도 있지만, 그건 단지 회사에서일 뿐이라고. 당신은 그것보다 더 많은, 다양한 면을 더 많이 가지고 있다고(예전에 캡처해서 저장해두었는데 삭제한 듯). 지금은 힘들었던 적응의 시기를 지나 잘 먹고 잘 잔다. 이런 시간이 부정적이지만은 않다. 이렇게 힘듦의 시기를 지나면 좀 더 단단해지기도 하기에.

2. 상처받은 건 그가 아니라 '나' 입니다.

파트 2에서 마음에 와닿은 문장은 "우리는 누구나 공격자가 될 수 있다"

누군가가 나에게 공격자가 될 수 있는 만큼, 나 또한 누군가에게 공격자가 될 수 있다. 나도 너무나 나약하고 부족한 사람이라는 것을 항상 기억하자. 또한 기억해야 할 것은, "자기가 하기 싫은 일을 남에게 하게 해서는 안 된다"<논어>

3. 나부터 잘 알아야 일도 더 잘됩니다.

회의 공포증, 걱정 조절하기, 거울 자아의 사례가 기억에 남는다. 회의 공포증은 내 경우엔, 공포라기보다는 떨리는 정도다. 마음에 짐이 되는 정도? 왜냐면 회의를 할 때 각자 무슨 일을 했고 어떻게 했고 남은 일은 뭔지 얘기하는데, 발표하는 것 같고 말을 잘하지 못하는 것 같고 평가받는 것 같아서 떨렸다. 그래서 내가 선택한 방법은 대본을 쓰는 거였다. 대본이 있으면 안 떨리고, 말도 좀 더 정리된 채로 전달이 되어서, 지금도 열심히 회의 시간에 대본을 읽고 있다. 그리고 목소리가 떨릴 때는 잠시 숨을 한번 쉬고 다시 읽으면 괜찮아진다. 언젠가는 뭐 대본 없이도 말을 잘 전달할 수 있는 사람이 되겠지.

걱정 조절하기. 근데 걱정은 어떻게 조절하는 거예요? 나는 원래부터 걱정 순이라서 그냥 걱정을 열심히 충분히 하고 살기로 했다. 걱정하면 좋은 점이 있다. 나름 스스로 최악의 상황을 걱정했기에 현실이 긍정적으로된다(대부분 최악의 상황은 오지 않기에). "오 최악의 상황은 피했군. 굿굿!"
완벽한 내가 되려는 거울 자아. 대학생 때 완벽해야 한다는 강박을 많이 극복했던 것 같다. 나는 내가 생각한 만큼 완벽한 사람이 될 수는 없다고. 나는 완전 연약한 인간이라고. 완벽하지 못한 나를 보며 실망하는 게 아니라, 오늘의 나를 칭찬하는 거다. 오늘 열심히 책을 읽고 독후감 쓴 나 자신 칭찬해!

4. 그럼에도 내 마음이 가장 소중합니다.

모든 일, 모든 상황에서 내 마음이 가장 소중하다. 다른 사람 아니고 나. 남의 판단 아니고 나. 그냥 나.

나의 주저리 : 나

"나"라는 단어를 말할 때, 가장 자신의 목소리가 나온다고 한다. 나. 당신이 주인공이라는 말이 있듯이, 나 자신이 나의 삶의 가장 중요한 사람이라는 것을 기억하자. 삶의 많은 부분을 겪어왔음에, 잘 지나갔음에 감사하다. 그리고 무엇보다 나를 잘 돌아보고 응원해야 한다는 것에 공감한다. 오늘도 나 자신, 수고 많았고 앞으로도 응원한다.

생산수단은 생산물을 생산해 낼 수 있다. 책에서는 5개의 분야 역사, 경제, 정치, 사회, 윤리에 관해 설명하지만, 특히 생산수단의 변화가 만들어 낸 역사의 흐름이 인상 깊어서 역사 중심으로 책의 내용을 정리하고자 한다.

역사

원시, 고대, 중세, 근대, 현대 : 생산수단과 공급과잉

<생산수단> ** 원시**는 공산사회로 재산을 공동으로 소유하고 관리하는 시대다. 소득이 있으면 함께 나누고 없으면 함께 굶는다. 생산수단도 소유주도 없는 평등한 사회다.

고대 시대는 토지, 영토가 중요한 생산수단이다. 생산수단은 왕이 소유했고 다른 사람의 노동력을 이용할 수 있는 도구가 되었다. 토지가 없는 사람들은 토지를 소유한 사람의 밑으로 들어가 일한다. 왕, 노예 등의 계급이 만들어졌다. 중세 시대. 왕, 성직자, 영주, 기사, 농노, 노예 등 계급은 더욱 세분된다. 생산수단을 왕뿐만 아니라 영주도 소유한다.

근대사회는 자본주의사회다. 생산수단이 공장과 자본으로 바뀐다. 생산수단의 소유주는 왕이 아닌 부르주아다. 계급은 크게 부르주아와 프롤레타리아(생산수단을 소유하지 않은 자들)로 나뉜다.

<자본주의 : 공급과잉의 사회> 산업혁명에 의해 자본주의 시대가 도래한다. 자본주의의 특징은 공급이 수요보다 큰, 공급과잉의 사회다. 공급과잉을 해결하기 위한 방법은 첫째, 수요를 늘리는 것이다. 많아진 공산품들을 소비할 시장이 필요해진다. 식민지를 통해 시장을 개척해 나갔다. 이 과정에서 1차 세계대전이 일어났다.

공급과잉을 해결하기 위한 두 번째 방법은 가격을 낮추는 것이다. 가격경쟁은 인건비를 줄이기 위한 구조조정으로 이어졌고, 대량실업이 발생했으며 이에 따라 소비심리가 위축되었다. 경제 대공황이 찾아왔다. 대공황을 해결하기 위해 미국은 뉴딜정책을 러시아는 공산주의, 독일의 군국화 등 각국은 다양한 정책을 펼쳤다. 독일의 군국화는 2차 세계대전을 일으켰다.

현대 시대는 세계대전이 끝난 후 승전국인 미국과 소련 중심으로 냉전 시대가 도래한다. 자본주의와 공산주의가 대립했다. 냉전 이후, 자본주의가 독주하는 시대가 되어 역사는 오늘날에 이르렀다.

나의 주저리 : 생산수단의 힘

(제 생각과 느낀점입니다) 생산수단이 중요하다는 것을 알고 있었지만 책을 읽으면서 내가 체감하고 있는 것 이상으로 너무나도 중요하다고 느꼈다. 역사는 주요 생산수단이 '무엇' 이고 '누가' 소유하냐에 따라 흘러왔다. 시대에 따라 토지, 공장, 자본과 같은 생산수단이 생겼고 왕, 영주, 부르주아가 생산수단을 소유했다. 생산수단의 변화로 (특히 공장) 세계는 전쟁이 발발하기도 하고, 경제 대공황을 맞이하기도 하며 현재에 이르렀다.

이렇게나 중요한 생산수단! 현재는 어떤 생산수단이 있고 과거와 무엇이 다르며, 누가 소유하고 있을까?

1) 과거의 생산수단은 현대에서도 여전히 중요할까? 중요하다. 그러나 각 생산수단의 가치는 동일하지 않다. 즉, '어떤 부가가치를 창출할 수 있는 생산수단인지?'도 중요하다. 땅으로 예를 들자면, 팔릴만한 가치가 있는 땅인가? 건물을 지을 수 있는 곳인가? 아무것도 개발 못 하는 땅인가? 에 따라 땅의 가치가 다르다.

2) 현대에 새로 생겨난 생산수단이 있을까? 과거와 다른 점은? '플랫폼'이다. 예를 들면, 유튜브. 유튜브는 사람들이 자기 창작물(동영상)을 올리는 공간이다. 유튜브는 사람들에게 동영상을 노출할 수 있는 공간을 제공한다. 사람들은 자기 노동력의 결과인 동영상을 올린다. 즉, 생산수단은 유튜브가 생산물은 사람들이 창작하는 것이다.

과거와 다른 점은, 생산수단이 '무형'이라는 점이다. 토지, 공장과 같은 생산수단은 유형의 것이었고 때문에 한정적이었다. 서로 한정된 자원을 가지고 차지하기 위해 싸우기도 했다. 그러나 유튜브는 무형이다. 한계가 없다. 그렇기 때문에 전 세계로 생산수단의 영향력을 뻗칠 수가 있다.

3) 현대는 누가 생산수단의 소유자인가? 생산수단을 소유한 자들이 너무 많다. 특정하기가 어렵다. 눈에 보이기로는 재벌. CEO. 회장님 등등이 아닐까?

4) '나'는 소유자인가? 아니. 나는 아직 소유하지 못한 자이다. 그럼 나는 좌절해야 하는가? 나는 '아직' 소유하지 못했다는 말에 주목하자. 현대 사회의 생산 수단은 무형의 수단이 많아진 만큼, 예전보다는 생산 수단을 소유할 가능성은 커졌다. 그리고 새로운 생산수단을 만들어 낼 가능성도 커졌다. 자기 브랜딩의 시대. 라고 하지 않나? 자기 자신이 생산수단이자 생산물이 될 수도 있다. 아직은 어떤 생산수단을 만들어야 할지, 내가 할 수 있는지 고민이지만 어찌 되었든 '계속 노동해야 하는 노동자'로서 만의 삶은 벗어나야 한다는 것은 알겠다.

넓고 다양한 지식을 얻기 위해 책을 읽었는데, 미래의 먹거리를 향한 고민이 되어버렸다ㅎㅎ 생산수단의 힘을 계속 생각하면서 나는 어떤 생산수단을 소유할 것인지! 나는 어떤 것을 할 수 있는지! 계속 고민해가야겠다.

인프런 (자바 ORM 표준 JPA 프로그래밍 - 기본편, 김영한) 강의를 듣고 정리한 내용입니다

연관관계 매핑

1. 단방향과 양방향 : 매핑의 방향

1) 단방향 : Member 와 Order. Order 에서만 Member 를 조회하고 Member에서는 Order 조회 X.

Member : id, name ... Order : id, member_id(FK), ...

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;
    ...}

@Entity
@Table(name = "ORDERS")
public class Order {
    @Id @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "memberId", insertable = false, updatable = false)
    private Member member; 
    ...}

2) 양방향 : Member와 Order 서로 조회함.

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    // 연관관계 추가
    @OneToMany(mappedBy = "member")
    private List<Order> Orders = new ArrayList<Member>();

    ...}

@Entity
@Table(name = "ORDERS")
public class Order {
    @Id @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "memberId", insertable = false, updatable = false)
    private Member member; 
    ...}

• 연관관계의 주인이 외래키(FK) 등록/수정 관리. 주인이 아니면 조회만 가능
• FK가 있는 쪽이 주인(Order)이 되고, 주인이 아닌쪽(Member)는 mapped by 를 통해 어디로 매핑되어 있는지 정의해야 함

*주의 1 : 순수 객체 상태를 고려해서 항상 양쪽에서 값을 설정하도록 해야 함

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    @OneToMany(mappedBy = "member")
    private List<Order> Orders = new ArrayList<Member>();

    public void setOrder(Order order){
        order.setMember(this); //연관관계 주인에게 값 설정
        this.orders.add(order); //주인이 아닌 객체도 값 설정
    }
    ...
}

*주의 2 : 양방향 매핑시에 무한 루프를 조심 (toString(), lombok 등) Member 의 toString() -> Order 의 toString() -> Member 의 toString() ... 무한루프 발생

@Override
public String toString(){
    return "Member [ id= " +id+" , orders= "+orders ...; 
}

@Override
public String toString(){
    return "Order [ id= " +id+" , members= "+members ...; 
}

객체지향의 사실과 오해를 읽고 정리한 내용입니다. 제가 느낀대로 정리한 것이기에 책의 내용, 구성과 다소 다를 수 있습니다.

1장. 협력하는 객체 들의 공동체

1) 객체의 자율성

현실 세계를 모방하는 것이 아닌, 새로운 세계를 창조하는 것. 객체가 스스로 상태를 관리하는 점(자율성)이 현실세계와 다름 (요청에 의해 스스로 자신의 상태를 바꿈)

ex) (현실) 사람이 컵에 물을 따름 -> 컵의 물 높이가 변화됨 ( 0 -> 30cm, 수동적) (코드) 사람 객체가 물을 따랐다는 요청을 컵 객체에게 보냄 -> 컵 객체 스스로 물 높이를 변화시킴 ( 0 -> 30cm, 능동적, 자율성)

2) 역할, 책임 , 협력

기능을 만들어가는 과정은 역할, 책임, 협력을 통해 이뤄짐

협력을 하는 방법 : 객체사이의 요청과 응답

역할과 책임 : 협력하는 사람들이 그 안에서 차지하는 책임, 임무 (ex, 손님의 역할은 주문) 여러 객체가 동일한 역할 수행 가능함. 역할은 대체 가능하며, 각 객체는 책임을 수행하는 방법은 자율적으로 선택할 수 있고, 하나의 객체가 동시에 여러 역할을 수행할 수 있음

2장. 이상한 나라의 객체

1) 상태 : 객체는 상태를 가지며 상태는 변경가능

프로퍼티 : 객체의 상태를 구성하는 모든 특징. 변경되지 않음. 정적. 속성(단순한 값) + 링크(다른 객체 가리킴) 프로퍼티 값 : 시간이 흐름에 따라 변경됨. 동적 링크 : 객체와 객체 사이의 의미 있는 연결

2) 행동 : 상태를 변화시키는 것은 객체의 행동

행동이란 외부의 요청에 응답하기 위해 동작하고 반응하는 활동 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있음 행동은 외부에 가시적이어야 함

• 캡슐화 : 객체는 상태를 감추구 외부에 행동만 노출함. 외부에서 객체에 접근할 유일한 방법은 행동일뿐임. 상태를 잘 정의된 행동 집합 뒤로 캡슐화하는 것은 객체의 자율성을 높이고 협력을 단순하고 유연하게 만듦

3) 식별자 : 객체는 유일하게 식별 가능. 어떤 객체를 다른 객체와 구분하는 데 사용하는 객체의 프로퍼티

값 : 식별자 없음. 값의 상태는 변하지 않음. 불변 상태. 숫자, 날짜, 시간, 금액 등. 상태가 같으면 두 인스턴스 같은 것으로 판단함(동등성) 객체 : 시간에 따라 변경되는 상태. 행동을 통해 상태 변경함. 가변 상태. 식별자를 기반으로 객체가 같은지 판단(동일성)

나의 생각 정리

객체지향이란?

각 객체 들에게 역할, 책임을 부여하고 객체 간의 협력을 통해 필요한 기능을 구현해 가는 것 궁극적인 목표를 달성하기 위해, 목표를 작은 책임들로 세분화하고, 각각의 책임을 수행할 수 있는 역할을 가진 객체가 다른 객체간의 요청&응답 으로 소통하는 것

객체에 집중한다는 것 ≠ 클래스에 집중한다는 것

책에서는 객체지향 설계와 클래스 지향 설계는 다르다고 말함. 클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중해야 함. 클래스는 단지 구현 메커니즘일뿐 코드를 담는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 사고의 중심을 전환해야 함 --> 클래스는 객체를 만들어내는 틀이고 객체는 인스턴스. 객체의 역할은 각각 로직에 따라 다를 수 있다고 이해했음. 하지만 현실적으로 객체와 클래스를 분리해서 설계하고 개발한다는 것이 와닿지는 않았음

그 외...

그 외에도 알겠지만 모르겠고 모르겠지만 알겠고 하는 부분들이 있었는데 나중에 예시를 보면 더 잘 이해가 될 것 같다. 객체지향을 좀 더 명확히 정의내릴 수 있게 하고 생각해보게 한다는 점에서 좋았다.

인프런 (자바 ORM 표준 JPA 프로그래밍 - 기본편, 김영한) 강의를 듣고 정리한 내용입니다

객체와 테이블 매핑 : @Entity

• JPA 를 사용해 테이블과 매핑할 클래스에 사용
• @NoArgsConstructor 등 기본 생성자를 필수로 만들어야 함

  @NoArgsConstructor(access = AccessLevel.PROTECTED)
  @Entity(name = "user")
  public class Member {
  }
  // user 테이블과 Member 클래스 매핑

필드와 컬럼 매핑 : @Column, @Enumerated, @Lob, @Transient 등

@Entity(name = "user")
public class Member {
 @Id
 private Long id;

 @Column(name = "name")  //컬럼 매핑 name(DB 칼럼이름), insertable/updateable (등록, 변경 가능여부)
 private String username;

 @Enumerated(EnumType.STRING) // enum 타입 매핑. EnumType.STRING 으로 사용
 private Type userType;

 @Lob    //BLOB(byte[], java.sql. BLOB), CLOB(String, char[], java.sql.CLOB) 매핑. 속성 없음
 private String description;

 @Transient  //매핑 무시. DB와 관련 없음. 메모리상에서만 값을 갖고 싶을떄 사용함
 private String tempName;

}

기본키 매핑 : @Id, @GeneratedValue

@Id : 직접 할당시 사용

 @Id
 private Long id;

member.setId(4L);

@GeneratedValue : 자동생성

• 1) IDENTITY PK생성 데이터베이스에 위임 MySQL, PostgreSQL, SQL Server, DB2 등에서 사용 em.persist() 시점에 즉시 insert 쿼리 실행(보통 jpa는 커밋 시점에 insert 쿼리 실행하지만 이 경우는 예외)

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

• 2) SEQUENCE 데이터베이스 시퀀스 오브젝트 사용 오라클, PostgreSQL, DB2, H2 데이터베이스 등에서 사용 @SequenceGenerator 필요

  @Entity
  @SequenceGenerator(
    name = "MEMBER_SEQ_GENERATOR",
    sequenceName = "MEMBER_SEQ", //매핑할 데이터베이스 시퀀스 이름
    initialValue = 1, allocationSize = 1)
  public class Member {
    @Id
      @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "MEMBER_SEQ_GENERATOR")
    private Long id;
  }
  
  //위와 동일
  @Entity
  public class Member {
    @Id
    @SequenceGenerator(name = "SEQ", sequenceName = "MEMBER_SEQ", initialValue = 1, allocationSize = 1)
      @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "SEQ")
    private Long id;
  }
  

//allocationSize 시퀀스 한 번 호출에 증가하는 수

- 3) TABLE: 키 생성용 테이블을 따로 만들어 관리
모든 DB에서 사용 가능하나 성능 이슈 있음. 잘 사용 안하므로 패스
@TableGenerator 필요

- 4) AUTO: DB에 따라 1) 2) 3) 의 전략 자동 지정

인프런 (자바 ORM 표준 JPA 프로그래밍 - 기본편, 김영한) 강의를 듣고 정리한 내용입니다

1. JPA 구동방식

1) Persistence --> 설정정보 조회 (META-INF/persistence.xml)

<persistence-unit name="hello"> //EntityManagerFactory 인자값이 됨
        <properties>
            <!-- 필수 속성 -->
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="유저"/>
            <property name="javax.persistence.jdbc.password" value="비밀번호"/>
            <property name="javax.persistence.jdbc.url" value="url정보"/>
            <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
            <!-- 옵션 -->
            <property name="hibernate.show_sql" value="true"/>
            <property name="hibernate.format_sql" value="true"/>
            <property name="hibernate.use_sql_comments" value="true"/>
            <!--<property name="hibernate.hbm2ddl.auto" value="create" />-->
        </properties>
</persistence-unit>

2) Persistence --> EntityManagerFactory 생성(1개만)

//웹서버 올라오는 시점에 1개만 생성됨
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");

emf.close();

3) EntityManagerFactory --> EntityManager 여러개 생성

EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");

//고객의 요청마다, 트랜잭션 단위마다 생성됨. 모든 데이터 변경은 트랜잭션 안에서 실행함
EntityManager em = emf.createEntityManager();
//code 들이 들어감
em.close();

emf.close();

2. 영속성 컨텍스트

1) 엔티티의 생명주기

• 비영속 (new/transient) : 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태

  //Member 객체만 만들었음
  Member member = new Member();
  member.setId(1L);
  member.setName("helloA");

• 영속 (managed) : 영속성 컨텍스트에 관리되는 상태

  //Member 객체를 영속성 컨텍스트에 넣음
  em.persist(member);

• 준영속 (detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태

  //영속성 분리함
  em.detach(member);
  //영속성 컨텍스트 완전히 초기화
  em.clear();
  //영속성 컨텍스트 종료
  em.close()

• 삭제 (removed) : 삭제된 상태

  //찾아서 
  Member findMember = em.find(Member.class, 1L);
  //삭제함
  em.remove(findMember);

2) 플러시(Flush) : 쿼리 바로 날려주는 기능

-> 영속성 컨텍스트에 넣었다고 해서 바로 쿼리가 실행되지 않고 커밋 직전에 실행됨

Member member = new Member();
member.setId(2L);
member.setName("hello2");

System.out.println("=========== BEFORE =========");
em.persist(member);
System.out.println("=========== AFTER =========");

=========== BEFORE =========
=========== AFTER =========
Hibernate: 
    /* insert helloJpa.Member
        */ insert 
        into
            Member
            (name, id) 
        values
            (?, ?)

-> flush를 사용하면 영속성 컨텍스트의 변경내용을 바로 DB에 반영함

System.out.println("=========== BEFORE =========");
em.persist(member);
em.flush();
System.out.println("=========== AFTER =========")

=========== BEFORE =========
Hibernate: 
    /* insert helloJpa.Member
        */ insert 
        into
            Member
            (name, id) 
        values
            (?, ?)
=========== AFTER =========

• flush() 말고도 커밋시, JPQL 쿼리 실행시 플러시가 자동 호출됨

3) 영속성 컨텍스트의 이점

• 1차 캐시 : 영속성 컨텍스트에 있는 값은 DB를 조회하지 않고 바로 가져옴

  System.out.println("=========== BEFORE =========");
  em.persist(member); //영속화
  Member findMember = em.find(Member.class, 3L); //영속성 컨텍스트에서 가져옴
  System.out.println("이름 : "+findMember.getName());
  System.out.println("=========== AFTER =========");

  =========== BEFORE =========
  이름 : hello3
  =========== AFTER =========
  Hibernate: 
    /* insert helloJpa.Member
        */ insert 
        into
            Member
            (name, id) 
        values
            (?, ?)
  

- 동일성 보장
```java
Member findMember1 = em.find(Member.class, 4L);
Member findMember2 = em.find(Member.class, 4L);
System.out.println(findMember1 == findMember2); //true

• 트랜잭션 지원하는 쓰기 지연(flush, 커밋, JPQL쿼리 실행전까지 모은 영속성 컨텍스트의 SQL 실행)
• 변경 감지 -> 엔티티와 스냅샷을 비교해서 변경이 되면 update 쿼리 생성

  Member findMember1 = em.find(Member.class, 4L);
  findMember1.setName("hello~~!!!!");

        update
            Member 
        set
            name=? 
        where
            id=?

클래스의 구성요소 및 클래스간의 관계를 표한하는 대표적인 UML

UML (Unified Modeling Language)

도메인을 모델로 표현해주는 대표적인 모델링 언어 의사소통, 설계, 전체 시스템의 구조 및 클래스의 의존성 파악 등을 위해 사용됨

클래스 다이어그램의 클래스 표현하는 기본요소

1. 클래스

1) 접근제어자

+ : public
- : private
# : protected

2) 속성

접근제어자 이름:타입 = 기본값

ex) private String name = "";
--> - name : String = ""

3) 메소드

접근제어자 이름(파라미터 속성): 리턴값 {abstract : 추상메소드일 경우만}

ex) public String getName(String name) 
-> + getName(String) : String 

ex) public abstract String getName(String name) 
-> + getName(String) : String {abstract}

2. 스테레오 타입

UML에서 제공하는 기본요소 외의 추가적인 확장요소

<< interface >> 
<< abstract >>
<< component >>

3. 클래스 간의 관계

(출처 : https://www.nextree.co.kr/p6753/)

1) Generalization ( 일반화 ) : 상속 (실선, 비어있는 화살표)

public class Subject {
    private String code;
    private String name;

    public void study() {
        System.out.println("공부");
    }
}

public class English extends Subject {
    @Override
    public void study() {
        System.out.println("영어공부");
    }
}

2) Realization ( 실체화 ) : interface 실제로 구현 (점선, 비어있는 화살표)

public interface Subject {
    public void study();
}

public class English implements Subject {
    @Override
    public void study() {
        System.out.println("영어공부");
    }
}

3) Dependency ( 의존 ) : 어떤 클래스가 다른 클래스 참조. 메서드 내에서 다른 클래스의 객체를 생성하거나 사용, 리턴받아 사용하는 것 (점선, 화살표)

public class English {
    public Schedule createSchedule() {
        return new Schedule(); //create << create >> 으로 표현
    }
  // 그외에도 <<local>>, <<parameter>> 로도 사용 가능함
}

4) Association ( 연관 ) : 다른 객체의 참조 (양방향일 경우 실선만, 방향성이 있으면 화살표)

Aggregation ( 집합 ) : 연관의 집합관계를 나타내는 것. Collection이나 Array를 이용하는 관계. 코드상으로 분리하기 애매하므로 생략함 (실선, 빈다이아몬드)

1 : 1개의 표현
* : 0 ~ n 개의 표현
n...m : n 부터 m까지 연관관계를 맺음

public class English {
    public List<Schedule> scheduleList;
}

5) Composition ( 합성 ) : 강한 결합의 관계. 참조하는 클래스의 라이프 사이클이 종속적 (실선, 채워진 다이아몬드)

English 클래스가 사용하지 않는 경우가 발생했을때 Schedule도 참조가 불가능한 상태가 됨

참고 사이트

https://sabarada.tistory.com/72 https://www.nextree.co.kr/p6753/

Mybatis3 를 참고하여 정리하였습니다. 더 자세한 내용은 해당 내용을 확인하세요.

Mybatis 구성 요소 및 관련 파일

MyBatis configuration file 데이터베이스의 연결 대상, 매핑 파일의 경로, 마이바티스의 동작 설정 등을 자세하게 설명하는 파일

org.apache.ibatis.session. SqlSessionFactoryBuilder 마이바티스환경 설정 파일 읽고 SqlSessionFactory 생성

org.apache.ibatis.session. SqlSessionFactory SqlSession 생성하기 위한 요소

org.apache.ibatis.session. SqlSession SQL 실행 및 트랜잭션 제어를 위한 API를 제공하는 컴포넌트

Mapper interface 매핑 파일에 정의된 SQL 함수를 호출하는 인터페이스

Mapping file 실행할 SQL 문이 있는 파일

애플리케이션 시작시

(1) SqlSessionFactoryBuilder에 SqlSessionFactory 빌드하도록 요청

(2) SqlSessionFactoryBuilder는 SqlSessionFactory를 생성하기 위한 MyBatis 구성 파일을 읽음

(3) SqlSessionFactoryBuilder는 MyBatis 구성 파일의 정의를 기반으로 SqlSessionFactory를 생성

클라이언트 요청에 의해 수행

(4) 클라이언트가 애플리케이션에 대한 프로세스 요청

(5) 애플리케이션은 (SqlSessionFactoryBuilder를 사용하여 빌드된) SqlSessionFactory에서 SqlSession을 가져옴

(6) SqlSessionFactory는 SqlSession을 생성하고 이를 애플리케이션에 반환

(7) 애플리케이션은 SqlSession 에서 Mapper 인터페이스의 구현 개체를 가져옴

(8) 애플리케이션은 Mapper 인터페이스 메서드를 호출 (“Mapper interface mechanism” → Mapper interface 메커니즘에 대해 자세히 알고싶다면 여기로...)

(9) Mapper 인터페이스의 구현 객체는 SqlSession 메서드를 호출하고 SQL 실행을 요청

(10) SqlSession은 매핑 파일에서 실행할 SQL 가져와 실행

Mybatis SQL 실행 예제

@Mapper
public interface TestMapper {
    List<String> findNameById(String id);
}

<mapper namespace="~~(생략).TestMapper">
    <select id="findNameById"
            parameterType="String"
            resultType="String">
        select name from test where id = #{id}
    </select>
</mapper>

Guide to Guava Table 을 보며 정리한 내용입니다. 예제는 그대로 사용했으며, 자세한 내용은 링크를 확인하세요:)

Guava Table

• 행. 열, 셀값을 포함하는 테이블 구조의 컬렉션
• 행과 열은 순서가 지정된 키 쌍으로 작동
• DB의 테이블 형식으로 사용 가능함

1. Creating (4 가지 방법)

1) HashBasedTable

Table<String, String, Integer> universityCourseSeatTable = HashBasedTable.create();

2) TreeBasedTable : 정렬 사용시

Table<String, String, Integer> universityCourseSeatTable = TreeBasedTable.create();

3) ArrayTable : 행, 열 및 테이블 크기 고정시

List<String> universityRowTable = Lists.newArrayList("Mumbai", "Harvard");
List<String> courseColumnTables = Lists.newArrayList("Chemical", "IT", "Electrical");

Table<String, String, Integer> universityCourseSeatTable = ArrayTable.create(universityRowTable, courseColumnTables);

4) ImmutableTable : 불변의 Table 인스턴스

Table<String, String, Integer> universityCourseSeatTable 
= ImmutableTable.<String, String, Integer> builder().put("Mumbai", "Chemical", 120).build();

2. 사용방법

1) 검색

 universityCourseSeatTable.put("Mumbai", "Chemical", 120);

 int seatCount = universityCourseSeatTable.get("Mumbai", "Chemical"); //120

2) 항목 있는지 확인

universityCourseSeatTable.put("Mumbai", "Chemical", 120);

boolean entryIsPresent = universityCourseSeatTable.contains("Mumbai", "Chemical"); //true
boolean courseIsPresent = universityCourseSeatTable.containsColumn("IT"); //false
boolean universityIsPresent = universityCourseSeatTable.containsRow("Mumbai"); //true
boolean seatCountIsPresent = universityCourseSeatTable.containsValue(60); //false

3) 제거

universityCourseSeatTable.put("Mumbai", "Chemical", 120);

int seatCount = universityCourseSeatTable.remove("Mumbai", "Chemical"); //120

4) 행 기준으로 셀값 맵

universityCourseSeatTable.put("Mumbai", "IT", 60);
universityCourseSeatTable.put("Havard", "IT", 120);
universityCourseSeatTable.put("Mumbai", "Chemical", 120);

Map<String, Integer> universitySeatMap = universityCourseSeatTable.column("IT");
/*
IT 기준으로 맵으로 만들어짐
"Mumbai", 60
"Havard", 120
*/

Map<String, Map<String, Integer>> courseKeyUniversitySeatMap = universityCourseSeatTable.columnMap();
/* 행 기준으로 만들어짐
"IT", <"Mumbai", 60>
"IT", <"Havard", 120>
"Chemical", <"Mumbai",120>
*/

5) 열 기준으로 셀값 맵

universityCourseSeatTable.put("Mumbai", "IT", 60);
universityCourseSeatTable.put("Havard", "IT", 120);
universityCourseSeatTable.put("Mumbai", "Chemical", 120);

Map<String, Integer> courseSeatMap = universityCourseSeatTable.row("Mumbai");
/*
Mumbai 기준으로 만들어짐
"IT", 60
"Chemical", 120
*/

6) 키 가져오기

universityCourseSeatTable.put("Mumbai", "Chemical", 120);
universityCourseSeatTable.put("Mumbai", "IT", 60);
universityCourseSeatTable.put("Harvard", "Electrical", 60);
universityCourseSeatTable.put("Harvard", "IT", 120);

//행 키 : Mumbai , Harvard
Set<String> universitySet = universityCourseSeatTable.rowKeySet();

//열 키 : Chemical, IT, Electrical
Set<String> courseSet = universityCourseSeatTable.columnKeySet();

• Redux 를 더 쉽게 사용하기 위한 도구
• 기존 Redux의 여러 문제점을 보완해줌

Redux 의 문제점

1. 무수한 보일러플레이트 코드가 필요함. 액션 타입, 액션 생성 함수, 액션별 리듀서를 각각 정의 하는 방식

2. 리덕스 스토어 환경 설정 복잡함 상태관리를 위해 만들어야 하는 파일이 많고 복잡함

3. 패키지를 많이 추가해야 함

--> Redux Toolkit은 보일러플레이트 코드를 최소화하고 하나의 파일 안에 정의할 수 있도록 하였음

[ 기존 예시 ]

1. 액션 타입

   export type StudyState = {
   startStudyTime: number|null,
   studyTime: number|null,
   }
   export type StudyAction = ActionType<typeof actions>

2. 액션 생성 함수

   export const
   START_STUDY = 'study/START_STUDY',
   END_STUDY = 'study/END_STUDY'
   

export const startStudy = createAction(START_STUDY, action => (startStudyTime: number) => action(startStudyTime)) export const endStudy = createAction(END_STUDY, action => (studyTime: number) => action(studyTime))

3. 액션 리듀서
```react
//3-1. 초기화
const initialState: StudyState = {
  startStudyTime: null,
  studyTime: null,
}

export default createReducer<StudyState, StudyAction>(initialState, {
  [START_STUDY]: (state, action) => {
    const startStudyTime: number = action.payload

    return produce<StudyState>(state, draft => {
      draft.startStudyTime = startStudyTime
      draft.studyTime = null
    })
  },
  [END_STUDY]: (state) => {
  const studyTime: number = action.payload

    return produce<StudyState>(state, draft => {
      draft.studyTime = studyTime
      draft.startStudyTime = null
    })
  }
})

4. 스토어별 취합

   export { default } from './reducer';
   export * from './actions';
   export * from './types';

Redux Toolkit의 createSlice()

액션 타입, 액션 생성 함수, 액션별 리듀서, 취합 파일 등을 하나의 파일로 통합할 수 있게 함

• createSlice에 선언된 슬라이스 이름을 따라서 리듀서와 액션 생성자, 액션 타입 자동 생성
• 따로 createAction, createReducer를 작성할 필요 없음

//1. 액션 타입
export type StudyState = {
  startStudyTime: number|null,
  studyTime: number|null,
}

//3-1. 초기화
const initialState: StudyState = {
  startStudyTime: null,
  studyTime: null,
}


const studySlice = createSlice({
    name: 'study', // 2. 액션 생성 함수의 앞에 부분. 'study/START_STUDY' 의 study
    initialState,
    reducers: { //2+3. 액션 생성과 리듀서를 한번에 함수로 정의
        startStudy(state, action: PayloadAction<number>) {
            const startStudyTime: number = action.payload

            state.startStudyTime = startStudyTime
            state.studyTime = null
        },
        endStudy(state, action: PayloadAction<number>) {
            const studyTime: number = action.payload

            state.studyTime = studyTime
            state.startStudyTime = null
        }
    }
})

export default studySlice.reducer
export const { startStudy, endStudy } = studySlice.actions

그 외의 더 많은 리덕스 툴킷의 유용한 API 를 보고 싶다면, [Redux Toolkit (리덕스 툴킷)은 정말 천덕꾸러기일까?] 를 참고하세요:)

1. H2 데이터베이스 설치

https://www.h2database.com/html/main.html

윈도우일 경우 Windows Installer , 맥일 경우 All Platforms 선택

2. 압축 해제후, 해당 파일의 bin에서 터미널 열고 H2 실행

./h2.sh

잠깐!!! Permission denied 가 뜬다면?!

-bash: ./h2.sh: Permission denied

//아래순으로 입력해주세요
chmod 755 h2.sh
./h2.sh

3. H2 설정

connect 누르기

잠깐!!! 아래처럼 에러가 뜬다면?!

--> C:/Users/사용자명/test 파일이 없어서 생기는 문제! 사용자명 파일에 텍스트 파일을 만들고 이름을 test.mv.db 로 저장후 connect 누르기

-->그래도 안 됨... JDBC URL 을 바꿔보자. 밑에 나온 경로를 그대로 URL로 옮기기

==> 성공!

노마드 코더의 완전 새로운 리액트가 온다? 핵심정리 10분컷 을 보고 요약한 내용입니다.

1. React Suspense

v16~17 | code splitting with React.lazy(Client) v18 | Data fetching via compatible libraries, like Relay.(Client) Streaming server rendering(Server)

Suspense 없을때

로딩 체크하는 로직이 컴포넌트 내부에 있음

function Profile(){
    const {data: profile, isLoading } = useQuery("profile",fn);
    if(isLoading){ 
        return <Loader />;
        }

    return <dib>Hello {profile.name}! Welcome!</div>
}

Suspense 있을때

로딩 상태를 컴포넌트와 분리, Suspense 를 사용하면 로딩 state 잊어도 됨. 로딩 상태를 컴포넌트와 분리

function Profile(){
    const {data: profile} = useQuery("profile",fn);;
    return <div>Hello {profile.name}! Welcome!</div>
}

Loading state가 컴포넌트 외부로 빠짐. 로딩 로직이 밖으로 빠짐으로써 컴포넌트 흐름 파악이 훨씬 간결해짐

<Suspense fallback={<Loader /}>
    <Profile />
</Suspense>

2. Server Side Rendering

Client side rendering : 모든 것이 클라이언트쪽에서 일어남

• 서버 : 브라우저가 다운받을 JS 파일을 제공 브라우저 : 리액트 코드가 들어있는 JS 파일 실행함 리액트 : 유저가 볼 수 있는 모든 HTML 요소와 UI 렌더링
• 웹사이트에는 어떠한 콘텐츠나 UI가 없으며, JS가 브라우저에서 비활성화되거나 다운로드가 느려지면 유저는 빈 화면만 보게 됨

Server side rendering :

• 서버 : 유저에게 응답하기 전에, 서버에서 리액트를 실행 리액트 : ui를 렌더링하고 결과 HTMl 을 제공. 해당 html를 유저에게 제공 브라우저 : html 페이지만 갖고 있고 인터렉션은 없음
• 서버사이드가 클라이언트보다 복잡하지만 유저경험이 좋음

서버사이드의 문제!

서버에서 먼저 전체 어플리케이션을 렌더링하게 때문에 어느 한 컴포넌트가 로딩하는데 오래걸리면 백엔드에서 전체 렌더링하는 동안 유저는 빈화면을 볼 수 있음.

<App>
    <Header />
    <Posts />
</App>

해결! Suspense가 활성화된 서버사이드 렌더링

• Suspense로 post 컴포넌트를 감싸서 유저는 header를 볼 수 있음 서버 사이드에서 로딩을 끝낼 때, http 스트림을 사용해 리액트는 loader 컴포넌트의 html을 post 컴포넌트의 결과 html 로 대체함.
• suspense 덕분에 어플리케이션이 빠르게 렌더링할 수 있음 .

  <App>
    <Header />
    <Suspense fallback={<Loader />}>
        <Posts />
    </Suspense>
  </App>

  Suspense 덕분에 전체 애플리케이션을 한꺼번에 로드할 필요가 없음 아직 hydreate 안된 걸 유저가 선택하면 유저가 인터렉션하기 원하는 그 컴포넌트 hydrate 로딩을 먼저함

Server component

• 서버 컴포넌트는 백엔드에서만 존재하는 리액트js코드를 쓸 수 있음
• 파일명을 통해 미리 어느 컴포넌트가 브라우저가 렌더링할지 서버가 렌더링할지 선택가능
• 로딩이 빨라지고 ux도 엄청 향상됨 매우 무거운 패키지에 의존하는 컴포넌트가 있다면, 클라이언트 사이드 렌더링에서는 유저는 코드 그리고 해당 패키지를 다운로드해야하므로 로딩 속도도 오래걸리고 어플리케이션 사이즈 커짐 서버 컴포넌트로 전환하면 컴포넌트 렌더링은 서버에서 수행되고 렌더링의 결과값만 유저에게 스트리밍 됨.
• DB랑 직접적으로 커뮤니케이션 하는 리액트 컴포넌트가 생김. SQL 쿼리 수행 가능

인프런의 더자바, JAVA8 강의를 들으며 정리한 내용입니다.

어노테이션이 궁금하다면 여기부터 읽어보세요:) 어노테이션이란?

JAVA8 추가된 Annotation 변화

1. Annotation 을 타입 선언부에서도 사용할 수 있음

@Target({ElementType.TYPE_PARAMETER}) // 타입 변수에만 사용 @Target({ElementType.TYPE_USE}) // 타입 변수를 포함해서 모든 타입 선언부에 사용

TYPE_PARAMETER 사용예제

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE_PARAMETER})
public @interface Chicken {
}

public static <@Chicken C>/*타입파라미터*/ void print(C c/* 타입 */){
    System.out.println(c);
}

타입에 선언하려고 한다면?

TYPE_USE 사용예제

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE_USE})
public @interface Pizza {
}

public static <@Pizza C>/*타입파라미터*/ void println(@Pizza C c/* 타입 */){
    System.out.println(c);
}

2. Annotation 을 중복해서 사용할 수 있음

중복 예제

컨테이너 어노테이션은 중복 사용하려는 어노테이션의 @Retention, @Target 보다 같거나 더 넓어야 함

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE_USE})
public @interface PizzaContainer {
    Pizza[] value();
}

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE_USE})
@Repeatable(PizzaContainer.class) //컨테이너 추가
public @interface Pizza {
    String value();
}

@Pizza("고르곤졸라")
@Pizza("슈퍼슈프림")
public class Main {

public static void main(String[] args){
            Pizza[] pizzas = Main.class.getAnnotationsByType(Pizza.class);
            Arrays.stream(pizzas).forEach(c->{
                System.out.println(c.value());
            });
        // 고르존졸라, 슈퍼슈프림
        }
}

• 비즈니스 로직에 영향을 주지 않으면서 소스코드에 메타데이터(데이터에 대한 데이터)를 표현하는 방법
• 특정 소스를 어떤 용도로 쓸지, 어떤 역할을 줄지 결정할 수 있음
• AOP 관점

Annotation 만들기

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD})
public @interface ahreumAnnotation {
    //Element
    String value() default "Ahreum Annotation Test";
}

@Retention(RetentionPolicy.~) : 어느 시점까지 보유할지 결정

• @Retention(RetentionPolicy.RUNTIME): 런타임시 어노테이션 정보를 가져옴. 리플렉션 이용
• @Retention(RetentionPolicy.SOURCE) : 소스상에서만 유지. Compile 이후 삭제
• @Retention(RetentionPolicy.CLASS) : 리플렉션 이용해 어노테이션 정보를 얻을 수 없음. 바이트 코드 파일까지 정보 유지

@Target({ElementType.~}) : 적용대상

• ElementType.PACKAGE : 패키지 선언시
• ElementType.TYPE : 타입 선언시
• ElementType.CONSTRUCTOR : 생성자 선언시
• ElementType.FIELD : 멤버 변수 선언시
• ElementType.METHOD : 메소드 선언시
• ElementType.ANNOTATION_TYPE : 어노테이션 타입 선언시
• ElementType.LOCAL_VARIABLE : 지역 변수 선언시
• ElementType.PARAMETER : 매개 변수 선언시
• ElementType.TYPE_PARAMETER : 타입 변수에만 사용
• ElementType.TYPE_USE : 모든 타입 선언부에 사용

@Inherited : 자식 클래스가 어노테이션 상속 가능

@Repeatable : 반복적으로 어노테이션 선언 가능

사용 예제

public class AhreumDto {

    @ahreumAnnotation
    private String title; //디폴트값 들어감

    @ahreumAnnotation(value = "title2 번째")
    private String title2;

    public String getTitle(){
        return title;
    }
    public String getTitle2(){
        return title2;
    }
}

public static void main(String[] args) throws InstantiationException, IllegalAccessException {
        Field[] fields = AhreumDto.class.getDeclaredFields();
        AhreumDto instance = AhreumDto.class.newInstance();
        for(Field f : fields){
            System.out.println(f.getName()); //title, title2 (field 출력됨)
            f.setAccessible(true);
            f.set(instance,f.getAnnotation(ahreumAnnotation.class).value());
        }
        System.out.println(instance.getTitle()); // Ahreum Annotation Test
        System.out.println(instance.getTitle2()); // title2 번째
    }

인프런의 더자바, JAVA8 강의를 들으며 정리한 내용입니다.

Optional

• 값 한 개가 있을수도 있고 없을수도 있을때 사용함
• 주로 결과값이 NULL 가능성이 있을때 사용
• 리턴값으로만 쓰기를 권장
• Optional 은 또다른 Optional 로 감싸지 말기

Optional API

1. Optional 만들기 Optional.of() : null이 안나올때 사용 Optional.ofNullable() : null이 올수도 있을때 Optional.empty() : null을 담고 있는,비어있는 Optional 객체 받아올때 사용

2. Optional에 값이 있는지 없는지 확인하기 isPresent() isEmpty() (Java 11부터 제공)

   List<B_OnlineClass> classes1 = new ArrayList<>();
   classes1.add(new B_OnlineClass(1,"spring boot",true));
   classes1.add(new B_OnlineClass(2,"study with me",false));
   classes1.add(new B_OnlineClass(3,"JPA",true));
   

Optional optional = classes1.stream() .filter(oc -> oc.getTitle().startsWith("ss")) .findFirst();

boolean present = optional.isPresent(); System.out.println(present); //false

3. Optional에 있는 값 가져오기
get() : 비어있을때는 NoSuchElementException

4. Optional에 값이 있는 경우에 그 값을 가지고 ~~를 하라.
ifPresent(Consumer)
```java
optional.ifPresent(oc -> System.out.println(oc.getTitle()));

5. 값이 있으면 가져오고 없으면~ orElse(T) : 없으면 실행 orElseGet(Supplier) orElseThrow() : 없으면 에러 던지기

   B_OnlineClass b_onlineClass = optional.orElse(new B_OnlineClass(6,"sss",true));
   System.out.println(b_onlineClass.getTitle()); //sss
   

B_OnlineClass b_onlineClass3 = optional.orElseThrow(IllegalStateException::new); // Exception in thread "main" java.lang.IllegalStateException System.out.println(b_onlineClass3.getTitle());

```

6. Optional 값 제어하기 Optional filter(Predicate) : 값 걸러내기 Optional map(Function) : 값 변환하기 Optional flatMap(Function): Optional 안에 들어있는 인스턴스가 Optional인 경우에 사용하면 편리

인프런의 더자바, JAVA8 강의를 들으며 정리한 내용입니다.

Stream

• 스트림으로 처리하는 데이터는 오직 한번만 처리
• 스트림이 처리하는 원본의 데이터는 변경하지 않음
• 중개 오퍼레이션은 근본적으로 lazy

  List<String> names = new ArrayList<>();
  names.add("ahreum"); names.add("jenny"); names.add("nami");
  

Stream