CheerUp_Cheers
오브젝트 1일 본문
#CHAP 0
이 책의 패러다임 전환
절차형 패러다임 -> 객체지향 패러다임으로의 변화.
프로그래밍 패러다임
개발자 공동체가 동일한 프로그래밍 스타일과 모델 공유
->불필요한 부분에 대한 의견충돌 방지.
패러다임 교육 -> 동일한 규칙과 방법을 공유하는 개발자.
-> 이 책이 쓰여진 이유.
플로이드 언급, 각 프로그래밍 언어가 제공하는 특징과 스타일은 언어에 프로그래밍 패러다임에 따름.
- C언어, 절차형 패러다임 기반
- JAVA, 객체지향 패러다임을 기반
- 리스프, 함수형 패러다임
- 프롤로그, 논리형 패러다임
=> 프로그래밍언어와 프로그래밍 패러다임을 분리 할수 없는 이유.
=> 객체지향이 적합하지 않은 상황에서는 언제나 다른 패러다임에 주목하라.
추상적인 개념과 이론
-> 훌륭한 코드 작성의 도구.
소프트웨어 설계와 유지보수에 중점을 두려면 실무에 초점을 맞추자.
-> 실무는 이론을 뛰어 넘음.
#01_ 티켓 판매 어플리케이션
객체사이의 의존성이 높음 = 결합도가 높다
-> 변경에 취약하고 이해가 어렵다.
-> 여기서 이해란, 관람객과 판매원이 일을 스스로 해야한다는 직관을 벗어난다는것.(극장이 다함)
#개선해야할 점
- 최소한의 의존성을 유지
- 불필요한 의존성을 제거하는것.
=> Theater가 불필요하게 알아야 하는 정보를 차단하자.
=> 관람객과 판매원을 자율적인 존재로 만들자.
#캡슐화
목적 : 변경하기 쉬운 객체를 만드는 것.
정의 : 객체 내부의 세부적인 사항을 감추는 것.
#인터페이스와 구현
객체 : 인터페이스 + 구현으로 나누고, 인터페이스만을 공개하는 것
-> 객체사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하는 가장 기본적 설계 원칙.
package C_01.Ticket_after;
public class Theater {
private TicketSeller ticketSeller;
public Theater(TicketSeller ticketSeller) {
this.ticketSeller = ticketSeller;
}
//티켓 오피스가 티켓셀러 내부에 존재하는지 모름.
//Theater는 Ticketseller의 인터페이스에만 의존.
//TictketSeller가 TicketOffice 인스턴스를 포함한다는 건 구현에 속함.
public void enter(Audience audience){
ticketSeller.sellTo(audience);
}
}
#자율적
목표 : 고객과 판매원이 내부구현을 외부에 노출하지 않고 자신의 문제를 스스로 책임지고 해결.
-> 자율적인 존재.
1)고객 : 기존에는 극장이 돈있는가? 초대장이 있는가? 였지만, 고객 자체가 Bag를 처리.
-> Audiece를 수정하더라도 TicketSeller에게는 영향을 미치지 않음.
//고객
package C_01.Ticket_after;
public class Audience {
private Bag bag;
public Audience(Bag bag){
this.bag = bag;
}
public Long buy(Ticket ticket){
if(bag.hasInvitation()){
bag.setTicket(ticket);
return 0L;
} else {
bag.minusAmount(ticket.getFee());
bag.setTicket(ticket);
return ticket.getFee();
}
}
}
2)판매원 : Audience의 인터페이스에만 의존함, 고객에게 Buy를 호출하여 결과를 가져오기를 기다림.
//판매상
package C_01.Ticket_after;
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience){
ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
}
}
#개선된 점?
1) 코드를 읽는 사람과 의사소통이라는 관점에서 개선.
2) 객체를 변경하더라도 다른 객체 변경 X(변경용이)
->자신의 문제는 자신이 해결
->다른 객체의 내부를 전부 알필요가 없어짐.
#응집도
밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에 위임하는 객체
->응집도가 높다고 표현.