<div id="readability-page-1" class="page"><div itemprop="articleBody">
            

            

            

            <p><img src="https://user-images.githubusercontent.com/33862991/113977861-2e98d000-987e-11eb-8b99-b4feb494dd1f.jpg"></p>
<p>지난 포스팅 <a href="https://youngjinmo.github.io/2021/04/features-of-oop/">객체지향 주요특징</a>에 이어 이번엔 객체지향의 주요 5가지 원칙을 정리해보려고 한다.</p>
<h2 id="객체지향-5가지-원칙"><a href="#객체지향-5가지-원칙" title="객체지향 5가지 원칙"></a>객체지향 5가지 원칙</h2><p>인프런에서 <a target="_blank" rel="noopener" href="https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8">스프링 핵심 원리 - 기본편</a>을 수강하며 정리한 내용이다. 토비의 스프링을 읽으면서 템플릿 메소드에 대한 내용이 쉽게 와닿지않아서 수강한 내용이었는데, 도움이 많이 되었다.</p>
<ul>
<li><a href="#srp">SRP (Single Responsibility Principle) : 단일 책임 원칙</a></li>
<li><a href="#ocp">OCP (Open-Closed Principle) : 개방 폐쇄 원칙</a></li>
<li><a href="#lsp">LSP (Liskov Substitution Principle) : 리스코프 치환 원칙</a></li>
<li><a href="#isp">ISP (Interface Segragation Principle) : 인터페이스 분리 원칙</a></li>
<li><a href="#dip">DIP (Dependency Inversion Principle) : 의존관계 역전 원칙</a></li>
</ul>
<br>

<h2 id="단일-책임-원칙-Single-Responsibility-Principle"><a href="#단일-책임-원칙-Single-Responsibility-Principle" title="단일 책임 원칙, Single Responsibility Principle"></a><a name="srp"></a>단일 책임 원칙, Single Responsibility Principle</h2><p>하나의 클래스는 하나의 책임만 가져야한다. </p>
<p>책임이란 기준이 모호하기 때문에 <strong><u>변경</u></strong> 을 책임의 기준으로 삼으면 설계에 용이할 수 있다. </p>
<p>어떠한 역할에 대해 변경사항이 발생했을때, 영향을 받는 기능만 모아둔 클래스라면 동일한 책임을 지닌 기능이 모인 집합으로써 SRP 원칙이 적용된 설계로 볼 수 있을것 같다.</p>
<p>이처럼 <strong><u>변경사항이 있을때, 애플리케이션의 파급 효과가 적으면</u></strong> SRP 원칙을 잘 따른것으로 볼 수 있다.</p>
<br>

<h2 id="개방-폐쇄-원칙-Open-Closed-Principle"><a href="#개방-폐쇄-원칙-Open-Closed-Principle" title="개방 폐쇄 원칙, Open Closed Principle"></a><a name="ocp"></a>개방 폐쇄 원칙, Open Closed Principle</h2><p><a target="_blank" rel="noopener" href="https://link.coupang.com/re/CSHARESDP?lptag=CFM65897625&amp;pageKey=20487435&amp;itemId=80658953&amp;vendorItemId=4187044755">토비의 스프링(저 이일민)</a>에서 개방 폐쇄 원칙을 <strong>높은 응집도와 낮은 결합도</strong>라는 원리로 설명할 수 있다고 한다.</p>
<h3 id="높은-응집도"><a href="#높은-응집도" title="높은 응집도"></a>높은 응집도</h3><p>응집도가 높다는건 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어 있다는 뜻이다. 같은 책임, 관심사를 기반으로 하나의 객체로 설계하기 때문에 객체에 변경이 발생하더라도 다른 곳에 미치는 영향이 제한적이다.</p>
<h3 id="낮은-결합도"><a href="#낮은-결합도" title="낮은 결합도"></a>낮은 결합도</h3><p>책임과 관심사가 다른 객체 도는 모듈과는 낮은 결합도를를 유지해야 한다. 이는 높은 응집도보다 더 민감한 원칙이라고 토비의 스프링에서는 설명하고 있다.</p>
<p>결합도란 하나의 오브젝트가 변경이 일어날때 관계를 맺고있는 다른 오브젝트에게 변화를 요구하는 정도로 설명한다.</p>
<p>즉 낮은 결합도란, 하나의 변경이 발생할 때 다른 모듈과 객체로 변경에 대한 요구가 전파되지 않는 상태라고 할 수 있다.</p>
<hr>
<p>다른 곳에서는 개방폐쇄 원칙을 확장에 열려있고, 변경에 닫혀있다고도 설명한다.</p>
<h3 id="확장에-열려있다"><a href="#확장에-열려있다" title="확장에 열려있다?"></a>확장에 열려있다?</h3><p>모듈의 확장성을 보장하는 것을 의미한다. <mark>새로운 변경사항이 발생했을 때 유연하게 코드를 추가 또는 수정</mark>할 수 있기 때문이라고 한다.</p>
<h3 id="변경에-닫혀있다"><a href="#변경에-닫혀있다" title="변경에 닫혀있다?"></a>변경에 닫혀있다?</h3><p>객체를 직접적으로 수정하는건 제한해야 한다. 기능이 추가되거나 수정할 때, 객체를 직접적으로 수정해야 한다면 새로운 변경사항에 대해 유연하게 대응할 수 없는 애플리케이션이다. </p>
<p>이는 유지보수의 비용증가가 될 수 있으며, 객체지향적인 설계로 볼 수 없다.</p>
<p>따라서 <mark>객체를 직접 수정하지 않고도 변경사항을 적용</mark>할 수 있도록 설계해야 한다. 그래서 변경에 닫혀있다고 표현한 것으로 추론된다.</p>
<br>

