SOLID는 객체 지향 프로그래밍(OOP)에서 코드의 관리 효율성과 확장성을 향상시키기 위해 설계된 기본 원칙 모음입니다. 이는 5가지 핵심 원칙으로 구성됩니다.
이러한 원칙은 로버트 C. 마틴(밥 삼촌이라고도 함)이 2000년대 초반에 도입한 이후 소프트웨어 개발 커뮤니티에서 널리 채택되었습니다. SOLID 원칙을 따르면 개발자는 더 쉽게 이해하고, 수정하고, 확장할 수 있는 코드를 생성하여 더욱 강력하고 유지 관리가 가능한 소프트웨어 시스템을 만들 수 있습니다.
단일 책임 원칙은 OOP와 SOLID의 첫 번째이자 가장 기본적인 원칙입니다. 이름에서 알 수 있듯이 이 원칙은 “하나의 클래스는 하나의 구체적인 책임만 맡아야 한다”는 의미입니다.
invoice라는 클래스가 있다고 가정해 보겠습니다. 여기에는 generateInvoice() 및 saveToFiles() 메소드 2개가 포함되어 있습니다.
public class Invoice { private Long InvoiceNo; public void generateInvoice() { // code to generate Invoice. } public void saveToFiles() { // code to save invoice as a file. } }
Invoice 클래스에는 두 가지 책임이 있으므로 이는 좋은 습관이 아닙니다. 더 나은 접근 방식은 이러한 기능을 전용 클래스로 분리하는 것입니다.
public class Invoice { private Long InvoiceNo; public void generateInvoice() { // code to generate Invoice. } } public class FileManager { public void saveToFiles(Invoice invoice) { // code to save invoice as a file. } }
여기서 사용 사례에 대한 2개의 클래스가 있음을 볼 수 있습니다.
개방-폐쇄 원칙은 SOLID의 또 다른 핵심 원칙입니다. 이 원칙은 1997년 Bertrand Meyer에 의해 도입되었습니다. 이 원칙의 배경이 되는 아이디어는 "소프트웨어 아티팩트(클래스, 모듈 및 기능)는 확장을 위해 열려야 하지만 수정을 위해서는 닫혀 있어야 합니다."
예를 들어
Shape라는 클래스가 있다고 가정해 보겠습니다. 이 클래스를 사용하여 도형의 면적을 계산할 수 있습니다.
public class Invoice { private Long InvoiceNo; public void generateInvoice() { // code to generate Invoice. } public void saveToFiles() { // code to save invoice as a file. } }
위 코드에서 새 모양을 추가하려면 기존 Shape 클래스를 수정해야 하는데 이는 좋은 방법으로 간주되지 않습니다.
아래는 개방-폐쇄 원칙을 이 시나리오에 적용하는 방법을 보여주는 코드 예시입니다.
public class Invoice { private Long InvoiceNo; public void generateInvoice() { // code to generate Invoice. } } public class FileManager { public void saveToFiles(Invoice invoice) { // code to save invoice as a file. } }
OCP를 적용하면 현재 구현을 수정하지 않고도 원하는 대로 많은 모양을 추가할 수 있습니다.
참고: 인터페이스를 사용하는 것이 OCP를 달성하는 유일한 방법은 아닙니다.
Liskov의 대체 원칙은 OOP의 또 다른 중요한 원칙입니다. 이는 1987년 데이터 추상화에 관한 컨퍼런스 강연에서 Barbara Liskov에 의해 소개되었습니다.
이 원칙은 "슈퍼클래스의 객체는 프로그램의 정확성을 변경하지 않고 하위 클래스의 객체로 대체 가능해야 한다"는 것입니다.
예를 들어 Circle과 Rectangle이 Shape의 하위 유형인 경우 Shape 개체를 문제 없이 Circle 또는 Rectangle 개체로 바꿀 수 있습니다.
public class Shape { private String shapeType; private double radius; private double length; private double width; public Shape(String shapeType, double radius, double length, double width) { this.shapeType = shapeType; this.radius = radius; this.length = length; this.width = width; } public double area() { if (shapeType.equals("circle")) { return Math.PI * (radius * radius); } else if (shapeType.equals("rectangle")) { return length * width; } else { throw new IllegalArgumentException("Unknown shape type"); } } } // Usage public class Main { public static void main(String[] args) { Shape circle = new Shape("circle", 5, 0, 0); Shape rectangle = new Shape("rectangle", 0, 4, 6); System.out.println(circle.area()); System.out.println(rectangle.area()); } }
이 예에서 알 수 있듯이 Liskov 대체 원칙을 준수한다는 것은 슈퍼클래스 인스턴스를 하위 클래스 인스턴스로 원활하게 대체할 수 있어야 함을 의미합니다.
인터페이스 분리 원칙은 로버트 C. 마틴이 소개한 5가지 SOLID 원칙 중 하나입니다. "클라이언트가 사용하지 않는 인터페이스에 의존하도록 강요해서는 안 됩니다."라고 명시되어 있습니다.
즉, 하나의 범용 인터페이스를 사용하는 것보다 여러 작업별 인터페이스를 사용하는 것이 더 좋습니다.
아래 예시는 범용 인터페이스의 사용법을 보여줍니다.
public class Invoice { private Long InvoiceNo; public void generateInvoice() { // code to generate Invoice. } public void saveToFiles() { // code to save invoice as a file. } }
MultifunctionPrinter와 같은 범용 인터페이스를 사용하면 불필요한 메서드를 구현하게 되는데, 이는 나쁜 습관으로 간주됩니다. 이 시나리오에 인터페이스 분리 원칙을 적용할 수 있는 방법을 살펴보겠습니다.
public class Invoice { private Long InvoiceNo; public void generateInvoice() { // code to generate Invoice. } } public class FileManager { public void saveToFiles(Invoice invoice) { // code to save invoice as a file. } }
public class Shape { private String shapeType; private double radius; private double length; private double width; public Shape(String shapeType, double radius, double length, double width) { this.shapeType = shapeType; this.radius = radius; this.length = length; this.width = width; } public double area() { if (shapeType.equals("circle")) { return Math.PI * (radius * radius); } else if (shapeType.equals("rectangle")) { return length * width; } else { throw new IllegalArgumentException("Unknown shape type"); } } } // Usage public class Main { public static void main(String[] args) { Shape circle = new Shape("circle", 5, 0, 0); Shape rectangle = new Shape("rectangle", 0, 4, 6); System.out.println(circle.area()); System.out.println(rectangle.area()); } }
ISP를 적용하여 프린터, 스캐너, 팩스와 같은 더 작은 역할별 인터페이스 로 분할했습니다. 이를 통해 각 클래스(예: BasicPrinter, AdvancedPrinter 또는 FaxMachine)는 관련 기능만 구현하여 모듈성을 촉진하고 불필요한 종속성을 줄일 수 있습니다.
의존성 역전 원칙은 SOLID의 최종 원칙입니다. 로버트 C. 마틴이 소개한 내용이기도 합니다. 이는 느슨하게 결합된 코드를 촉진합니다.
DIP에는 몇 가지 사항이 명시되어 있습니다.
간단히 말하면 클래스가 다른 특정 클래스(구체적 구현)에 직접 종속되는 대신 인터페이스 또는 추상 클래스에 종속되어야 합니다. 종속 클래스를 변경하지 않고도 구현을 교체할 수 있으므로 코드가 더욱 유연해지고 유지 관리가 쉬워집니다.
public class Invoice { private Long InvoiceNo; public void generateInvoice() { // code to generate Invoice. } public void saveToFiles() { // code to save invoice as a file. } }
위의 예에서 볼 수 있듯이 Computer 클래스는 Keyboard 클래스에 직접적으로 종속됩니다.
public class Invoice { private Long InvoiceNo; public void generateInvoice() { // code to generate Invoice. } } public class FileManager { public void saveToFiles(Invoice invoice) { // code to save invoice as a file. } }
이제 컴퓨터는 특정 키보드가 아닌 InputDevice 인터페이스에 의존합니다. 이렇게 하면 Computer 클래스를 수정하지 않고도 WirelessKeyboard와 같은 다른 입력 장치로 쉽게 전환할 수 있습니다.
결론적으로 SOLID 원칙: 단일 책임, 개방형, 폐쇄형, Liskov 대체, 인터페이스 분리 및 종속성 반전은 객체 지향 프로그래밍에서 깔끔하고 유지 관리 가능하며 확장 가능한 코드를 작성하기 위한 필수 지침을 제공합니다.
이러한 원칙을 준수함으로써 개발자는 더 쉽게 이해하고, 수정하고, 확장할 수 있는 시스템을 만들 수 있으며 궁극적으로 더 높은 품질의 소프트웨어와 더 효율적인 개발 프로세스로 이어질 수 있습니다.
이 글을 읽어주셔서 감사합니다! 이제 SOLID 원칙과 이를 적용하여 프로젝트를 향상시킬 수 있는 방법을 확실하게 이해하셨기를 바랍니다.
팔로우:
— 사디샤 님사라
위 내용은 견고한 원칙의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!