Computer Science/객체지향 14

코드의 네이밍과 코딩 컨벤션은 왜 중요한가?

우테코 수업을 듣다가 코드에서 효과적인 네이밍이 왜 중요한가? 라는 질문을 들었다. 효과적인 네이밍은 왜 중요한가? 모두들 흔히 좋은 네이밍으로써 코드의 가독성과 이해도를 향상시키고 유지보수성을 높이는데 도움이 된다고 말한다. 하지만 이것에 대해 다시 왜? 냐고 물으면 쉽게 입이 떼어지지 않았다. 좋은 네이밍이 중요한 이유 Eddy 님의 글에서는 아래처럼 말한다. 프로그래밍은 문제 해결이 전부가 아니다. 프로그래밍은 다른 사람과의 커뮤니케이션이고 협업이다. 내가 만든 코드를 읽는 것은 컴퓨터 뿐만이 아니라 '다른 프로그래머들'이, 그들과 다를 바 없는 '미래의 나' 이다. 그래서 코드는 그 사람들에게 이 프로그램이 어떤 동작을 하는지(어떤 책임을 갖는지)를 명료하게 전달해야 한다. 또 우테코 코치 제이슨..

서브클래싱과 서브타이핑 - 코드로 이해하는 객체지향

상속은 크게 두 가지로 목적으로 사용됩니다. 상속은 타입 계층을 구현하기 위해 사용됩니다. 부모 클래스는 계층 안에서 일반적인 개념을 구현하고 자식클래스는 특수한 개념을 구현합니다. 상속은 코드 재사용을 위해 사용됩니다. 간단한 선언으로 부모 클래스의 코드를 재사용할 수 있습니다. 하지만 재사용을 위해 상속으 사용하면 부모 클래스와 자식 클래스가 강하게 결합되기 때문에 변경하기 어려운 코드를 얻게 될 확률이 높습니다. 그러므로 상속의 사용의 일차적인 목표는 타입 계층을 구현하기 위함이어야 합니다. 코드 재사용을 목표로 상속을 사용하면 부모, 자식 클래스가 강하게 결합되어 설계의 변경을 방해합니다. 하지만 타입 계층을 목표로 상속을 사용하면 다형적으로 동작하는 객체들의 관계에 기반하여 확장 가능하고 유연한..

다형성 - 코드로 이해하는 객체지향

상속은 클라이언트 관점에서 인스턴스들을 동일하게 행동하는 그룹으로 믂고 싶을 때 사용해야 합니다. 단지 단순히 코드를 재사용하기 위함이 목적이면 안 됩니다! 다형성은 런타임에 메시지를 처리하기에 적합한 메서드를 동적으로 찾는 과정을 통해서 구현됩니다. 또 상속은 이런 메서드를 찾기 위한 탐색 경로를 클래스 계층의 형태로 구현하기 위한 방법입니다. 상속의 관점에서 다형성이 구현되는 기술적인 매커니즘을 먼저 살펴봅시다. 다형성 다형성(Polymorphism)은 여러 타입을 대상으로 동작할 수 있는 코드를 작성할 수 있는 방법입니다. 객체지향 프로그래밍에서 다형성은 아래처럼 분류될 수 있습니다. 오버로딩 다형성: 하나의 클래스 안에 동일한 메서드 존재하는 경우입니다. 흔히 말하는 메서드 오버로딩이 이 경우이죠..

합성과 유연한 설계 - 코드로 이해하는 객체지향

상속은 부모 클래스와 자식 클래스를 연결해서 부모 클래스의 코드를 재사용하고 합성은 전체를 표현하는 객체가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용합니다. 상속 관계는 is-a 관계입니다. 자식 클래스가 Cat, 부모 클래스가 Animal 이면 Cat is a Animal 인 것이죠. 합성은 has-a 관계입니다. Cat has a Claw(발톱). 형식이지요. 이 둘은 코드 재사용이라는 동일한 목적을 가지지만, 이것을 제외하면 구현 방법, 변경을 다루는 방식이 다릅니다. 상속은 부모 클래스의 코드를 자식 클래스가 자신의 것처럼 사용하고, override 할 수 있게 합니다. 하지만 부모 클래스의 내부 구현, 의도를 자세히 알고 이해해야 상속을 제대로 사용할 수 있기 때문에 자식 클래스..

상속과 코드 재사용. 상속을 사용할 때 조심해야 할 점을 중심으로 - 코드로 이해하는 객체지향

재사용 관점에서 상속 은 클래스 안에 정의된 인스턴스 변수와 메서드를 자동으로 새로운 클래스에 추가하는 구현 기법입니다. 코드 재사용의 다른 방법으로는 합성이 있습니다. 새로운 클래스의 인스턴스 안에 기존 클래스의 인스턴스를 포함시키는 방법입니다. 합성은 다음 글에서 알아보고 이번에는 상속에 대해 자세히 알아봅니다. 상속과 중복 코드 DRY 원칙 중복 코드는 변경을 방해합니다. 중복 코드는 코드를 수정하는데 드는 비용을 더 증가시킵니다. 테스트를 할 때도 그렇죠. 중복 여부를 판단하는 기준은 모양이 아니라 변경입니다. 요구사항이 변경되었을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복인 것입니다. 중복 여부를 결정하는 기준은 코드가 변경에 반응하는 방식입니다. 코드의 모양이 유사하다는 것은 단지 중..

