객체 지향 - 하늘꿈

쉬운 목차

프로그래밍 패러다임

어형 변화표

한 시대의 전체 사회가 공유하는 이론, 방법 및 문제 인식의 체계

프로그래밍 패러다임

특정 시점에 성숙한 개발자 커뮤니티에서 수용된 프로그래밍 방법, 문제 해결 방법 및 프로그래밍 스타일.

우리가 사용하는 프로그래밍 패러다임은 우리가 해결하는 문제를 바라보는 방식과 프로그램을 작성하는 방식을 바꿉니다. 다른 프로그래밍 언어는 다른 프로그래밍 패러다임을 채택합니다.

'추천 관련글,

패러다임 변화

절차적 패러다임에서 객체 지향 패러다임으로의 전환을 의미합니다.

프로그래밍 패러다임의 역할

개발자 커뮤니티가 동일한 프로그래밍 스타일과 모델을 공유할 수 있도록 함으로써 불필요한 사항에 대한 의견 불일치를 피할 수 있습니다.

교육을 통해 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비할 수도 있습니다.

특정 유형의 문제를 해결하는 데 필요한 일련의 개념을 지원합니다.

소극장 애플리케이션의 문제점

의도

극장: 관객 입장

TickerSeller: 티켓 판매

청중: 티켓 구매

1. 기대 이상의 코드 예제

내가 관객이라고 가정하면 관객의 입장에서 소극장이라 일컬어지는 제3자가 관객의 가방을 마음대로 열어 초청을 확인한다.

의도: 티켓을 구매하는 방문자는 주머니에서 돈을 꺼내 판매자에게 지불합니다.

2. 변경에 취약한 코드 예시

의존성 문제. 객체가 변경되면 다른 종속 객체도 변경될 수 있습니다.

Theatre는 Audience 및 TicketSeller의 자세한 내부 구현을 알고 있어야 합니다.

디자인 개선

// 문제코드
public class Theater{
	private TicketSeller ticketSeller;
    
    public Theater(TicketSeller ticketseller){
    this.ticketSeller = ticketSelelr;
    }
    
    public void enter(Audience audience){
        if(audience.getBag().hasInvitation()){ //TicketSeller의 sellTo()메소드로 옮긴다. TicketSeller의 내부구현을 캡슐화
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().setTicket(ticket);
        }else{
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            ticketSeller.getTicketOffice().plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
	}
}

//개선 코드
public class Theater {
	private TicketSeller ticketSeller;
    
    public Theater(TicketSeller ticketSeller){
    	this.ticketSeller = ticketSeller;
        }
    
    public void enter(Audience audience){
    	ticketSeller.sellTo(audience); //TicketOffice에 접근하는 로직을 모두 ticketSeller.sellTo에 숨김
        }
    }

1. 자율성을 높인다

청중과 판매자를 자율적으로 만듭니다.

TicketSeller 및 Audience 세부 정보에서 Theatre의 정보를 차단합니다.

방문객은 주머니에 든 현금과 초대장을 직접 관리하고 판매자는 매표소에서 티켓과 판매 수수료를 직접 관리합니다.

1.1 캡슐화 개체 내에서 세부 정보를 개념적 또는 물리적으로 숨기는 것입니다.

개체 내부에 대한 액세스를 제한하면 개체 간의 결합 정도가 줄어듭니다. -> 보다 쉽게 디자인 변경 가능

접근 가능한 public 메소드가 없기 때문에 외부에서 직접 ticketOffice에 접근할 수 없습니다. TicketSeller에만 존재합니다.

1.2 수정된 극장 클래스는 어디에서도 ticketOffice에 액세스하지 않습니다.

극장은 TicketSeller에 ticketOffice가 있는지 모르겠습니다.

극장은 오직 TicketSeller 인터페이스에만 의존합니다.

개체를 인터페이스와 구현으로 분해하고 인터페이스만 노출하면 개체 간의 결합이 줄어들고 코드를 더 쉽게 변경할 수 있습니다.

2. 자신의 문제 해결

벤더가 티켓을 판매하기 위해 ticketOffice 사용의 모든 부분 TicketSeller로 이동하여 관객이 티켓을 구매하기 위해 가방을 사용하는 모든 부분을 관객으로 이동합니다.

코드를 수정하여 문제를 직접 해결하십시오.

개량

변경 용이성 향상

TicketSeller의 내부 구현을 변경하더라도 함께 극장을 변경할 필요가 없습니다. TicketSeller가 매표소가 아닌 은행에 돈을 보관하기를 원하는 경우 TicketSeller 내에서 전환하기만 하면 됩니다.

책임 이전

기존 코드에서는 Threater에 책임이 집중되었습니다.

독재자가 없으며 책임이 각 개체에 적절하게 분배됩니다.

데이터와 데이터를 사용하는 프로세스는 동일한 개체에 상주합니다.

절차상의

개선 이전의 연극은 절차적 프로그래밍입니다.

극장 입장 방식은 프로세스이고, Audience, TicketSeller, Bag, TicketOffice는 데이터입니다.

과정을 담당하는 극장 Audience, TicketSeller, Bag 및 TicketOffice 모두 여기에 의존했습니다. 모든 처리는 하나의 클래스에 배치되었고 나머지 클래스는 데이터에 불과했습니다.

별도의 모듈에 프로세스와 데이터를 배치하는 것은 절차적입니다.

객체지향 설계

자체적으로 문제를 처리하기 때문에 예측 가능하고 이해하기 쉬우며, 개체 내부의 변경 사항이 외부로 전파되지 않도록 제어할 수 있기 때문에 변경하기 쉽습니다.
종속성 제거 : 불필요한 종속성 제거 -> 객체 간 결합 정도 감소
Encapsulation: Theater가 알 필요가 없는 세부 정보를 Audience 및 TicketSeller에 숨겨서 캡슐화합니다.