전체 글 74

[Effective Java 3/E] 4장 클래스와 인터페이스

📋 목차. 4. 클래스와 인터페이스 .아이템 15 - 클래스와 멤버의 접근 권한을 최소화하라. .아이템 16 - public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 .아이템 17 - 변경 가능성을 최소화하라 .아이템 17 - 변경 가능성을 최소화하라 .아이템 18 - 상속보다는 컴포지션을 사용하라 .아이템 19 - 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 .아이템 20 - 추상 클래스보다는 인터페이스를 우선하라 .아이템 21 - 인터페이스는 구현하는 쪽을 생각해 설계하라 .아이템 22 - 인터페이스는 타입을 정의하는 용도로만 사용하라 .아이템 23 - 태그 달린 클래스보다는 클래스 계층구조를 활용하라 .아이템 24 - 멤버 클래스는 되도록 static으로..

[Effective Java 3/E] 3장 모든 객체의 공통 메서드

📋 목차. 1. 챕터 .아이템 10 - equals는 일반 규약을 지켜 재정의 하라 .아이템 11 - equals를 재정의하려거든 hashCode도 재정의하라 .아이템 12 - toString을 항상 재정의하라 .아이템 13 - clone 재정의는 주의해서 진행하라 .아이템 14 - Comparable을 구현할지 고려하라. ✔️ 내용. 3. 모든 객체의 공통 메서드 Object는 객체를 만들 수 있는 구체 클래스이지만. 기본적으로는 상속해서 사용하도록 설계되었다. Object에서final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 재정의를 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 명확히 정의되어 있다. 이번 장에서는 fina..

[Effective Java 3/E] 2장 객체 생성과 파괴

📋 목차. 2. 객체 생성과 파괴 .아이템 1 - 생성자 대신 정적 팩터리 메서드를 고려하라. .아이템 2 - 생성자에 매개변수가 많다면 빌더를 고려하라. .아이템 3 - private 생성자나 열거 타입으로 싱글턴임을 보증하라. .아이템 4 - 인스턴스화를 막으려거든 private 생성자를 사용하라 .아이템 5 - 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 .아이템 6 - 불필요한 객체 생성을 피하라 .아이템 7 - 다 쓴 객체 참조를 해제하라. .아이템 8 - finalizer와 cleaner 사용을 피하라 .아이템 9 - try-finally 보다는 try-with-resources를 사용하라. ✔️ 내용. 2. 객체 생성과 파괴 학습 내용 1. 객체를 만들어야 할 때와 만들지 말아야 할..

[Effective Java 3/E] 1장 들어가기

📋 목차. 1. 들어가기 ✔️ 내용. 1. 들어가기 이 책의 규칙 대부분은 핵심적인 원칙 몇 개에서 파생된다. 1. 명료성 2. 단순성 3. 컴포넌트는 사용자를 놀라게 하는 동작을 해서는 절대 안 된다 - 정해진 동작 or 예측 가능한 동작만 수행 4. 컴포넌트는 가능한 한 작되, 그렇다고 너무 작아서는 안 된다. (*컴포넌트 : 개별 메서드 부터 여러 패키지로 이뤄진 복잡한 프레임워크까지 재샤용 가능한 모든 요소) 5. 코드는 복사가 아니라 재사용 되어야 한다. 6. 컴포넌트 사이 의존성을 최소화 한다. 7. 오류는 생성 되자마자 최대한 빨리(되도록 컴파일) 잡아야 한다. 위의 규칙이 100% 옳을 수 없지만 어겨야 할 경우 합당한 이유가 있어야 한다.

[객체지향의 사실과 오해 - 2] 이상한 나라의 객체

📋 목차. 2. 이상한 나라의 객체 .객체지향과 인지 능력 .객체, 그리고 이상한 나라 .객체, 그리고 소프트웨어 나라 .기계로서의 객체 .행동이 상태를 결정한다 .은유와 객체 ✔️ 내용. 2. 이상한 나라의 객체 객체지향 패러다임은 지식을 추상화하고 추상화한 지식을 객체 안에 캡슐화함으로써 실세계 문제에 내재되니 복잡성을 관리하려고 한다. 객체를 발견하고 창조하는 것은 지식과 행동을 구조화하는 문제다. - 레베카 워프스브록 .객체지향과 인지 능력 - 인간이 직접적으로 지각할 수 있는 대부분의 객체는 물리적인 경계를 지닌 구체적인 사물이다. .객체, 그리고 이상한 나라 - 객체의 특징 1. 객체는 상태를 가지며 상태는 변경 가능하다. 2. 객체의 상태를 변경시키는 것은 객체의 행동이다. 2-1) 행동의 ..

Study 2023.01.17

[객체지향의 사실과 오해 - 1] 협력하는 객체들의 공동체

