들어가며객체지향 프로그래밍에서 클래스를 설계할 때 우리는 종종 단순히 "어떤 속성과 메서드가 필요한가?"라는 구현 중심적 사고에 빠지곤 합니다. 하지만 좋은 클래스 설계를 위해서는 보다 체계적이고 다각도적인 접근이 필요합니다. 개념 관점 설계는 도메인 안에 존재하는 개념과 개념들 상의 관계를 표현합니다. 도메인이란 사용자들이 관심을 가지고 있는 특정 분야나 주제를 말하며 소프트웨어는 도메인에 존재하는 문제를 해결하기 위해 개발됩니다. 이 관점은 사용자가 도메인을 바라보는 관점을 반영합니다. 따라서 실제 도메인 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심입니다. 명세 관점에 이르면 사용자의 영역인 도메인을 벗어나 개발자의 영역인 소프트웨어로 초점이 옮겨집니다. 명세 관점은 도메인의 개념이 아니라 실제..
programming
서론오류를 나누는 기준은 여러가지가 있을 수 있습니다. 개발자의 관점에서 에러는 처리의 대상이며 상황에 따른 적절한 처리를 위해 소프트웨어가 계속 작동할 수 있는 오류와 작동할 수 없는 오류로 구분할 수 있습니다. 이 포스팅에서는 에러를 복구 가능에러와 복구 불가능 에러로 구분하고 각 에러의 처리 방식에 대한 이야기를 나눠보겠습니다. 복구 가능한 오류시스템 전체에 영향을 미칠만큼 치명적이지 않으며 호출하는 곳에서 오류를 복구하는 것이 합리적인 경우입니다.대표적인 예로 로그인폼에 패스워드를 잘못입력하는 경우가 있습니다. 이 경우 앱을 멈추는 대신에 사용자에게 다시 비밀번호 입력을 유도하는 것이 더 이상적입니다. 일반적으로 복구 가능한 오류의 예에는 다음과 같습니다. 1.네트워크 오류외부 서비스에 연결할 ..
서론 좋은 코드의 조건을 다양합니다. 하지만 "표현이 직관적이며 동작이 예상 가능한 코드"가 좋은 코드라는 것에는 이견이 없을 것이라 생각합니다. 동작이 예상 가능한 코드라는 표현을 달리 말하면 오용하기 어려운 코드라고 할 수 있습니다. 오늘 주제는 코드의 제약 조건에 의해 발생하는 오용 가능성과 이런 제약 조건을 핸들링해서 오용 가능성을 좁히는 내용입니다.(이 내용은 좋은 코드, 나쁜 코드에 수록된 내용을 정리한 것임을 밝힙니다.) 제약 조건이 있는 코드오용하기 쉬운 코드는 암묵적 제약 조건이 많은 코드라고 할 수 있습니다. 제약 조건에 대한 이해가 있어야 제대로 사용할 수 있는 코드라는 말은 자칫 잘못 사용되기 쉬운 코드라는 말이 됩니다. 다음의 예제를 통해 코드에서 발생하 수 있는 제약조건에 대해..
서론우리 모두는 단일 책임 원칙 (Single Responsibility Principle, SRP) 에 대해 이미 알고 있습니다.하나의 모듈은 하나의 책임만 가져야한다는 객체 지향 프로그래밍의 설계 원칙입니다. 너무 명쾌한 내용이기에 이 원칙을 공감하지 못하는 분은 없을겁니다. 하지만 그럼에도 불구하고 우리는 비대한 모듈을 만들곤 합니다. 왜 일까요? 바로 "하나의 책임"이라는 말이 가지는 모호함때문입니다. 과연 어디까지 책임의 범위로 취급해야 할까요? 커피를 만드는 과정으로 예를 들어보겠습니다. 1. 물을 끊인다.2. 원두를 갈아 넣는다.3. 물을 커피에 붓는다.4. 커피를 컵에 따른다. 커피를 만드는 과정을 위 4가지 단계로 나눠보겠습니다. 그러면 각 단계가 각각 하나의 책임일까요? 한번 딴지를 걸..
