05.30
프로그램을 만들 때 지향 이 붙으면 그 개념으로 붙여서 만든다.
절차지향은 함수를 만들어 함수를 호출하여 프로그램을 만들었다.
https://www.slideshare.net/ssuser651ced/2-pptx-251931615
객체지향 프로그래밍 정의 ppt
절차지향
절차지향은 이러한 단점이 있다.
- 데이터와 데이터를 다루는 함수가 분리되어 있다.
매번 주소값을 받아와야 했고 쓸대없이 함수가 길어지는 경우가 있다.
- 함수를 이름을 항상 다르게 작성해야 한다.
함수의 이름은 전역 이름공간을 사용하기 때문에 모든 함수 이름을 다르게 해야한다.
컴파일러 왈 '누군지 모르겠어'
- 프로그램을 확장하기 어렵다.
프로그램에 수정 사항이 생기면 변경 사항이 많아짐. > 이를 위해서 함수 포인터를 사용했음 > 귀찮음
객체지향이 만들어진 이유는 프로그램 유지보수가 힘들기 때문이다.
이제부턴 객체지향을 이용해 해보겠다.
객체
객체는 데이터 영역이다 (변수 등의 집합체)
객체지향 프로그래밍의 주요개념 4가지
캡슐화
데이터와 데이터를 조작하는 메소드(함수)를 같이 작성하는 것이다.
사용자 정의 타입에 알고리즘과 그에 필요한 데이터를 한 번에 작성할 수 있는 것
상속
코드를 물려받는 것
코드 재사용이 가능하다
추상화
구현 세부정보를 숨기는 일반적인 인터페이스를 정의하는 행위
메소드가 데이터를 가져다가 조작하는 행위가 있어야 함
서로 다른 부분이 만나고 소통하거나 서로에게 영향을 미치는 영역
다른 사용자가 사용하기 쉽게 만드는 것이 좋다.
프로그램을 빠르고 편리하게 작성하기 위한 방법
함수를 얼마나 잘 만드느냐? 에 따라 추상화가 잘됬는지 안됬는지 알 수 있다.
다형성
같은 인터페이스를 사용하되 다른 세부 구현 사항을 가질 수 있는 성질
구현의 새부 사항이 다르다.
가상함수는 인터페이스를 유지한 채로 구현 세부사항을 바꿀 수 있다. 이를 오버라이딩 이라 한다.
객체지향 프로그래밍의 핵심!.
객체지향이 되면 어떤 변화가 있는가?
쓸대없는 분기문이 사라진다.
클래스 안에 정의된 함수를 메소드 라 하고 데이터 부분은 필드 라고 한다.
객체지향적 설계
메소드는 기능을 표현
필드는 그 기능을 구현하기 위한 데이터를 표현
기능을 우선적으로 생각하고 기능을 구현하기위해 무엇이 필요한가 생각하자
적절할 객체에게 적절한 책임을 부여하는 것에서 시작
책임 주도 설계
협력
요청과 응답으로 구성되어 있다.
소프트웨어의 기능은 더 작은 책임으로 분할되고 책임은 적절한 역할을 가진 객체에 의해 수행된다
협력이 성공하려면 특정한 역할을 맡은 각 개인이 얼마나 요청을 성실히 이행할 수 있는지에 달렸다.
책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소이며, 역할은 유연하고 재사용 가능한 협력 관계를 구축하는데 중요한 설계요소이다.
객체
객체지향 프로그래밍에서 객체(object)는 상태(state)와 행동(behavior)을 함께 지닌 실체이다.
객체는 충분히 협력적이어야 합니다.
다른 객체의 요청을 잘 처리해야 하고
다른 객체에 적극적으로 도움을 요청할 줄 알아야 합니다.
'모듈화를 잘 해라' 라고 요약할 수 있다.
객체는 충분히 자율적이어야 합니다.
요청에 응답하는 방식은 객체가 스스로 판단하고 결정해야 한다.
요청으 응할지 여부도 스스로 결정해야 한다.
다형성 부분을 의미한다.
객체 내부와 외부를 잘 구분해야 한다.
객체의 내부는 객체 스스로 관리하고 외부에서 일체 간섭할 수 없도록 해야한다.
객체에 외부에서는 접근이 허락된 수단을 통해 의사소통하게 된다.
객체가 역할을 가진다는건 아래와 같다
여러 객체가 동일한 역할을 수행할 수 있다.
역할은 대체 가능성을 의미한다.
각 객체는 책임을 수행하는 방법을 자율적으로 선택할 수 있다
하나의 객체가 동시에 여러 역할을 수행할 수 있다.
책임
객체가 어떤 행동을 하는 이유는 다른 객체로부터 요청을 수신했기 때문이다.
요청을 처리하기 위해 객체가 수행하는 행동을 책임이라 할 수 있다.
소프트웨어를 객체지향적으로 설계할 때는
1. 소프트웨어의 기능을 명세
2. 기능을 수행하기 위한 협력 관계를 구축해야 한다.
기능을 수행할 수 있게 여러 책임으로 나누고 각 객체에 부여하여 협력하게 만들어야 한다.
책임은 객체가 '어떻게' 해야 하는가가 아니라 '무엇' 을 해야 하는가를 설명한다.
책임은 수행방법을 제한할 정도로 구체적이어도 안되고 협력의 의도를 명확하게 표현하지 못할정도로 추상적이어도 안된다.
책임은 역할이라고도 할 수 있다.
메시지
객체지향 세계에서의 유일한 의사소통은 메시지 이다.
객체지향의 세계에서 협력은 메시지를 전송하는 객체와 메시지를 수신하는 객체 사이의 관계로 구성된다.
메시지를 전송하는 객체를 송신자.
메시지를 받는 객체를 수신자 라 한다.
객체가 수신된 메시지를 처리하는 방법을 메소드 라고 부른다.
외부의 요청이 무엇인지 표현하는 메시지와 요청을 처리하기 위한 구체적인 방법인 메소드를 분리하는 것이 객체의 자율성을 높히는 방법이다.
다시말해 가상함수를 잘 쓰라는 이야기다.
다형성에 대한 재해석
객체가 어떤 방법으로 처리하던지 송신자는 관심없으며 수신자가 메시지를 받을 수 있기만 하면 된다.
메시지는 송신자와 수신자 사이의 결합도를 낮춤으로써 설계를 유연하고, 확장 가능하고, 재사용 가능하게 만든다.
따라서 설계의 품질을 높이기 위해서는 훌륭한 메시지를 선택해야 한다.
정리
객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법이다.
자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미한다.
객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
객체는 다른 객체와 협력하기 위해 메시지를 전송하고 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메소드를 자율적으로 선택한다.
코드를 담는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 사고의 중심을 전환해야 한다.
중요한 것은 어떤 클래스가 필요한가가 아니라 어떤 객체들이 어떤 메시지를 주고받으며 협력하는가다. 클래스는 객체 간 협력 관계를 코드로 옮기는 도구에 불과하다.
객체지향의 핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다.
어떤 협력관계 어떤 메시지들을 주고받에 해야 내가 원하는 기능을 구현할 수 있을까 를 고민해야한다. 어떤 클래스가 필요한가 가 아니라 어떤 객체들이 메시지를 주고받는지를 고민하는것이 좋다.
SOLID 원칙
단일 책임원칙
각 소프트웨어 모듈은 변경의 이유가 하나여야 한다.
각 객체는 단 하나의 책임만 들고있어야 유지보수하기 편하다.
개방-폐쇄법칙
객체는 확장에는 열려있어야하고 변경에는 닫혀있어야 한다는 원칙
쉽게 기능을 추가할 수 있어야하고 데이터를 직접 다루지 말라는. 데이터를 다루는것 메소드가 한다.
캡슐화를 잘 하라는 의미
리스코프 치환 원칙
하위 타입에 관한 원칙으로 프로그램 P에서 T 타입의 객체 자리에 S 타입의 객체로 모두 치환하더라도 P의 행위가 변하지 않는다면 S는 T의 하위 타입이라는 것이다.
상속과 관련이 있다.
상속을 할때는 is-a 관계가 되어야 한다. (자식클래스) is a (부모클래스) 가 만족해야한다.
인터페이스 분리 원칙
어떤 타입이 다른 타입에 의존한다고 할 때 필요한 인터페이스만을 분리해 의존하게 설계하라는 원칙.
다시 말하자면 결합도를 메시지 수준으로 낮추라는 것
의존성 역전 원칙
고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안되며, 세부사항이 정책에 의존해야 한다는 원칙이다.
새로운 클래스가 생기더라도 의존성 역전 원칙을 따르면 푸른색 박스안의 내용은 변하지 않는다.
다시 말하자면 다형성을 적극적으로 활용하라는 얘기다.