📋 목차. 1. 협력하는 객체들의 공동체 .협력하는 사람들 .역할, 책임, 협력 .협력 속에 사는 객체 .객체지향의 본질 ✔️ 내용. 1. 협력하는 객체들의 공동체 시너지를 생각하라, 전체는 부분의 합보다 크다. - 스티븐 코비 .협력하는 사람들 - 객체지향의 목표는 실세계를 모방하는 것이 아니다. 오히려 새로운 세계를 창조하는 것이다. - 협력에는 특정한 역할을 맡고 역할에 적합한 책임을 수행한다 1. 여러 사람이 동일한 역할을 수행할 수 있다. 2. 역할은 대체 가능성을 의미한다. 3. 책임을 수행하는 방법은 자율적으로 선택할 수 있다. 4. 한 사람이 동시에 여러 역할을 수행할 수 있다. .역할, 책임, 협력 - 객체지향 설계라는 예술은 적절한 객체에게 적절한 책임을 할당하는 것에서 시작된다. 책임..

Study 2023.01.17

[객체지향의 사실과 오해 - 0] 계획

❓ 책 정보. 저자 : 조영호 『객체지향의 사실과 오해』는 객체지향이란 무엇인가라는 원론적면서도 다소 위험한 질문에 답하기 위해 쓰여진 책이다. 안타깝게도 많은 사람들이 객체지향의 본질을 오해하고 있다. 가장 널리 퍼져있는 오해는 클래스가 객체지향 프로그래밍의 중심이라는 것이다. 객체지향으로 향하는 첫 걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. ✏️ 선정 이유. - 객체지향이란 무엇인가에 대해 알고 싶어서 - 좋은 설계에 대해 관심을 가지게 되어서 📋 진행 방식. - 📝 계획. - 2022.01.17 ~ 2022.01.31 (2주) 👨‍👨‍👦‍👦 인원. - wony

Study 2023.01.17

[Server] Cannot allocate memory

✏️ Info. - AWS EC2 하나에 3개의 Java Application 이 가동 중 - 인스턴스 유형 : t3.small (https://aws.amazon.com/ko/ec2/instance-types/t3/) - 사용량이 많아지자 Application 이 계속 다운되는 현상 발생 - Swap 메모리 설정으로 해결 - 부족한 Ram Memory 를 HDD로 대체 📋 List. 1. JVM 모니터링 - JPS 명령어로 확인 2. swap 설정 1. swap 생성 2. swap 파일 생성 3. swap 확인 ✔️ Content. 1. JVM 모니터링 이슈 확인 중 jps(Java Virtural Machine Process Status Tool , JVM 프로세스 상태 확인 툴) 라는 명령어를 찾음..

Linux 2022.10.05

[Study][함께자라기 - 1] 3. 애자일

📋 목차. 3. 애자일 .애자일의 씨앗 .애자일 도입 성공 요인 분석 .당신이 조직에 새 방법론이 먹히지 않는 이유 .애자일을 애자일스럽게 도입하기. ✔️ 내용. 3. 애자일 애자일은 불확실성이 클 때 우리가 어떻게 해야 하는지를 고민한 결과물이다. 좀더 짧은 주기로 더 일찍 부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 일찍 피드백을 받은 것으로 정리할 수 있다. 앞서 배운 '함께(협력)' 과 '자라기(학습)'가 이 애자일의 핵심이다. 불확실성이 큰 상황에서 좋은 대응 전략이다. 이 장에서는 애자일을 좀 더 들여다본다. .애자일의 씨앗 고객에게 매일 가치를 전하라. 애자일의 씨앗을 한문장으로 압축한 것이다. 각각의 단어의 내용은 다음과 같다. - 고객에게 - 우리의 진짜 고객은 누구인가?..

[Study][함께자라기 - 1] 2. 함께

📋 목차. 2. 함께 .소프트웨어 관리자의 개선 우선수위 .협력을 통한 추상화 .신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가 .하향식 접근의 함정 .전문가팀이 실패하는 이유 .구글이 밝힌 탁월한 팀의 비밀 .쾌속 학습팀 .프로젝트 확률론 ✔️ 내용. 2. 함께 스터디를 진행할 때면 각각 파트를 분리하고 후에 합쳐서 보게 되는데 속을 들여다보면 협력은 거의 없다고 볼 수 있다. 이 장에서는 협력 방법을 배우고 수련하는 파트이다. .소프트웨어 관리자의 개선 우선수위 조엘 테스트라는 것으로 '개발팀 평가 테스트'가 다음과 같이 있다. 1. 소스 컨트롤을 사용하는가? 2. 한 번에 빌드를 만들어낼 수 있는가? 3. 일일 빌드를 만드는가? 4. 버그 데이터베이스를 가지고 있는가? 5. 새로운 코드를 작성하기 전에 ..