고오급 개발자가 되는길

유일하게 변하지 않는 것은 모든 것이 변한다는 사실 뿐이다 - 헤라클레이토스 위와 같은 인용문구를 통해 애플리케이션을 개발할때 신경써야 하는 부분은 애플리케이션을 개발함에 있어 사용자의 요구사항은 언제든지 변할 수 있고 그 변화에 대응할 수 있도록 객체지향적 설계를 해야 한다 라는 것입니다. 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하여 객체지향 설계를 해야 합니다. 기능 설계 대 구조 설계 기능 설계 - 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞추어 설계 하는것 - 사용자에게 제공할 기능 구조 설계 - 제품의 형태가 어떠해야 하는지에 대해 초점을 맞추어 설계 하는것 - 기능을 담을 안정적인 구조 설계는 기능, 구조 설계 이 두가지를 조화롭게 이루도록 설계를..

자율적인 책임 - 자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체이다 - 객체가 자율적이기 위해서는 객체에게 할당되는 책임의 수준 역시 자율적이어야 한다. EX) 앨리스 이야기에서 왕이 모자장수에게 증언을 요청하면 모자장수는 어떠한 방법을 사용하던 상관없이 증언이라는 책임만 수행하면 된다 너무 추상적인 책임 - 너무 포괄적이고 추상적인 책임을 선택하는 것은 협력의 의도를 파악하게 더 어렵게 할 수 있다 - 협력에 참여하는 의도를 명확하게 설명할 수 있는 수준 안에서 추상적이여야 한다. EX) 재판에서 설명하다 라는 책임은 애매하게 들릴 수 있다. 증언하다라는 책임이 협력의 의도를 뚜렷하게 표현할 수 있다. '어떻게'가 아니라 '무엇'을 - 자율적인 책임의 특징은 ..

협력 - 협력은 다수의 요청과 응답으로 구성되며 전체적으로 협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성된다. - 객체들간의 요청과 응답으로 협력 관계를 이루어 각 객체가 수행할 책임을 정의한다. 책임 - 어떤 요청에 대한 응답이나, 적절한 행동을 할 의무가 있다는 것임을 나타내는것이 책임이다. - 책임은 객체에 의해 정의되는 응집도 있는 행위의 집합, 무엇을 할 수 있는가에 대한 초점으로 맞춰야 한다. - 책임은 객체의 공용 인터페이스 (public interface)를 구성한다. 책임의 분류 1. 하는것 (Doing) - 다른 객체에게 요청을 보내어 다른 객체가 행동을 시작하게 하는것 2. 아는것 (Knowing) - 다른 객체에 대한 정보를 알고 있는 것 EX) 토끼가 목격자가 모자 장수라는..

컴퓨터를 조작하는 것이 추상화를 구축하고, 조작하고, 추론하는것에 관한 모든 것 이라는것을 깨닫고 나면 컴퓨터 프로그래밍을 작성하기 위한 중요한 전제 조건은 추상화를 정확하게 다루는 능력이라는 것이 명확해 진다 - 키스 데블린 기존의 지형과 위치를 고려하여 나온 복잡한 지하철 노선도는 단순하고 직관적으로 역 간의 네트워크를 표현한 지하철 노선도가 나옴으로써 복잡하게 이해되고 보기 어렵던 노선도는 쉽게 파악되며 사용되어졌습니다. 추상화도 이 처럼 이해하기 쉽고 단순하며 목적에 부합하는 수준으로 설정하여 개발자에게 복잡성을 극복해 낼 수 있습니다. 추상화를 통한 복잡성 극복 - 위의 지하철 노선도 사례에서 봤을때 중요한 점은 역의 위치가 중요한것이 아니라 역과 역 사이의 연결 관계가 중요했던 것입니다. 그래..

객체지향 패러다임은 지식을 추상화하고 추상화한 지식을 객체 안에 캡슐화함으로써 실세계 문제에 내재된 복잡성을 관리한다. 해당 챕터에서는 앨리스 이야기를 기준으로 객체의 패러다임을 설명하고 있습니다. 앨리스는 이야기 중 작은 문을 통과해야하는데 문을 통과하려면 키가 작아야 통과를 할 수 있었는데, 음료를 마시거나, 부채질을 하거나 행동을 통하여 키를 줄이거나 늘릴 수 있습니다. 이러한 행동을 객체지향의 패러다임으로 보았을 때, 앨리스의 키를 변화 시키는 것은 앨리스의 행동(음료를 마시거나 부채질을 함) 이며, 앨리서의 행동에 따라 앨리스의 상태(키) 가 변하게 된다. 앨리스가 한 행동의 결과는 앨리스의 상태의 의존적이다, 음료를 마시거나, 부채질을 함으로써 키가 변하기 때문이다. 하지만 행동 간에 순서도 ..