<h2 id="리스코프-치환-원칙-Liskov-Substitution-Principle"><a href="#리스코프-치환-원칙-Liskov-Substitution-Principle" title="리스코프 치환 원칙, Liskov Substitution Principle"></a><a name="lsp"></a>리스코프 치환 원칙, Liskov Substitution Principle</h2><p>객체는 프로그램의 정확성을 깨지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다.</p>
<p>하위 클래스는 인터페이스 규약을 지켜서 작성되어야 한다. 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면 LSP가 필요하다.</p>
<p>인터페이스의 메소드를 사용한다고 하면, 어떤 구현체를 사용하든 호출부에서 기대하는대로 동작되어야 한다는 것이다.</p>
<figure><table><tbody><tr><td><pre><span>1</span><br><span>2</span><br><span>3</span><br></pre></td><td><pre><span><span><span>interface</span> <span>Calculator</span></span>{</span><br><span>   <span><span>int</span> <span>add</span><span>(<span>int</span> num1, <span>int</span> num2)</span></span>;</span><br><span>}</span><br></pre></td></tr></tbody></table></figure>

<p>호출부에서 <code>add()</code>를 호출하면, 내부 로직을 모르더라도 파라미터에 들어온 데이터를 합산해서 반환해줄 것이라는 것을 기대하고 사용할테니 인터페이스 <code>Calculator</code>의 구현체, 하위 클래스들은 이런 규약을 지켜서 설계되어야 한다.</p>
<br>

<h2 id="인터페이스-분리-원칙-Interface-Segragation-Principle"><a href="#인터페이스-분리-원칙-Interface-Segragation-Principle" title="인터페이스 분리 원칙, Interface Segragation Principle"></a><a name="isp"></a>인터페이스 분리 원칙, Interface Segragation Principle</h2><p>범용 인터페이스 하나보다는 특정 클라이언트를 위한 여러 개의 인터페이스 분리가 더 좋다고 한다.</p>
<p><code>운전자가 자동차를 운전한다.</code> 라는 명제를 객체간 관계로 비유하면 자동차에 대한 인터페이스, 운전자에 대한 인터페이스를 각각 분리하는 것이다. </p>
<p>그럼 <code>운전자</code>는 <code>택시 기사</code>가 될수도 있고, <code>우버 드라이버</code>가 될수 있다. <code>자동차</code>는 <code>버스</code>가 될 수도 있고, <code>택시</code>가 될수도 있고, <code>스포츠카</code>가 될 수도 있다. </p>
<br>

<h2 id="의존관계-역전-원칙-Dependency-Inversion-Principle"><a href="#의존관계-역전-원칙-Dependency-Inversion-Principle" title="의존관계 역전 원칙, Dependency Inversion Principle"></a><a name="dip"></a>의존관계 역전 원칙, Dependency Inversion Principle</h2><p>프로그래머는 구체화가 아니라 추상화에 의존해야 한다고 한다. 즉 <mark>구현 클래스(구현체)가 아니라 인터페이스(역할)에 의존</mark>하라는 이야기이다.</p>
<p>연극을 예로 들면 <b>배역(인터페이스)</b>과 <b>배우(구현체)</b>를 예로 들 수 있다. 이 때 연극은 특정 배우를 염두에 두고 기획되기보다 배역에 집중해서 기획되어야 한다. </p>
<p>특정 배우에 의존했는데 만약 그 배우가 스케줄 또는 당일 컨디션때문에 연극에 출연이 불발 될 경우 해당 연극은 차질이 불가피해진다. 따라서 연극은 배우가 아닌 배역에 의존해야 한다.</p>
<p>지난 포스팅(<a href="https://youngjinmo.github.io/2021/04/features-of-oop/">객체지향 주요특징</a>)에서 다형성을 언급하면서 사용한 이미지를 인용하겠다.</p>
<p><img src="https://user-images.githubusercontent.com/33862991/114132424-4dab6680-993f-11eb-836d-39dbfdd59f94.png"></p>
<p>이렇게 의존관계를 설계하면 <code>LottoNumberGenerator</code> 객체에 대한 변경사항이 발생하거나 혹은 객체를 삭제할 일이 있어도 <code>Lotto</code> 클래스에는 직접적인 코드 변경할 필요가 없게된다.</p>

        </div></div>

객체지향 설계 원칙 5가지

댓글