CS/OOP

[OOP] SOLID 정리

앞선 게시글에서 객체지향 설계 원칙인 SOLID Principle에 대해 알아보았다. 이 글에서는 SOLID Principle을 사용해야 하는 이유, 그리고 각각의 원칙들의 연관성에 대해 조금 살펴본다. 왜 설계 원칙이 중요할까? 사용자 요구사항의 변경은 정말 시시때때로 이루어진다. 요구사항이 바뀌면 한숨부터 나오는 것은 사실이다. 그렇지만 이러니저러니 해도 결국 그 요구사항을 받아들여 프로그램을 수정해야 한다. 왜? 결국 프로그램을 사용하는 건 사용자니까. 이런저런 요구사항을 전부 수정하다보면 코드가 꼬이는 일도 비일비재하다. 초기에는 깨끗한 설계도 이것저것 덧붙이다 보면 지저분해지기 마련이니까. 그래서 더더욱 유지보수성과 확장성이 높으면서도 버그가 적게 발생할 수 있는 좋은 설계가 중요하다. SOLI..

[OOP] SOLID - Dependency Inversion Principle

이 글은 객체지향 5대 원칙, SOLID principle 중 D인 Dependency Inversion Principle, 의존성 역전 원칙에 대해 알아본다. 정의 dependency를 가지는 component가 구현체가 아닌 추상화에 의존해야 한다는 원칙이다. 각 모듈들이 dependency를 가질 때(상위 module이 하위 module을 사용할 때) concretion이 아닌 abstraction에 의존해야 한다. abstraction은 concretion에 의존하면 안 된다. concretion은 abstraction에 의존해야 한다. 결국 모든 경우에 abstraction에 의존해야 한다. 예전의 설계는 상위 module이 하위 module의 concretion을 직접적으로 사용하며, 이 때 ..

[OOP] SOLID - Interface Segregation Principle

이 글은 객체지향 5대 원칙, SOLID Principle 중 Interface Segregation Principle에 대해 다룬다. 정의 Interface Segregation Principle은 object는 자신이 사용하지 않는 method를 포함한 interface에 의존하면 안 된다는 원칙이다. 이 원칙은 dependency와 overhead에 대한 이야기이다. 언제 사용해야 할까? 만약 어떤 class C가 interface I를 implement하는 예시를 생각해 보자. interface I에는 method A, B, C 등 여러 가지 method가 있다. 그러나 class C는 method A밖에 사용하지 않는다. 이 경우 class C에서는 사용하지 않는 method B, method ..

[OOP] SOLID - Liskov Substitution Principle

이 글은 객체지향 5대 원칙, SOLID principle 중 L인 Liskov Substition Principle을 다룬다. 정의 subtype이 항상 supertype로 치환할 수 있어야 한다는 원칙이다. 이 원칙은 polymorphism에 관련된 이야기이다. 다르게 설명하자면 supertype을 사용하는 위치에 subtype을 넣어도 프로그램 수행에는 변화가 없어야 한다는 말이다. 따라서 supertype에서 사용하는 method는 subtype에서도 사용할 수 있어야 한다. polymorphism을 공부했다면 method overriding과 upcasting에 대해 이미 알고 있을 것이다. Liskov Substitution Principle를 따른다면 upcasting한 상태에서 parent..

[OOP] SOLID - Open Closed Principle

이 글은 객체지향 5대 원칙, SOLID principle 중 O인 Open Closed Principle에 대해 알아본다. 정의 class, function, module 등 프로그램의 구성 요소는 확장에는 열려 있고 수정에는 닫혀 있어야 한다는 원칙이다. 조금 풀어 설명하면 코드를 변경하지 않으면서 기능 변경 또는 확장할 수 있도록 설계되어야 한다는 것이다. Open Closed Principle가 준수되지 않은 경우 요구사항이 변화하거나 새로운 요구사항이 생길 때 기존 코드를 수정해야 한다. 반면 완벽하게 준수되었다면 요구사항의 변화 또는 확장 시 기존 코드를 수정할 필요 없이 새로운 코드만 추가하면 된다. 따라서 이 원칙은 프로그램의 유지보수성을 높여주며 코드의 확장성을 높이는 데 크게 기여한다...

[OOP] SOLID - Single Responsibility Principle

이 글은 객체지향 5대 원칙, SOLID principle 중 S인 Single Responsibility Principle 단일 책임 원칙에 대해 알아본다. 정의 Single Responsibility Principle은 모든 class는 단 하나의 책임을 가져야 한다를 의미한다. 여기서 책임이란 단어가 조금 애매한데, 해당 class가 수행하는 역할이라고 이해해도 된다. 따라서 class가 단 하나의 역할만 가져야 한다고 이해해도 무방하며, 즉슨 class 변경의 이유가 맡고 있는 역할에 대한 변경 단 하나뿐이어야 한다는 것도 의미한다. 예를 들어 class teamA, class teamB가 Data class의 getData()라는 method를 사용한다고 가정하자. getData() method..

[OOP] 객체지향 프로그래밍 Object-Oriented Programming

컴퓨터가 만들어진 후 초창기 프로그램은 대부분이 Procedural 프로그래밍이었다. 그러나 시작부터 끝까지 모든 순서를 정의하기에는 경우의 수가 너무 많고 코드가 꼬이기 십상이다. 그래서 나온 개념이 바로 Object-oriented이다. 객체지향이란? 객체지향에 대한 명확한 정의를 딱 내리긴 어렵고 사람마다 다양한 관점이 있지만, 나는 다음과 같이 정의한다. 객체지향이란 객체들의 상호작용으로 프로그램을 구현하는 방법이다. 객체란 어떤 개념을 추상화하고 모델링한 요소이다. 객체에 대해 좀 더 설명하자면, 어떠한 개념을 추상화하고 모델링을 통해 만든 요소이다. 객체는 상태(state)와 행위(behavior)를 가지고 있으며 행위를 통해 상호작용한다. Class vs Instance class는 inst..