OOP OOP 객체지향 객체지향 많이 썼지만 추상적인 부분이 많다.
객체지향의 특징을 한번 정리해보자!
1. OOP란?
OOP (Object-Oriented Programming)이란 객체 지향적인 프로그래밍. 즉, C언어같은 절차 지향적인 프로그래밍이 아닌 객체의 관점에서 프로그래밍을 한다는 것이다.
OOP는 객체를 기준으로 코드를 나누어 구현한다. c++의 경우 그 구성 부분 단위가 클래스이다. 자세히 말하자면 클래스는 설계도고 직접일을하는 구현체는 인스턴스다.
물이 위에서 아래로 흐르는 것처럼 순차적인 처리가 중요시 되며 프로그램 전체가 유기적으로 연결되도록 만드는 프로그래밍 기법입니다.
OOP 특징 5가지.
캡슐화, Encapsulation 💊 ...
은닉화, Information hiding 🥷 ...
상속, Inheritance 👪 ...
추상화, Abstraction ⛰️ ...
다형성, Polymorphism 🎭 ...
총 6가지인데 하나씩 가볍게 살펴보자.
1. 캡슐화 (Encapsulation)
하나의 객체에 대해 그 객체가 특정한 목적을 위한 필요한 변수나 메소드를 하나로 묶는 것을 의미한다.
클래스 안에 변수나 함수 묶어서 사용하는데 그게 캡슐화.
2. 은닉화
캡슐화를 하는 중요한 목적은 바로 정보은닉이다.
public, private, protected같이 클래스 내부에서 변수나 함수 선언할 때, 데이터의 상태를 정해줄수 있다.
3. 추상화
추상화는 목적과 관련이 없는 부분을 제거하여 필요한 부분만을 표현하기 위한 개념이다.
추상화가 머냐면, 기억이 안난다. 함수 선언 할때 0을 넣는거 처럼 아무것도 함수에 아무것도 안넣고 비워둔다. 왜냐, 자식클래스에 상속하면 자식클래스마다 다른 내용들을 넣어 주려고 이렇게 상속할 때 자식에서 모두 다르게 쓰는 데이터라면 추상화만 해두고 쓰는게 좀더 효율적이다.
4. 다형성(Polymorphism)
다형성은 상속을 통해 기능을 확장하거나 변경하는 것을 가능하게 해준다. 즉, 다형성은 형태가 같은데 다른 기능을 하는 것을 의미한다(같은 동작이지만 다른 결과물이 나올때 다형이라고 생각하면 된다.).
이를 통해 코드의 재사용, 코드 길이 감소가 되어 유지보수가 용이하도록 도와준다.
오버로딩, 오버라이딩도 이러한 다형성의 특성중 하나다.
5. 상속성, 재사용(Inheritance)
예를 들면 동물의 특성이 있는 객체가 있다면, 고양이 강아지 처럼 모든 동물에 해당하는 객체에 상속시켜주면 쉽게 구현할 수 있다.
OOP 원칙 5가지.
단일 책임 원칙(Single responsibility principle) - 약어: SRP
개방 폐쇄 원칙(Open/closed principle) - 약어: OCP
리스코프 치환 원칙(Liskov substitution principle) - 약어: LSP
인터페이스 분리 원칙(Interface segregation principle) - 약어: ISP
의존관계 역전 원칙(Dependency inversion principle) - 약어: DIP
이런게 있는지 전혀 몰랐다. 그냥 쓴거지. 솔직히 이런거 몰라도 OOP 코드 설계하는데 전혀 문제없었는데, 면접용 또는 학업용으로 알면 좋겠다. 라고 말하면 엄청 혼나겠지;
위 원칙을 맞춰서 코드 작성하는걸 지향해야한다. 이거 안맞추고 코드 작성했다가 깐깐한 사람들 만나면 엄청 까인다. 유의하자.
사실 대규모 환경이 아니라면 굳이 안맞춰도 된다고 생각하지만, 대규모 환경에서 개발한다고 가정하면 원칙을 지키지 않아 사용할때마다 확인해야하고 번거로운 일이 발생할거다.
선임들이 열심히 지켜서 짰는데 안지키는 신입 보면 화날만하다. 후후훗.
혼나기 싫으면 잘 봐두자고!
1. 단일 책임 원칙
객체를 작성할 때, 하나의 객체가 하나의 특성만 담고 있어야한다.
예를 들면 자동차라는 객체가 있다면, start나 stop같이 자동차의 특성에 관한건만 넣어주고, carWash같은 내용은 Wash의 객체에 넣어주는 식으로 설계하자.
2. 개방폐쇄 원칙
객체를 확장함에 있어 개방적, 반대로 수정함에 있어 폐쇄적이란다.
왜~!!? 객체의 기능을 확장하는건 좋은 거니까 긍정적이고, 수정의 경우 만약 객체의 메소드를 하나 수정하면, 해당 메소드를 활용한 다른 부분에서 문제가 발생할 수 있다. 그래서 객체를 활용할 땐 최대한 확장하는 형태로 구현하자!
3. 리스코프 치환 원칙
부모를 인스턴스로 만들어 사용하는 부분은 자식으로 치환해 사용가능하다.
4. 인터페이스 분리 원칙
객체는 자신이 호출하지 않을 메소드는 가지고 있지 않길 권장한다.
예를 들어 자식에서 쓰지 않을 메소드를 굳이 자식에게 상속시켜주지말자.
만약 부모가 너무 크다면 쪼개서 관리하자!
5. 의존관계 역전 원칙
의존관계 역전 원칙(dependency inversion principle)은 "추상화에 의존해야지, 구체화에 의존하면 안된다"
부모에서 메소드로 값같은거 받도록 정의 해두지말고, 자식에서 정의 할수 있도록 추상화 하는걸 권장한다.
후기
소규모 프로젝트라면 굳이 위 원칙을 지킬 필요는 없다고 생각한다. 솔직히 함수 쪼개는 것도 시간 걸리고 원칙에 맞춰 설계하는것도 꽤나 공을 들여야 하는 작업이다.
하지만 다른사람과 협업해야하는 환경에서는 꼭 지키도록 노력해야한다. 내가 안맞다고 원칙없이 짜버리면 다른사람이 힘들어진다.
