객체 지향 프로그래밍(OOP)

객체지향프로그래밍(OOP)

객체지향프로그래밍(Object-Oriented Programming, OOP)은 컴퓨터 프로그래밍 패러다임 중 하나로, 프로그램을 객체(Object)라는 개별 단위로 분류하여 여러 객체들 간의 상호작용을 통해 프로그램을 설계하고 구현하는 방법을 말합니다.

객체는 데이터와 해당 데이터를 조작하는 메소드(Method)를 포함하고 있습니다. 객체지향 프로그래밍에서는 이러한 객체들이 간에 상속(Inheritance), 다형성(Polymorphism), 캡슐화(Encapsulation) 등의 개념을 활용하여 프로그래밍을 구현하고고, 이를 통해 모듈화, 재사용성, 유지보수성, 확장성 등의 장점을 제공합니다.

 

객체지향프로그래밍은 대부분의 현대적인 프로그래밍 언어에서 지원하고 있으며, 소프트웨어 개발 분야에서 널리 사용되는 프로그래밍 패러다임 중 하나입니다. 그렇다면 이러한 객체지향프로그래밍을 만들기 위한 방식은 어떻게 되는지 한번 알아 보도록 하겠습니다. 


SOLID 원칙

객체지향 프로그래밍에서 SOLID 원칙은 객체지향프로그래밍을 활용한 좋은 소프트웨어 설계를 위한 다섯 가지 원칙을 의미합니다. 그렇다면 이러한 SOLID가 어떠한 의미를 가지고 있는지 알아보고자 합니다. 

 

  • S: Single Responsibility Principle (단일 책임 원칙)
  • O: Open/Closed Principle (개방-폐쇄 원칙)
  • L: Liskov Substitution Principle (리스코프 치환 원칙)
  • I: Interface Segregation Principle (인터페이스 분리 원칙)
  • D: Dependency Inversion Principle (의존 역전 원칙)

 

https://velog.io/@haero_kim/SOLID-%EC%9B%90%EC%B9%99-%EC%96%B4%EB%A0%B5%EC%A7%80-%EC%95%8A%EB%8B%A4

 

SRP(Single Responsibility Principle) : 단일 책임 원칙(분류)

단일 책임 원칙은 한 클래스는 하나의 책임을 가져야 한다는 원칙입니다. 클래스가 수행하는 일이 많아지면 클래스가 복잡해지고 유지보수가 어려워지기 때문에 이러한 원칙이 필요합니다. 이 원칙은 클래스의 변경 사항이 발생할 때 영향이 미치는 범위를 최소화하며, 코드의 재사용성과 유연성을 높이는 데 도움을 줍니다.

 

MVC 모델 패턴은 표준적인 레이어별 분류를 지원하고 있기 때문에 SRP를 지원하고 있다고 볼 수 있습니다.

 

OCP(Open Close Principle) : 개방 폐쇄 원칙(교체)

개방-폐쇄 원칙은 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다는 원칙입니다. 이 원칙은 변경에 유연하게 대처할 수 있도록 설계를 해야 한다는 것을 의미합니다. 즉, 기존의 코드를 수정하지 않고도 새로운 동작을 추가할 수 있도록 해야 합니다.

 

LSP(Liskov Substitution Principle) : 리스코프 치환 법칙(교체)

자식 클래스는 부모 클래스의 인스턴스로 대체해도 문제가 없어야 한다. 이 원칙은 상속을 사용할 때 발생할 수 있는 문제를 방지하기 위한 것입니다. 부모 클래스의 메서드를 자식 클래스에서 오버라이딩할 때는 부모 클래스의 메서드와 같은 인자와 반환 값을 가져야 합니다.

 

실무에서의 이야기(참고)
실무에서는 의외로 상속을 많이 사용하지 않는다. 
- 상속 시 오버라이드를 한 것과 아닌 것의 혼란 
- 상속 오버라이드를 잘못하면 로직 충돌
- 기능을 너무 확장하거나 변경하면 재활용성 낮아짐 

상속의 대안 또는 상속을 잘 하는 방법 
- 상속을 위한 설계를 한 클래스만 상속하라
- 부모 클래스 상속 대신 인터페이스를 활용하라 
- 피할 수 없다면 상속을 하지만 부모와 상호 치환이 가능하도록 하라 

 

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

클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다라는 원칙입니다. 이 원칙은 자주 사용되는 인터페이스를 더 작은 조각으로 분리하여 각각의 조각이 자신이 필요로 하는 메서드만 가지도록 하는 것을 목표로 합니다.

인터페이스 분리 원칙을 준수하면, 불필요한 의존성을 제거하여 코드의 결합도를 낮출 수 있습니다. 또한 인터페이스가 변경될 때, 영향을 받는 클래스의 수를 최소화하여 유지보수성을 높일 수 있습니다.

 

DIP(Dependency Inversion Principle) : 의존성 역전 원칙(교체)  

의존 역전 원칙(Dependency Inversion Principle, DIP)은 SOLID 원칙 중 하나로, 고수준 모듈은 저수준 모듈에 의존해서는 안된다. 대신에 추상화에 의존해야 한다라는 원칙입니다. 이 원칙은 클래스 사이의 의존성을 역전시키는 것을 목표로 합니다.

보통 클래스 사이의 의존성은 하위 클래스가 상위 클래스에 의존하는 것입니다. 하지만, DIP는 이러한 의존성을 역전시켜 상위 클래스가 하위 클래스에 의존하도록 하는 것입니다. 이는 상위 클래스가 하위 클래스의 구현에 종속되는 것이 아니라, 추상화된 인터페이스에 의존하여 구현이 변경되어도 영향을 받지 않도록 하는 것입니다.


추가적으로..

개발을 하게되면서 알아 두면 좋은 원칙 두가지를 더 알게 되었는데, 그것은 KISS(Keep It Simple Stupid) 와 YAGNI(You Ain't Gonna Need It) 이다. 이에 대한 설명을 먼저 하자면 아래와 같습니다. 

 

KISS(Keep It Simple Stupid)

KISS 원칙은 "간단하게 유지하라, 멍청아"라는 뜻을 가지고 있습니다. 즉, 복잡한 디자인이나 기능을 추가하면서 코드를 복잡하게 만들지 말고, 가능한 한 간단하고 직관적으로 유지하는 것을 권장합니다. 이를 통해 코드의 가독성과 유지보수성을 향상시킬 수 있습니다.

 

YAGNI(You Ain't Gonna Need It)

반면에, YAGNI 원칙은 "당신은 필요하지 않을 것이다"라는 뜻을 가지고 있습니다. 즉, 개발자가 지금 당장 필요하지 않은 기능을 추가하지 않도록 권장합니다. 이는 코드의 복잡성을 증가시키고, 필요하지 않은 기능을 추가하여 코드의 가독성과 유지보수성을 저하시킬 수 있기 때문입니다.

 

두 가지 원칙은 간단하고 직관적인 코드 작성을 추구하며, 필요한 기능만을 구현하여 코드의 복잡성을 줄이고, 가독성과 유지보수성을 향상시키는 것을 목표로 합니다. 이를 통해 개발자는 코드를 더욱 효율적으로 작성할 수 있습니다.

'Language > Java' 카테고리의 다른 글

제네릭스<Generics>  (0) 2023.05.03
Collections Framework  (0) 2023.04.26
JVM GC(Garbage Collection)  (0) 2023.04.13
JVM(Java Virtual Machine)  (0) 2023.04.03
BigInteger, BigDecimal  (0) 2023.03.29