전체 글

예외처리(Exception Handling) - (1)

자바에서는 실행 시(runtime) 발생할 수 있는 프로그램 오류를 '에러(Error)'와 '예외(Exception)'로 구분한다. 에러는 메모리 부족(OutOfMemoryError)이나 스택오버플로우(StackOverflowError)와 같이 일단 발생하면 복구할 수 없는 심각한 오류이고, 예외는 발생하더라도 수습될 수 있는 비교적 덜 심각한 것이다. 에러는 프로그램 코드에 의해서 수습될 수 없고 예외는 수습될 수 있으므로, 예외 처리(Exception Handling)를 통해 해당 상황을 인식하고 대처하도록 한다. 1. 예외 클래스의 분류 🎹 예외 클래스의 계층 구조는 크게 3가지로 나누어 볼 수 있다. 왼쪽에 있는 Error, 파란색으로 표시된 Checked Exception 계열, 주황색으로 표시..

객체지향의 사실과 오해(2)

4장. 역할, 책임, 협력 🚢 책임 책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소이다. 객체지향 설계의 예술은 적절한 객체에게 적절한 책임을 할당하는 데 있다. 설계를 시작하는 초반에는 어떤 객체가 어떤 책임을 가지고 어떤 방식으로 서로 협력해야 하는지에 대한 개요를 아는 것만으로도 충분하다. 책임과 협력의 구조가 자리를 잡기 전까지는 책임을 구현하는 방법에 대한 고민을 잠시 뒤로 미뤄두자. 역할 어떤 객체가 수행하는 책임의 집합은 객체가 협력 안에서 수행하는 역할을 암시한다. 역할은 재사용 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소이다. 역할의 개념을 사용하면 유사한 협력을 추상화할 수 있다. 그리고 다양한 객체들이 협력에 참여할 수 있기 때문에 협력이 좀 더 유연해지며 다양..

객체지향의 사실과 오해(1)

