sh1mj1_log

소개이전 글에서는 SOLID 원칙 중 첫 번째, 두 번째, 세 번째 원칙인 단일 책임 원칙(SRP), 개방-폐쇄 원칙(OCP), 리스코프 치환 원칙(LSP)을 다뤘습니다.아직 읽어보지 않았다면 먼저 확인해 보시길 추천합니다.🔗  SRP(Single Responsibility Principle) 글 보기🔗  OCP(Open-Closed Principle) 글 보기🔗  LSP(Liskov Substitution Principle) 글 보기이번 글에서는 네 번째 원칙인 인터페이스 분리 원칙(Interface Segregation Principle, ISP)을 살펴보겠습니다.이 원칙은 클래스가 실제로 사용하는 기능만을 포함하도록 인터페이스를 분리하여 유연하고 유지보수하기 쉬운 시스템을 설계하는 것을 목표로..

소개이전 글에서는 SOLID 원칙 중 첫 번째와 두 번째 원칙인 단일 책임 원칙(SRP)과 개방-폐쇄 원칙(OCP)을 다뤘습니다.아직 읽어보지 않았다면 먼저 확인해 보시길 추천합니다.🔹 SRP(단일 책임 원칙) 글 보기🔹 OCP(개방-폐쇄 원칙) 글 보기이번 글에서는 세 번째 원칙인 리스코프 치환 원칙(Liskov Substitution Principle, LSP)을 살펴보겠습니다.이 원칙은 객체 지향 시스템에서 유연하고 안정적인 구조를 설계하는 핵심 개념입니다.LSP(리스코프 치환 원칙)란?리스코프 치환 원칙(Liskov Substitution Principle, LSP)은 다음과 같이 정의됩니다."부모 클래스(상위 타입)의 객체를 자식 클래스(하위 타입)의 객체로 대체하더라도 프로그램의 정확성이 ..

소개이전 글 다시 보기이전 글에서는 SOLID 원칙 중 첫 번째인 단일 책임 원칙(SRP)에 대해 다뤘습니다.SRP를 준수함으로써 어떻게 코드를 더 단순하고 유지보수하기 좋게 만들 수 있는지 알아보았습니다.이번 글에서는 SOLID 원칙의 두 번째, OCP(개방-폐쇄 원칙)에 대해 살펴보겠습니다.이 원칙은 소프트웨어 시스템이 변경에 유연하게 대처할 수 있도록 설계하는 데 중요한 역할을 합니다.OCP(개방-폐쇄 원칙)이란?OCP는 다음과 같이 정의됩니다:“소프트웨어 엔티티는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다.”간단히 말해:새로운 기능이나 동작을 추가할 때 기존 코드를 수정하지 않고 확장할 수 있어야 합니다.이를 통해 기존 시스템을 안정적으로 유지하면서도 새로운 요구사항에 쉽게 적응할 수..

소개SOLID란?SOLID 는 객체지향 설계를 더 이해하기 쉽고, 유연하며, 유지보수하기 쉽게 만드는 다섯 가지 원칙을 말합니다.이 원칙들은 시스템을 확장 가능하고, 견고하며, 변경에 적응할 수 있도록 설계하도록 안내합니다.하지만 이러한 원칙을 이해하는 것은 실용적인 예제가 없으면 어렵게 느껴질 수 있습니다.왜 이 시리즈를 작성했나요?이 시리즈의 목적은 간단합니다:SOLID 원칙이 어떻게 위반되는지를 명확히 설명합니다.각 원칙을 효과적으로 준수하는 방법을 리팩토링 과정을 통해 보여줍니다.SRP(단일 책임 원칙)이란?SRP(Single Responsibility Principle)는 객체지향 설계 원칙의 기초로, 다음을 의미합니다:모듈은 오직 하나의 책임만 가져야 한다.모듈은 변경해야 하는 이유가 단 하나..

우테코 수업을 듣다가 코드에서 효과적인 네이밍이 왜 중요한가? 라는 질문을 들었다. 효과적인 네이밍은 왜 중요한가? 모두들 흔히 좋은 네이밍으로써 코드의 가독성과 이해도를 향상시키고 유지보수성을 높이는데 도움이 된다고 말한다. 하지만 이것에 대해 다시 왜? 냐고 물으면 쉽게 입이 떼어지지 않았다. 좋은 네이밍이 중요한 이유 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): 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 여기서 확장 은 애플리케이션(이하 앱)의 동작의 관점, 수정 은 코드의 관점 을 반영합니다. 확장에 ..