객체지향

객체지향(OOP; Object Oriented Programming)

• 모든 대상을 객체(Object)로 나누고 객체의 행동(Method)과 고유한 값(Attribute)을 정의하여 설계하는 방법

객체지향 구성요소

클래스⭐️⭐️

(20년 1,2,3회 기출)

• 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것
• 공통된 속성과 연산(행위)를 공유하는 객체들의 집합
• 객체지향 프로그램에서 데이터를 추상화하는 단위
• 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
• 다른 클래스와 독립적으로 디자인함
• Super Class는 특정 클래스의 상위클래스
• Sub Class는 특정 클래스의 하위클래스

객체

• 객체는 자신 고유의 속성을 가지며, 클래스에서 정의한 연산을 수행
• 객체의 연산은 클래스에 정의된 연산에 대한 정의를 공유함으로써 메모리를 경제적으로 사용
• 독립적으로 식별 가능한 이름을 가짐
• 객체가 가질 수 있는 조건인 상태는 일반적으로 시간에 따라 변함
• 객체 간 상호연관성에 의한 관계가 형성됨
• 객체는 일정한 기억장소를 가짐

인스턴스

• 클래스에 속한 각각의 객체
• 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화라고함

속성

• 객체들이 가지고 있는 고유한 데이터를 단위별로 정의한 것
• 성질, 분류, 수량, 현재상태 등

메서드

• 어떤 특정한 작업을 수행하기 위한 명령문의 집합
• 객체가 가지고 있는 속성들을 변경할 수 있는 하나의 연산

메시지

• 객체에게 어떤 행위를 하도록 지시하는 명령
• 객체의 메서드를 호출함으로써 객체 간의 상호작용을 할 수 있음

객체지향언어의 특징⭐️

캡슐화(Encapsulation)

(20년 2,3,4회 기출)

• 속성(데이터)과 메서드(함수)를 하나로 묶어 외부와 경계를 만들고 필요한 인터페이스만 노출
• 캡슐화 된 객체의 세부내용은 외부에 은폐(정보은닉)되어 외부 접근이 제한됨
• 정보은닉 측면과 가장 밀접한 관계
• 외부 모듈의 변경으로 인한 오류의 파급효과가 적음
• 재사용 용이, 인터페이스 단순화
• 결합도 감소, 응집도 상승

정보은닉(information hiding)

• 캡슐화의 가장 중요한 개념
• 다른 객체들이 객체 내부 데이터에 직접 접근할 수 없도록 제한하며, 오직 공개된 메서드를 통해서만 내부 상태에 접근할 수 있게 함
• 시스템의 한 부분에서 변경이 발생할 때 다른부분에 미치는 영향을 최소화함으로써 시스템의 유지보수와 확장성을 향상시킴

상속, 일반화(Generalization)

(20년 2회)

• 상위클래스의 모든 속성과 메서드를 하위클래스가 물려받는것
• 하위클래스는 상위클래스의 속성과 메서드를 자신의 클래스에 다시 정의할 필요없음
• 하위클래스는 상속받은 요소 외 새로운 속성과 메서드 추가 가능
• 상위클래스의 요소들을 사용할 수 있으므로, 소프트웨어 재사용을 증대시키는 중요한 개념

다형성(Polymorphism)

(20년 4회)

• 하나의 메시지에 대해 각 객체가 가지고 있는 여러가지 방법으로 응답할 수 있는 개념
• 객체에서 동일한 메서드명을 인자값의 유형이나 개수 등 매개변수만 다르게 하는 오버로딩
• 객체에서 상속 받은 메서드를 재정의하는 오버라이딩
• 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가

추상화(Abstraction)

• 실체의 핵심적인 개념만을 추출하여 간결한 형태로 표현하는 것
• 하위클래스들에 존재하는 공통적인 메서드를 상위클래스 혹은 인터페이스로 정의하고, 하위클래스가 해당 메서드를 재정의할 수 있도로 하는것

집단화(Aggregation)

(20년 1회)

• 서로 관련 있는 여러 개의 객체를 묶어 한 개의 상위 객체를 만드는 것
• 여러 개의 속성을 묶어 사용자 정의형의 엔티티를 만드는 수단으로 사용

객체지향 설계원칙(SOLID)⭐️

단일 책임 원칙(SRP;Single Responsibility Principle)

• 한 클래스는 하나의 책임만을 가져야 한다.

개방 폐쇄 원칙(OCP;Open-Closed Principle)

• 소프트웨어 엔티티는 확장에 대해서는 열려있어야 하지만, 수정에 대해서는 닫혀있어야 한다.
• 기존 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계

리스코프 치환 원칙(LSP;Liskov Substitution Principle)

(20년 2회)

• 자식클래스는 언제나 부모클래스를 대체할 수 있어야 한다.
• 부모클래스가 들어갈 자리에 자식클래스를 넣어도 계획대로 작동해야한다.

인터페이스 분리 원칙(ISP;Interface Segregation Principle)

(20년 4회)

• 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.
• 자신이 사용하지 않는 기능(인터페이스)때문에 영향을 받아서는 안된다.

의존성 역전 원칙(DIP;Dependency Inversion Principle)

• 의존 관계를 맺을 때 자주 변화하는 것보다 변화가 거의 없는 것에 의존해야한다.
• 구체적인 클래스보다 인터페이스나 추상클래스와 의존 관계를 맺어야 한다.