객체 ⇒ 물리적인 경계를 지닌 구체적인 사물. (추상적인 사물까지도 사람들은 객체로 인식할 수 있다.) ex) 주문, 계좌 이체 물리적인 실체는 존재하지 않더라도 인간이 쉽게 구분하고 하나의 단위로 인지할 수 있는 개념적인 객체의 일종이다. 객체지향 패러다임의 목적 : 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것 객체, 그리고 소프트웨어 나라 객체의 다양한 특성을 효과적으로 설명하기 위해서는 객체를 상태(state), 행동(behavior), 식별자(identity)를 지닌 실체로 보는 것이 가장 효과적이다. 상태(state) 상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인..
분류 전체보기
본 내용은 객체지향의 사실과 오해라는 책 내용을 정리한 것이며, 자세한 내용은 책을 참고하시길.. 기능을 구현하기 위해 협력하는 객체들 손님 → 캐시어 → 바리스타 커피를 주문하는 과정은 객체지향의 핵심적이고 중요한 개념을 거의 대부분 포함하고 있다. 사람이라는 단어를 객체 손님, 캐시어, 바리스타 에이전트의 요청을 메시지 손님 → 캐시어 : 주문을 요청 캐시어 → 바리스타 : 커피제조를 요청 요청을 처리하는 방법을 메서드 캐시어 : 주문을 받은 후 바리스타에게 커피제조를 요청한다. 바리스타 : 커피제조를 한다. 역할과 책임을 수행하며 협력하는 객체들 사람들은 커피 주문과 같은 특정한 목표를 이루기 위해 서로 협력한다. 실세계 : 협력의 핵심은 특정한 책임을 수행하는 역할들 간의 연쇄적인 요청과 응답을 ..
클라이언트가 클래스의 인스턴스를 얻는 방법 중 한가지로 생성자와 별도로 정적 팩터리 메서드(static factory method)를 제공하는 방법이 있다. (그 클래스를 반환하는 단순한 정적 메서드) boolean 값을 받아 Boolean 객체 참조로 변환해 준다. public static Boolean valueOf(boolean b){ return b ? Boolean.TRUE : Boolean.FALSE; } 정적 팩터리를 사용했을 때 생성자 보다 좋은점과 나쁜점을 알아보자. 장점 첫 번째, 이름을 가질 수 있다. 정적 팩터리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다. BigInteger (int bitLength, int certainty, Random rnd) - 생성자 ..
많은 클래스가 하나 이상의 자원에 의존한다. 가령 맞춤법 검사기는 사전(dictionary)에 의존하는데, 이런 클래스를 정적 유틸리티 클래스로 구현한 모습을 드물지 않게 볼 수 있다. 정적 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다. public class SpellChecker { private static final Lexicon dictionary = ...; private SpellChecker() {} // 객체 생성 방지 public static boolean isValid(String word){ ... } public static List suggestions(String type) { ... } } 싱글턴을 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다. pub..
자바 8전에는 메서드가 특정 조건에서 값을 반환할 수 없을 때 취할 수 있는 선택지는 두가지가 존재했다. 예외를 던진다. null을 반환한다. 하지만 두가지 모두 허점이 존재하게 되는데, 예외는 진짜 예외적인 상황에서만 사용해야 하며, 예외를 생성할 때 스택 추적 전체를 캡처하므로 비용도 만만치 않다. null을 반환하면 이런 문제가 생기지는 않지만, 메서드를 호출 하는 쪽에서 별도의 null 처리 코드를 추가해야하는 문제가 발생한다. 자바가 8버전으로 올라가면서 또 하나의 선택지가 생겼는데 바로 Optional를 사용하는 것이다. Optional은 null이 아닌 T 타입 참조를 하나 담거나, 혹은 아무것도 담지 않을 수 있다. 보통 T를 반환해야 하지만 특정 조건에서는 아무것도 반환하지 않아야 할 때..
메서드 이름을 신중히 짓자 항상 표준 명명 규칙을 따라야 한다. 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 그다음 목표는 개발자 커뮤니티에서 널리 받아들여지는 이름 사용(긴 이름은 피하자!) 편의 메서드를 너무 많이 만들지 말자 모든 메서드는 각각 자신의 소임을 다해야 한다. 메서드가 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다. (인터페이스도 마찬가지) 매개변수 목록은 짧게 유지하자 매개변수는 4개 이하가 좋다. 일단 4개가 넘어가면 매개변수를 전부 기억하기가 쉽지 않다. 같은 타입의 매개변수 여러개가 연달아 나오는 경우는 특히 해롭다. 사용자가 매개변수 순서를 기억하기 어려울뿐더러, 실수로 순서를 바꿔 입력해도 그대로 컴파일되고 실행..
자바개발자라면 한번씩 필수로 알아두어야 하는 부분이다. (Naming Rule, Naming Convention 이라고도 한다.) 자바의 명명 규칙은 크게 철자 와 문법 두 범주로 나뉜다. 철자 규칙 은 패키지, 클래스, 메서드, 필드 타입 변수의 이름을 다룬다. 이 규칙들은 특별한 이유가 없는 한 반드시 따라야 한다. 철자 규칙 패키지(package) 패키지와 모듈이름은 각 요소를 점(.)으로 구분하여 계층적으로 짓는다. 요소들은 모두 소문자 알파벳 혹은 (드물게)숫자로 이뤄진다. 조직 바깥에서도 사용될 패키지라면 조직의 인터넷 도메인 이름을 역순으로 사용한다. (edu.cmu, com.google) 패키지 이름은 나머지 해당 패키지를 설명하는 하나 이상의 요소로 이뤄진다. (일반적으로 8자 이하의 짧..
우리는 "오류는 가능한 한 빨리 (발생한 곳에서) 잡아야한다" 는 원칙을 지키기위해 노력해야한다. 오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워진다. 메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다. 매개변수 검사를 제대로 하지 못하였을 때 발생하는 문제가 몇 가지 있는데 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다. 더 나쁜 상황은 메서드가 잘 수행되지만 잘못된 결과를 반환할 때이며, 더 나쁜 상황은 메서드는 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 때다. public..
collect()메소드는 단순히 요소를 수집하는 기능 외 컬렉션의 요소들을 그룹핑해서 Map객체를 생성하는 기능도 제공한다. Collectors의 groupingBy() 또는 groupingByConcurrent()가 리턴하는 Collector를 매개값으로 대입하면 사용할 수 있다. groupingBy()는 Map객체를 리턴하며, groupingByConcurrent는 ConcurrentMap을 리턴한다. Collectors의 static method // With a classification function as the method parameter: // T를 K로 매핑하고, K키에 저장된 List에 T를 저장한 Map 생성 static Collector groupingBy(Function
private final List cheesesInStock = ...; /** * @return 매장 안의 모든 치즈 목록을 반환한다. * 단, 재고가 하나도 없다면 null을 반환한다. */ public List getCheese(){ return cheesesInStock.isEmpty() ? null : new ArrayList(cheesesInStock); } 위의 코드의 문제점은 null을 반환한다는 것이다. 재고가 없다고 해서 특별히 취급할 이유는 없는대도 말이다.. 만약에 재고가 없을 경우 null을 반환하는 것을 고집한다면, 이 메소드를 사용하는 모든 클라이언트는 아래와 같은 방어 코드를 넣어줘야 한다. List cheeses = shop.getCheese(); if(cheeses != ..
