Single Responsibility Principle(SRP)
이 원칙은 각 클래스 또는 위젯이 단일 책임을 가져야 한다고 명시합니다. 클래스나 위젯은 하나의 특정 기능을 수행해야 하며 변경할 이유가 너무 많지 않아야 함을 강조합니다.
예: 사용자 정보를 표시하는 위젯과 게시물 목록을 표시하는 별도의 위젯을 만듭니다.
class UserProfileWidget extends StatelessWidget {
// Logic to display user information
}
class PostListWidget extends StatelessWidget {
// Logic to display a list of posts
}
Open/Closed Principle(OCP)
이 원칙은 기존 코드를 수정하는 대신 새 코드를 추가하여 기능을 확장하도록 권장합니다.
예: 전자 상거래 앱에서 다양한 유형의 제품을 표시하는 위젯을 빌드합니다.
abstract class ProductWidget extends StatelessWidget {
// Common logic for displaying products
}
class ElectronicProductWidget extends ProductWidget {
// Logic to display electronic products
}
class ClothingProductWidget extends ProductWidget {
// Logic to display clothing products
}
Liskov Substitution Principle(LSP)
이 원칙은 프로그램의 정확성에 영향을 주지 않으면서 파생 클래스의 개체를 기본 클래스의 개체로 대체할 수 있어야 한다고 주장합니다.
예: 기하학적 모양을 관리하는 위젯을 구성합니다.
abstract class ShapeWidget extends StatelessWidget {
// Common logic for displaying shapes
}
class RectangleWidget extends ShapeWidget {
// Logic to display rectangles
}
class CircleWidget extends ShapeWidget {
// Logic to display circles
}
Interface Segregation Principle(ISP)
이 원칙은 클래스나 위젯이 필요하지 않은 메서드를 강제로 구현하지 않도록 인터페이스를 더 작은 크기로 나눌 것을 권장합니다.
예: 데이터 업데이트 및 표시를 위한 인터페이스.
abstract class Updateable {
void update();
}
abstract class Displayable {
void display();
}
Dependency Inversion Principle(DIP)
이 원칙은 종속성을 관리하기 위해 종속성 주입을 사용하는 것을 제안합니다.
예: 종속성 주입을 사용하여 위젯의 종속성을 관리합니다.
class OrderProcessor {
final DBConnection _dbConnection;
final EmailService _emailService;
OrderProcessor(this._dbConnection, this._emailService);
}
SOLID 에 원칙을 적용하는 것은 Flutter 프로젝트의 특정 목적과 및 에 대한 이해에 따라 유연하게 수행되어야 한다는 점을 SOLID 기억 하십시오 Flutter.