역할, 책임, 협력 너무나도 읽어보고 싶었던 책이다. 물론 책 자체가 유명해서 읽어보고 싶기도 했지만, 여기서 나오는 이상한 나라의 앨리스 이야기가 특히 궁금하였다. 친구들이랑 얘기할 때 또는 강의를 들을 때 객체지향의 사실과 오해의 '이상한 나라의 앨리스'가 자주 등장해 왔기 때문이다. 이 책의 가장 큰 장점을 하나 정한다면 비유다. '커피 공화국의 아침', '이상한 나라의 앨리스', '지하철 노선도' 등 다양한 비유를 통해 개념들을 이해하기 쉽게 전달한다. 이 장점을 굳이 단점으로 본다면, 비유로 인해 구현 코드가 거의 나오지 않게 된다. 그래서 혹시나 구현 코드까지 기대했던 사람들은 여기서 개념을 확실히 잡고 다른 책을 읽어보면 좋을 거 같다. (물론 나도 객체지향에 관련해서 다른 책들을 추가적으로..

클린 코드(Clean Code) - 14장, 15장, 16장, 17장

14장. 점진적인 개선 📌 나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다. 나쁜 일정은 다시 짜면 된다. 나쁜 요구사항은 다시 정의하면 된다. 나쁜 팀 역학은 복구하면 된다. 하지만 나쁜 코드는 썩어 문드러진다. 점점 무게가 늘어나 팀의 발목을 잡는다. 속도가 점점 느려지다 못해 기어가기도 한다. 너무 서두르다가 이후로 영원히 자신들의 운명을 지배할 악성 코드라는 굴레를 짊어진다. 물론 나쁜 코드도 깨끗한 코드로 개선할 수 있다. 하지만 비용이 엄청나게 많이 든다. 코드가 썩어가며 모듈은 서로서로 얽히고설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다. 오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다. 반면 처음부터 코드를 깨끗하게 유지하기란 상대적으로 ..

클린 코드(Clean Code) - 13장

13장. 동시성 🚦 동시성은 결합(coupling)을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 1. 동시성과 관련된 일반적인 미신과 오해 🚧 동시성은 항상 성능을 높여준다. 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우메난 성능이 높아진다. 어느 쪽도 일상적으로 발생하는 상황은 아니다. 동시성은 구현해도 설계는 변하지 않는다. 단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다. 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달리진다. 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. 실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시..

클린 코드(Clean Code) - 11장, 12장

11장. 시스템 📡 Main 분리 시스템 생성과 시스템 사용을 분리하는 한 가지 방법으로, 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다. 제어 흐름을 따라가기 쉽다. main 함수에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘긴다. 애플리케이션은 그저 객체를 사용할 뿐이다. main과 애플리케이션 사이에 표시된 의존성 화살표의 방향에 주목한다. 모든 화살표가 main 쪽에서 애플리케이션 쪽을 향한다. 즉, 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다는 뜻이다. 단지 모든 객체가 적절히 생성되었다고 가정한다. 11장 결론 시스템 역시 깨끗해야 한다. 깨끗하지 못한 아키텍..

클린 코드(Clean Code) - 10장

10장. 클래스 🏠 지금까지 코드 행과 코드 블록을 올바로 작성하는 방법에 초점을 맞췄다. 함수를 올바로 구현하는 방법과 함수가 서로 관련을 맺는 방식도 공부했다. 하지만 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 이 장에서는 깨끗한 클래스를 다룬다. 클래스는 작아야 한다! 얼마나 작아야 하는가? 함수는 물리적인 행 수로 크기를 측정했다. 클래스는 맡은 책임으로 측정을 한다. 단일 책임 원칙 (Single Responsibility Priciple) SRP는 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. 이는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. public ..

클린 코드(Clean Code) - 8장, 9장

8장. 경계 💒 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 때로는 패키지를 사고, 때로는 오픈 소스를 이용한다. 때로는 사내 다른 팀이 제공하는 컴포넌트를 사용한다. 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다. Map을 (혹은 유사한 경계 인터페이스를) 여기저기 넘기지 말라. Map sensors = new HashMap(); Sensor s = (Sensor)sensors.get(sensorId); 위의 코드는 의도가 명확히 드러나지 않는 깨끗하지 않은 코드이다. 이를 개선하기 위해 제네릭스(Generics)를 사용하면 코드 가독성이 크게 높아지지만 Map가 사용자에게 필요하지 않은..

클린 코드(Clean Code) - 7장

7장. 오류 처리 🏰 무언가 잘못될 가능성은 늘 존재한다. 무언가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다. 호출자를 고려해 예외 클래스를 정의하라. // 중복이 심하여 나쁜 코드 ACMEPort port = new ACMEPort(12); try { port.open(); } catch (DeviceResponseException e) { reportPortError(e); logger.log("Device response exception", e); } catch (ATM1212UnlockedException e) { reportPortError(e); logger.log("Unlock exception", e); } catch (GMXError e) { reportPortError(..

클린 코드(Clean Code) - 4장, 5장, 6장

4장. 주석 🌿 나쁜 코드에 주석을 달지 마라. 새로 짜라. 주석은 오래될수록 코드에서 멀어진다. 주석은 오래될수록 완전히 그릇될 가능성도 커진다. 이유는 단순하다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까. 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. 부정확한 주석은 독자를 현혹하고 오도한다. 부정확한 주석은 결코 이뤄지지 않을 기대를 심어준다. 더 이상 지킬 필요가 없는 규칙이나 지켜서는 안 되는 규칙을 명시한다. 주석은 의미를 명료하게 밝혀야 한다. 그릇된 주석을 달아놓을 위험도 상당히 높다. 그리고 주석이 올바른지 검증하기는 쉽지 않다. 이것이 의미를 명료히 밝히는 주석이 필요한 이유인 동시에 주석이 위험한 이유이기도 하다. 그러므로 주석을 달 때는 더 나은 방법이..

equals를 재정의하려거든 hashCode도 재정의하라(2) - [3장. 모든 객체의 공통 메서드(아이템11)]

앞에서 살펴본 것처럼 좋은 해시 함수라면 서로 다른 인스턴스에 다른 해시 코드를 반환한다. 이상적인 해시 함수는 주어진 (서로 다른) 인스턴스들을 32비트 정수 범위에 균일하게 분배해야 한다. 이상을 완벽하게 실현하기는 어렵지만 비슷하게 만들기는 그다지 어렵지 않다. 해당 글을 통해 해시 코드를 구현하는 4가지 방법과 주의 사항을 알아보자. 1. 전형적인 hashCode 구현 🥑 핵심 필드 중에 하나를 골라서 hashCode를 구한다. 기본 타입(primitive type) 필드라면 해당 타입의 hashCode라는 메서드를 사용해서 구하면 된다. (Type.hashCode(f)) 참조 타입(reference tyep) 필드라면 해당 타입의 hashCode를 호출해서 구한다. (Point라는 타입을 사용한..

네트워크 기본 개념

1. 네트워크란 무엇인가? 네트워크란 노드들이 데이터를 공유할 수 있게 하는 디지털 전기통신망의 하나이다. (노드란 네트워크에 속한 컴퓨터 또는 통신 장비를 뜻하는 말이다.) 즉, 분리되어 있는 컴퓨터를 통신망으로 연결한 것을 말한다. 네트워크에서 여러 장치들은 노드 간 연결을 사용하여 서로에게 데이터를 교환한다. 그렇다면 인터넷이란 무엇일까? 인터넷이란 문서, 그림, 영상과 같은 여러 가지 데이터를 공유하도록 구성된 세상에서 가장 큰 전 세계를 연결하는 네트워크이다. 흔히 www를 인터넷으로 착각하는 경우가 많은데 www는 인터넷을 통해 웹과 관련된 데이터를 공유하는 것이다. (네트워크가 더 큰 개념이다.) 2. 네트워크의 분류 1. 크기에 따른 분류 LAN (Local Area Network) 하나의..