광운 객체지향프로그래밍 부성순 강의목표 강의세부내용

Presentation on theme: "광운 객체지향프로그래밍 부성순 강의목표 강의세부내용"— Presentation transcript:

1 광운 객체지향프로그래밍 2017. 10. 21 부성순 Bakpak@empa.com 강의목표 강의세부내용
객체지향 언어에 대한 정리 C#을 이용한 객체지향 언어 시작 강의세부내용 Ctrl+Shift+왼쪽클릭 캡슐화의 정의 및 사용법 객체지향 설계기법 (SOLID) UML의 정의

2 파이썬 기본문법이해 객체지향 이해 https://opentutorials.org/course/741/4587
Ctrl+Shift+왼쪽클릭

3 = + + Software Program Data Document 소프트웨어 위기론(공급과 수요의 불일치)
* Document에서 중요도:  메뉴얼<소스코드<설계도(UML)     소프트웨어 위기론 극복방안 - 결정적인 발전 없이 느리고 점진적인 변화 - 개발 기술의 낙후 및 부족한 전문 인력 - 개발 예산과 일정을 설정하기 어려움 - 사용자의 요구에 못 미침 - 품질개선이 안됨 - 유지보수가 어려움 - 스파게티 코드를 자제함 - 모듈화 프로그램 - 구조적 프로그래밍 - 4세대 언어(비 절차적 언어) - (재사용성 향상)소프트웨어 공학 - (재사용성 향상)객체지향 기술 - (재사용성 향상)컴포넌트 기반 기술 설계의 품질 - Quality of Design 잘 설계한 시스템은 이해하기 쉽고, 바꾸기 쉽고, 재사용하기 쉽습니다. 개발하는데 특별히 어렵지도 않고, 단순하고 간결하며 경제적입니다. 출처: [소프트웨어 디자인- Design Software by vandbt]

4 (Procedural Oriented: 프로시져 지향)
소프트웨어 가치 사용자가 요구하는 기능을 올바르게 제공 즉. 요구사항에 유연하게 적용가능한 소프트웨어 개발 절차지향 단점 (Procedural Oriented: 프로시져 지향) 추상화된 객체지향 사용 데이터 타입이나 의미를 변경해야 할때, 함께 수정해야 하는 프로시저가 증가한다. 같은 데이터를 프로시저들이 서로 다른 의미로 사용하는 경우가 발생한다.

5 데이테르의 법칙(Law of Demeter) –모듈간 결합도 최소화
캡슐화 객체가 내부적으로 기능을 어떻게 구현하는지 감춤 이를 통해 내부의 기능 구현이 변경되더라도 그 기능을 사용하는 코드는 영향을 받지 않도록 만들어준다. 즉, 내부 구현 변경의 유연함을 주는 기법이다. Tell, Don’t Ask - 데이터를 물어보지 않고, 기능을 실행해 달라고 말하는 규칙 데이테르의 법칙(Law of Demeter) –모듈간 결합도 최소화 - 메서드에서 생성한 객체의 메서드만 호출 - 파라미터로 받은 객체의 메서드만 호출 - 필드로 참조하는 객체의 메서드만 호출