많은 사람들이 객체지향이란 실세계를 직접적이고 직관적으로 모델링 할 수 있는 패러다임이라고 생각한다. 하지만 실제 세계의 방화벽은 화재의 확산을 막아주고, 소프트웨어의 방화벽은 네트워크 침입을 막는 용도로 사용된다. 이런 예시와 같이 의미적 거리 만큼이나 소프트웨어 객체와 실세계 사물이 존재하는 연관성은 희미할 수 있다. 실제로 애플리케이션을 개발하면서 객체에 직접적으로 대응되는 실세계의 사물을 발견할 확률은 그다지 높지 않다. 이러한 상황들을 봤을떄 객체지향의 목표는 실세계를 모방하는 것이 아니라, 오히려 새로운 세계를 창조하는 것이다. 하지만 실세계의 모방은 객체지향을 이해하고 학습하는데에는 효과적이다. 객체지향 이해를 위한 실세계 모방 커피 주문 과정에서의 역할과 책임 1. 손님 - 커피를 주문한..

자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원들이 많은데, 자원을 닫기 위해서는 try-finally 보다 try-with-resources를 사용하여 닫아야 한다. -> 자원이 둘 이상이면 try-finally 방식은 너무 지저분하다 -> finally 구문에서도 예외가 발생할 수 있고 이전에 try 구문에서도 예외가 발생할 수 있으므로 나중에 나온 예외가 이전 예외를 덮어버려서 어떠한 예외에서 에러가 발생했는지 파악하기 어렵다. -> try-with-resources를 사용할 경우 { } 안에 있는 예외만 발생하게 되어 예외를 확실히 알 수 있다. 전통적인 자원 닫힘 보장 수단 - try-finally - 예외가 발생하거나 메서드에서 반환되는 경우를 포함 try-with-re..

자바 제공 객체 소멸자 1. finailzer 2. cleaner 위 두개의 객체 소멸자 사용 시 인스턴스의 자원 회수가 제멋대로 지연될 수 있다. 상태를 영구적으로 수정하는 작업에서는 절대 finalizer나 cleaner에 의존해서는 안된다. 객체 소멸자 대체 방법 - AutoCloseable 구현 해주고, 클라이언트에서 인스턴스를 다 쓰고 나면 close 메서드를 호출 - 일반적으로 예외가 발생해도 제대로 종료되도록 try-with-resources 사용 finailzer과 cleaner 활용 방법 1. 소유자가 close 메서드를 호출하지 않는 것에 대비한 안전망 역할 - 두 객체 소멸자가 호출 된다는 보장은 없지만, 클라이언트가 하지 않은 자원 회수를 늦게라도 해주는 안정망 역할 2. 네이티브 ..

가비지 컬렉션 (GC) - 다 쓴 객체(사용하지 않는 객체)를 알아서 회수해 가는 자바 메모리 관리 기능 가비지 컬렉션이 객체를 회수하지 못하는 경우 - 참조된 객체가 하나라도 있다면 해당 객체 뿐만 아니라 그 객체가 참조하는 모든 객체는 회수 될 수 없다 그래서 단 몇개의 객체가 매우 많은 객체를 회수하지 못하게 할 수 있고 잠재적으로 성능에 악영향을 줄 수 있다. 해결방안 1. 해당 참조를 다 사용하였을 떄 null 처리(참조 해제) 하면 된다. - 프로그래머는 비활성 영역이 되는 순간 null 처리를 해서 해당 객체는 더이상 쓰이지 않을 것임을 가비지 컬렉션에 알려야 한다. -> 실수로 null 처리한 참조를 사용하게 된다면 프로그램은 NullPointerException 예외를 발생시켜 종료된다...

똑같은 기능의 객체 생성 - 똑같은 기능의 객체를 매번 생성하기 보다는 객체 하나를 재사용 하는 편이 나은 경우가 많다. EX) String s = new String("lee"); -> 실행될 떄마다 String 인스턴스를 새로 만든다. 단순 lee라는 문자열을 반환하는 것임에도 불구하고 불필요한 인스턴스 생성이 일어남 String s = "lee"; - 새로운 인스턴스를 매번 만드는 대신 하나의 String 인스턴스를 사용한다. 생성비용이 비싼 객체 - 반복이 필요하다면 캐싱하여 재사용 권장 - 객체 생성 비용이 비싼 객체의 인스턴스를 사용하는 클래스의 초기화 과정에서 직접 생성하여 캐싱함 private static final Pattern ROMAN = Pattern.compile("정규식") st..