객체지향
코드를 작성할 때 객체가 중심이 돼서 프로그램을 작성하는 것을 일컫는다. 객체가 중심이 돼서
작성한다고 함은 해당 객체를 통해 필요로 하는 속성과 기능을 정의하여 코드를 작성하는 방법을
일컫는다.
예를 들면 나라는 사람에 대해서 코드를 작성한다고 했을 때 속성으로는 이름, 성별, 나이, 몸무
게, 키, 주민등록번호가 속성에 해당되고 기능으로는 걷기, 달리기, 수영, 먹기, 소화하기, 잠자
기 등이 해당한다.
코드를 객체지향적 작성할 때의 장점으로 코드의 재사용성, 코드의 유지와 보수의 장점이 있고 단
점으로 프로그램 설계 시간이 상대적으로 길어지고 실행 속도가 느리다는 점을 들 수 있다.
객체의 3가지 요소
객체 속성
객체는 속성을 갖는다.
객체 기능
객체는 기능을 갖는다.
객체 유일성
객체가 DB에 저장될 때 고유한 ID를 갖는다.
객체지향의 4대 특징
* 캡슐화(1)
객체의 속성을 보호하기 위해서 사용한다. 컴퓨터의 전원을 켜기 위해 메인보드에 직접 전기 신호
로 접근하는 것이 아닌 본체의 전원버튼을 통해 ON/OFF 속성에 접근하는 것이다.
* 캡슐화를 위한 객체 내부 메소드 설계 원칙
- 객체 내부에는 객체 속성을 변경하기 위한 메서드를 제공해야 한다. set method가 대표적
- 제공하려는 서비스로직에 맞추어 기능을 제공해야한다.
- 로그인이 있으면 로그아웃이 있듯이 구현하려는 기능의 양면을 설계할 줄 알아야 한다.
- 객체 안 메서드는 객체 안의 속성만 처리해야 하고 다른 객체를 처리해선 안된다.
- 다른 객체의 속성을 가져오길 원할 경우 클래스 내 객체 선언 후 해당 객체 메서드를 통해
값을 가지고 와야한다.
* example
- 다른 객체에 정의된 속성에 접근할 때에는 해당 객체의 get method나 set method를 통해 접근
해야 한다.
- CRUD Method
데이터 처리를 위한 기본적인 CRUD Method를 제공
- Business Logic Method
비즈니스 로직 처리를 위한 Method 제공
- 객체의 생명 주기 처리 Method
destroy(), disconnect(), quit() 등 소멸에 대한 method
- 객체의 영구성 관리 Method
영구성 속성에 대한 변경이 필요한 경우 외부에서 접근이 불가능 하도록 private로 선언하며,
내부의 다른 Method를 통해서 사용되도록 한다.
* 캡슐화의 장점
객체지향하면 당연하게 생각되어지는 추상화를 제공합니다. Method가 어떻게 동작하는지 외부에서
이해할 필요가 없고 단순 호출만으로 기능을 수행할 수 있어 객체 단위 프로그램 설계가 가능합니다.
계속해서 사용할 수 있습니다. 객체와 관련된 속성과 메서드는 독립된 형태로 제공되기 다른 객체에
영향을 잘 끼치지 않습니다. 따라서 특정 기능을 사용하고 싶은 객체가 있을 때 이미 만들어져 있는
객체를 가져다가 사용하면 되고 또한 해당 객체 내부의 코드에 변경사항이 있다고 하더라도 앞서 말
씀드렸듯이 다른 객체에 영향을 미치지 않으므로 계속해서 사용할 수 있습니다.
이러한 추상화와 재사용성을 제공하므로 작성한 코드를 유지하고 보수하기가 용이합니다.
* 무결성
코드상으로 캡슐화 코딩을 하면 변수는 private으로 선언하고 Method는 public으로 선언하는 형
태를 많이 띄게 됩니다. 이는 객체가 결함이 없음을 유지하는 방식으로 볼 수 있는데 Getter/Set
ter를 제외하고 public method는 입력된 매개변수를 Validation 한 후 실행하는 것을 기본으로
합니다.
Validation을 체크하지 않을 경우 객체가 가진 속성을 유지할 수 없는 경우가 발생할 수도 있기
때문입니다. 예를 들어 입출금을 담당하는 객체가 있다고 했을 때 해당 객체에 메소드로 출금을 담
당하는 기능이 있다고 생각해봅시다. 그랬을 때 매개변수로 특정 금액을 요구하는 금액이 매개변수
로 들어왔는데 그 금액이 해당 객체의 최대 한도를 넘는 금액일 경우 해당 객체로서의 기능을 할 수
없기 때문입니다.
error 체크도 무결성을 위함입니다.
* 상속(2)
객체지향에서의 상속은 하위로 내려갈수록 점점 구체화 된다. 여러 객체를 설계한다고 했을 때 여
러 객체가 갖고 있는 공통적인 속성과 메서드를 추출해서 상속을 받는 형태로 객체를 설계하기 때
문이다. 추상클래스와 인터페이스가 상속의 예이다.
* 상속의 효과
프로그램 구조에 대한 이해도가 향상된다.
최상위 클래스의 구조를 보고, 하위 클래스의 동작을 이해 할 수 있다.
객체를 통해 코드를 다시 사용할 수가 있다. (재사용성 향상)
상속을 통해 클래스에 필요한 속성과 메서드를 모두 정의하지 않고 상속 받아서 사용할 수 있다.
필요한 객체를 추가하기가 용이해진다. (확장성 향상)
서로 다른 여러 객체를 만든다고 할 때 객체 간의 공통적인 부분을 추출해서 속성과 메서드를 정
의하여 상속받는 형태로 프로그램을 설계하기 때문에 서로 다른 특징의 객체를 만들 때 상속을 활
용해서 Override나 Overload를 활용해 서로 다른 특징의 객체를 만들어 낼 수 있다.
객체에 대한 코드를 유지하고 보수하기가 쉬워진다.
공통된 부분을 상속받아서 객체를 설계하기 때문에 특정 객체에 수정 할 부분이 생기게 될 경우 코
드 수정에 많은 시간과 비용이 들어가지 않게 된다.
* 다형성(3)
다형성은 하나의 객체가 상속을 통해 여러형태로 변화할 수 있는 것을 의미합니다. 여러 형태로
변화할 수 있게 오버라이딩을 제공합니다. 오버라이딩이란 상속받는 객체의 메서드를 다시 정의
해서 만들고자 하는 객체에 맞게 커스터마이징 해주는 것을 의미합니다.
* 추상화(4)
객체지향에서 추상화는 모델링이다. 여기서 모델링이란 여러 형태의 객체를 만들고자 할 때 그 분기점에
해당하는 클래스를 설계하는 것을 일컫는다. 따라서 분기되는 지점을 잘 파악하여 여러 객체를 만들고자
할 때 여러 객체가 가진 공통 속성과 기능이 무엇인지 파악하여 작성하는 것이 중요한 부분이다.
객체지향 설계 5원칙 SOLID
응집도와 결합도
좋은 소프트웨어 설계를 위해선 결합도(coupling)는 낮추고 응집도(cohesion)는 높여야 한다.
결합도
모듈 간의 서로 의존하는 정도를 나타내는 지표이다. 결합도가 낮으면 모듈간 서로 의존하는 것이
줄어 들어서 코드를 유지하고 보수하기가 편하다. 왜냐하면 하나 고치면 다른데 안 고쳐도 되기 때
문이다.
응집도
응집도가 높다는 것은 클래스 안에 존재하는 속성과 기능들의 관련성이 높다는 의미이다.
결합도와 응집도와 관련해서 참고할 만한 좋은 링크가 있어서 아래 첨부하도록 하였다.
결합도와 응집도
1. 단일책임원칙 SRP (Single Responsibility Principle)
클래스를 변경해야 하는 이유는 한가지 뿐이어야 한다. 그 것은 하나의 클래스가 여러가지 기능을
가지고 있을 때이다.
따라서 여러가지 기능을 각각의 클래스로 만들어서 모듈화 작업을 수행한다. 그랬을 때 기능에 변
경사항이 생길 경우 해당 모듈만 수정해줌으로써 재사용성 및 유지보수가 쉽다.
2. 개방 폐쇠 원칙 OCP (Open Closed Principle)
자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다. 상위 클래스 또는 인터페
이스를 중간에 둠으로써, 자신은 변화에 대해서는 패쇄적이지만, 인터페이스는 외부의 변화에 대해
서 확장을 개방해 줄 수 있다.
3. 리스코프 치환 원칙 LSP (Liskov Substitution Principle)
자식 타입은 언제나 자신의 기반(상위) 타입으로 교체 할 수 있어야 한다.
4. 인터페이스 분리 원칙 ISP (Interface Segregation Principle)
클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다.
5. 의존 역전 원칙 DIP (Dependency Inversion Principle)
자신보다 변하기 쉬운 것에 의존하지 말아야 한다.
정리
객체지향에 대해 아주 간단하게 알아보았다. 사실 이런 말들은 앞으로 객체를 차차 공부해가면서
조금씩 알아가는 것이 답이고 객체지향에 대해 떠올릴 때 손쉽게 떠올릴 수 있는 용도로 작성된 부
분이 커서 혹시나 해당 글을 읽게 된다면 여러 블로그를 참고하시는 것이 좋을 것 같다.
짧디나 짧은 식견으로 객체지향을 지향하면서 코드를 작성하는 것에 핵심이 뭘까 생각해본다면 객
체부터 만들어 놓고 코딩을 시작해야 하는 것 같고 해당 객체의 변경이 다른 객체에 영향을 미치지
않고 객체를 만드는 것을 지향하는 것이 객체를 지향하는 방법인 것 같다는 것이 현재의 생각이다.