6 캡슐화-Tell, Don’t Ask 예 회원의 서비스 만료 날짜 여부에 따라 서비스를 제공하거나 안내 페이지를 보여줘야 할때, 서비스 만료 날짜 여부를 확인하는 코드는 여러곳에서 사용될 것이다. 회원 정보를 담고 있는 클래스는 아래와 같이 만료 날짜 데이터를 담고 있을 것이다. public class Member { // pass private Date expiryDate; private boolean male; public Date getExpiryDate() { return expiryDate; } public boolen isMale() { return male; Member 객체 정의 private 날짜 형식의 만료일변수 private 블린 형식의 남자변수; public 만료일여부 { public 남자여부 { expiration date (만료일( if (member.getExpiryDate()!=null && member.getExpiryDate().getDate() < System.currentTimeMillis()) { // 만료되었을때 처리코드 } 만료처리 코드예

7 캡슐화-Tell, Don’t Ask 예 만약 여성회원인 경우 만료 기간이 지났어도 30일 간은 서비스를 운영할수 있도록 정책이 변경되었다면 if (member.getExpiryDate()!=null && member.getExpiryDate().getDate() < System.currentTimeMillis()) { // 만료되었을때 처리코드 } 모든 코드 찾아서 변경해야함 long day30=1000*60*60*24*30; //30일 초단위로 계산 if ( ( member.isMale() && member.getExpiryDate()!=null && member.getExpiryDate().getDate() < System.currentTimeMillis()) ) || ( !member.isMale() && member.getExpiryDate()!=null && member.getExpiryDate().getDate() < System.currentTimeMillis()) – day30 )) { //만료되었을때 처리 } expiration date (만료일(

8 캡슐화-Tell, Don’t Ask 예 만료시 true 반환 if (member.isExpired()) {
public class Member { // pass private Date expiryDate; private boolean male; public Date getExpiryDate() { return expiryDate; } public boolen isMale() { return male; public Date isExpired(){ return expiryDate != null && expiryDate.getDate()< System.currentTimeMillis()); 만료시 true 반환 if (member.isExpired()) { //만료에 따른 처리 } expiration date (만료일(

9 캡슐화-데미테르법칙 - 메서드에서 생성한 객체의 메서드만 호출 - 파라미터로 받은 객체의 메서드만 호출 - 필드로 참조하는 객체의 메서드만 호출 public class Member { // pass private Date expiryDate; private boolean male; public Date getExpiryDate() { return expiryDate; } public boolen isMale() { return male; public void processSome(Member member) { if (member.getDate().getTime().. } 파라미터로 받은 객체의 메서드만 호출해야함. member의 getData()뒤에 다시 getTime 안됨  member.somMethod() 로 변경해야함.

10 SOLiD 객체지향 기본이 되는 설계원칙 : SOLID
단일책임원칙(Simgle responsibility principle; SRP) 개방-폐쇄 원칙(Open-closed principle; OCP) 리스코프 치환 원칙(Liskov substitution principle; LSP) 인터페이스 분리 원칙(interface segregation principle; iSP) 의존 역전 원칙(Dependency inversion principle; DIP)

11 객체지향 기본이 되는 설계원칙 : SOLiD 단일 책임원칙(Simgle responsibility principle; SRP)
클래스는 단 한개의 책임을 가져야 한다. (즉 클래스를 변경하는 이유는 단 한개여야 한다 public class DataViever { public void display() { String data=loadHtml(); updateGui(data); } public String loadHtml() { HttpClient client=new HttpClient(); client.connect(url); return client.getResponse(); private void updateGui(String data){ GuiData guiModel=parseDataToGuiData(data) tableUi.changeData(guiModel); private GuiData parseDataToGuiData(String data) { //파싱처리 String를 byte로 변경하면 읽어온 데이터 구조변화 updateGui()파라미터 타입 변화 GuiData 생성하는 코드 변화

12 객체지향 기본이 되는 설계원칙 : SOLiD 단일 책임원칙(Simgle responsibility principle; SRP)
클래스는 단 한개의 책임을 가져야 한다. (즉 클래스를 변경하는 이유는 단 한개여야 한다 데이터 읽기와 데이터를 화면에 보여주는 책임을 두개의 클래스로 분리하고 둘 간에 주고받을 데이터를 저수준의 String가 아닌 알맞게 추상화된 타입을 사용하면 데이터를 읽어오는 부분의 변경 때문에 화면을 보여주는 코드가 변경되는 상황을 막을수 있다.

13 객체지향-추상클래스 & 인터페이스 추상 클래스는 클래스의 명칭과 메서드는 있으나 메서드의 처리 내용은 없다.
상속을 통해서 메서드가 구체화 추상클래스를 상속받은 하위 클래스에서는 추상적인 기능 구현 인터페이스 인터페이스는 상수와 추상 메서드만을 가진다. 클래스는 하나의 상위 클래스로서만 상속받을수 있지만, 인터페이스는 여러개의 인터페잇로부터 상속받을수 있기 때문에 다중 상속의 기능 제공

14 객체지향-추상클래스 & 인터페이스 추상클래스

15 UML(unified modeling language)
용도 객체관련 표준화기구인 OMG에서 1997년에 만든 객체 지향적 분석,설계방법론의 표준 지정 통합 모델링 언어 시스템을 개념적, 물리적으로 표현하는 모델이 필요 객체지향적인 분석과 설계를 위한 표준으로 인정받는 모델링 언어인 UML필요 역사 다이어그램 종류

16 UML 특징 가시화 언어 - UML은 소프트웨어의 개념모델을 시각적인 그래프 형태로 작성
- 표기법에 있어서는 각 심벌에 명확한 정의가 존재 - 개발자들 사이에 오류없는 원활한 의사소통이 가능 명세화 언어 - 명세화란 정확하고, 명백하며, 완전한 모델을 만드는 것을 의미 - UML은 소프트웨어 개발 과정인 분석, 설계, 구현 단계의 각 과정에서 필요한 모델을 정확하고 완전하게 명세화 할수 있는 언어 구축언어 - UML은 Java, C++, Visual Basic과 같은 다양한 프로그래밍 언어로 표현 - 명세화된 설계 모델은 프로그램 소스 코드로 변환하여 구축 가능 - 구축되어 있는 소스를 UML로 역변환하여 분석하는 역공하깅 가능 문서화언어 - 시스템 아키텍처와 이에 대한 모든 상세 내역에 대한 문서화를 다루며, 요구사항을 표현하고 시스템을 테스트하는 언어 제공

17 UML 구성요소

18 UML-구조사물(UML모델의 명사형) - 클래스(자동차) -인터페이스 .배기량/색상/브랜드(속성)
.속도()/멈춤() (오퍼레이션) -인터페이스 클래스 또는 컴포넌트의 서비스를 명세화하는 오퍼레이션을 모아놓은것. (원으로 표현)

19 C#에서의 구조형과 클래스의 비교

20 C#에서의 구조형과 클래스의 비교

21 C#에서 액세스 수준

22 C#에서 액세스 수준