유연한 설계 - 코드로 이해하는 객체지향

이전 글에서의 다양한 의존성 관리 기법을 원칙 이라는 관점에서 정리해봅시다. https://sh1mj1-log.tistory.com/154 의존성 관리 - 코드로 이해하는 객체지향 잘 설계된 객체지향 App. 은 작고 응집도 높은 객체들로 구성됩니다. 책임이 명확하고 한 가지 일을 잘하는 객체이지요. 이 객체들이 협력을 하는 것입니다. 협력은 하면 필연적으로 의존성이 발 sh1mj1-log.tistory.com 개방-폐쇄 원칙 개방-폐쇄 원칙(Open-Closed Principle, OCP): 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 여기서 확장 은 애플리케이션(이하 앱)의 동작의 관점, 수정 은 코드의 관점 을 반영합니다. 확장에 ..

의존성 관리 - 코드로 이해하는 객체지향

잘 설계된 객체지향 App. 은 작고 응집도 높은 객체들로 구성됩니다. 책임이 명확하고 한 가지 일을 잘하는 객체이지요. 이 객체들이 협력을 하는 것입니다. 협력은 하면 필연적으로 의존성이 발생합니다. 너무 과한 협력은 과한 의존성을 발생시키므로 결국 '적당히' 가 중요합니다. 충분히 협력적이면서도 유연한 객체르 만들기 위한 의존성 관리에 대한 글입니다. 의존성 변경과 의존성 의존성은 의존하고 있는 대상의 변경에 영향을 받을 수 있는 가능성입니다. 실행 시점 의존성: 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 함. 구현 시점 의존성: 의존 대상 객체가 변경될 경우 의존하는 객체도 함께 변경됨. 위 글만 읽으면 무슨 소리인지 잘 이해가 안되는데, 코드를 통해서..

객체 분해 - 코드로 이해하는 객체지향

프로시저 추상화와 데이터 추상화 프로그래밍 언어의 두가지 추상화 메커니즘은 프로시저 추상화(procedure abstraction) 와 데이터 추상화(data abstraction) 입니다 . 각각 소프트웨어가 무엇을 해야 할지를 추상화하고, 소프트웨어가 무엇을 알아야 하는지를 추상화합니다. 시스템을 분해하는 방법을 결정하려면 프로시저 추상화를 중심으로 할 것인지, 데이터 추상화를 중심으로 할 것인지를 결정해야 합니다. 프로시저 추상화를 중심으로 하면 기능 분해(functional decomposition) == 알고리즘 분해(algorithmic decomposition) 을 하는 것이며, 데이터 추상화를 중심으로 하면 데이터를 중심으로 타입을 추상화(type abstraction) == 추상 데이터 ..

메시지와 인터페이스 - 코드로 이해하는 객체지향

메시지와 인터페이스 객체 지향 애플리케이션의 가장 중요한 재료는 클래스가 아닌 객체들이 주고받는 메시지입니다. 객체를 수신하는 메시지들이 객체의 퍼블릭 인테페이스를 구성합니다. 책임 주도 설계 방법 + 좋은 퍼블릭 인터페이스를 얻기 위한 설계 원칙과 기법을 익히고 적용해야 합니다. 협력과 메시지 클라이언트 - 서버 모델 두 객체 사이의 협력 관계를 설명할 때 전통적으로 클라이언트 - 서버(Client - Server) 모델 을 사용합니다. 메시지를 전송하는 객체가 클라이언트, 수신하는 객체가 서버입니다. 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이죠 위 그림에서 클라이언트 Screening 이 가격을 계산하라 메시지를 전송하여 도움을 요청하고 서버 Movie 는 가격을 계산하는 서비스를 제공하..

책임 할당 - 코드로 이해하는 객체지향 프로그래밍

https://sh1mj1-log.tistory.com/131 이 글에서는 책임 중심 설계의 객체 지향 코드의 대략적인 모양, https://sh1mj1-log.tistory.com/133 이 글에서는 역할, 책임, 협력이 객체지향적인 코드를 작성하기 위한 핵심이라는 사실, https://sh1mj1-log.tistory.com/137 이 글에서는 데이터에 초점을 맞출 때 생기는 문제점에 대해 알아보았습니다. 이번에는 책임 중심 설계의 설계 과정을 하나씩 따라가보면서 책임 할당 기본 원리를 살펴봅시다. 책임 할당 책임 주도 설계를 향해서 두가지 원칙을 지켜야 합니다. 데이터보다 행동을 먼저 결정하자 협력이라는 문맥 안에서 책임을 결정하자 데이터보다 행동을 먼저 결정하자 먼저 '이 객체가 수행해야 하는 책..