경영정보시스템 코드설계에서 코딩의 목적은 무엇인가?

코딩의 목적은 독특함, 표준화, 체계화입니다. 코드는 다양한 객관적 개체를 표현하기 위해 숫자나 문자를 사용합니다. 시스템 개발 과정에서 코드를 설계하는 목적은 고유성, 표준화, 체계화입니다.

코드는 다양한 객관적 개체를 나타내기 위해 사용됩니다.

1. 표준화;

코드 디자인의 6가지 원칙

단일 책임 원칙

정의: 클래스나 인터페이스는 단 하나의 책임만을 담당하는 것이 가장 좋습니다. 문제의 원인: 클래스 T는 두 가지 다른 책임 P1과 P2를 담당합니다. 책임 P1을 변경하고 T 클래스를 수정해야 하기 때문에 원래 정상적으로 실행되던 책임 P2의 기능이 오작동할 수 있습니다.

해결책: 단일 책임 원칙을 따르세요. 해당 책임에 해당하는 새 클래스를 생성하세요. 이렇게 하면 클래스 수정이 다른 책임에 영향을 미치는 것을 피할 수 있습니다.

책임이 급증할 때 논리가 충분히 단순한 경우에만 코드 수준에서 단일 단위를 위반할 수 있습니다. 책임 원칙은 클래스의 메서드 수가 충분히 작은 경우에만 메서드 수준에서 단일 책임 원칙을 위반할 수 있습니다.

이점: 클래스의 복잡성이 줄어들고 가독성이 크게 향상됩니다. 유지보수성도 향상됩니다.

Liskov 대체 원칙

기본 클래스가 사용되는 경우 해당 하위 클래스를 임의로 사용하여 하위 클래스가 기본 클래스를 완벽하게 대체할 수 있도록 할 수 있습니다. 이 정신은 실제로 상속 메커니즘의 제약 조건과 사양을 구현한 것입니다. 상위 클래스 및 하위 클래스의 특정 구현에서 상속 계층의 관계 특성은 기본 클래스를 하위 클래스로 대체할 때 프로그램 동작이 문제를 일으키지 않고 정상적으로 계속될 수 있도록 엄격하게 제어됩니다. 상속의 경우 상위 클래스는 일련의 사양과 계약을 정의합니다. 모든 하위 클래스가 준수해야 하는 것은 아니지만 하위 클래스가 이러한 비추상적 메서드를 임의로 수정하면 전체 상속 시스템에 손상을 줄 수 있습니다.

부모 클래스의 메서드를 다시 작성해야 하는 경우 더 일반적인 방법은 원래 부모 클래스와 하위 클래스가 모두 더 인기 있는 기본 클래스를 상속하고 원래 상속 관계를 제거하고 종속성, 집계, 조합 및 기타를 사용하는 것입니다. 관계 대체;

원칙에는 다음과 같은 네 가지 의미 수준이 포함됩니다.

* 하위 클래스는 상위 클래스의 추상 메서드를 구현할 수 있지만 상위 클래스의 비추상 메서드를 재정의할 수는 없습니다.

* 하위 클래스 메서드가 상위 클래스 메서드를 재정의하는 경우 메서드의 형식 매개변수는 상위 클래스 메서드의 입력 매개변수보다 더 완화됩니다.

* 하위 클래스 메서드가 상위 클래스의 추상 메서드를 구현하는 경우 , 메소드의 반환 값은 상위 클래스보다 더 엄격합니다.

종속 반전 원칙

정의: 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해서는 안 됩니다. 세부 사항은 추상화에 의존해야 하며 그 핵심은 추상화에 의존하는 것입니다.

문제의 원인: 클래스 A는 클래스 B에 직접적으로 의존합니다. 클래스 A를 클래스 C에 의존하도록 변경하려면 다음을 수행해야 합니다. 클래스 A의 코드를 수정합니다. 이 시나리오에서 클래스 A는 일반적으로 복잡한 비즈니스 로직을 담당하는 상위 수준 모듈이고, 클래스 B는 클래스 A가 수정되는 경우 하위 수준 모듈입니다. 이는 프로그램에 불필요한 위험을 가져올 것입니다. 해결 방법: 클래스 A를 수정하여 인터페이스 I에 의존합니다. 클래스 B와 클래스 C는 각각 인터페이스 I을 구현합니다. 클래스 A는 인터페이스 I를 통해 클래스 B와 클래스 C에 간접적으로 연결하므로 클래스 A를 수정할 가능성이 줄어듭니다. , 일반적으로 다음 세 가지 작업을 수행해야 합니다.

* 하위 수준 모듈에는 추상 클래스나 인터페이스, 또는 둘 다 있어야 합니다.

* 선언된 변수 유형은 가능한 한 추상 클래스나 인터페이스여야 합니다.

* 상속을 사용할 때는 Liskov 대체 원칙을 따르세요.

인터페이스 분리 원칙

정의: 클라이언트는 필요하지 않은 인터페이스에 의존해서는 안 됩니다. 한 클래스의 다른 클래스 의존성은 가장 작은 인터페이스를 기반으로 해야 합니다. 인터페이스 오염을 유발합니다. 클래스 A는 인터페이스 I을 통해 클래스 B에 종속되고 클래스 C는 인터페이스 I을 통해 클래스 D에 종속됩니다. 인터페이스 I가 클래스 A와 클래스 B의 최소 인터페이스가 아닌 경우 클래스 B와 클래스 D는 이를 구현해야 합니다.

원칙의 의미는 다음과 같습니다. 단일 인터페이스를 구축하고, 거대하고 비대한 인터페이스를 구축하지 말고, 인터페이스를 개선하고, 인터페이스에 가능한 적은 메소드를 사용하도록 노력하십시오. 즉, 각 클래스마다 전용 인터페이스를 설정해야 합니다. 이를 사용하여 호출하는 모든 클래스에 대해 거대한 인터페이스를 구축하려고 하지 마세요.

인터페이스는 가능한 한 작아야 합니다. 인터페이스를 개선하면 프로그래밍 유연성이 향상될 수 있지만 너무 작으면 인터페이스 수가 최소화되어 설계가 복잡해집니다. 따라서 인터페이스에 의존하는 클래스에 대해 서비스를 맞춤화하고, 호출 클래스에 필요한 메서드만 노출하고, 필요하지 않은 메서드는 숨기도록 하세요.

규칙:

* 인터페이스는 하나만 제공합니다. 하위 모듈 또는 비즈니스 로직, 서비스 사용자 정의

* 비즈니스 로직을 통해 인터페이스의 공개 메소드를 압축하여 인터페이스를 더욱 간소화합니다.

* 오염된 인터페이스를 최대한 수정하세요. 변경 위험이 너무 크면 변환을 위해 어댑터 모드를 사용하세요.

* 특정 비즈니스에 따라 로직을 깊이 이해하고 디자인 아이디어를 마음으로 제어하세요.

인터페이스 격리를 구현하는 방법에는 두 가지 주요 방법이 있습니다.

1. 위임 분리는 고객의 요청을 위임하기 위한 새로운 인터페이스 유형을 추가하여 고객과 인터페이스의 직접적인 종속성을 분리합니다.

2. 다중 상속 분리, 인터페이스의 다중 상속을 통해 고객 요구 실현

Dimit의 법칙

정의: 객체의 핵심 정신은 다음과 같습니다. 일반인의 관점에서 낯선 사람과 대화하지 마십시오. 이는 객체가 호출을 위해 결합 및 연관되어야 하는 클래스에 대해 더 적게 알아야 함을 의미합니다. 이는 클래스 간의 결합 정도를 감소시키며 각 클래스는 시도합니다. 다른 클래스에 대한 의존성을 줄이기 위해.

합성과 재사용의 원리

상속을 사용하는 대신 합성/집합을 최대한 사용하는 것이 원칙입니다.

열기 및 닫기 원리

정의: 클래스, 템플릿 및 템플릿과 같은 소프트웨어 엔터티입니다.

해결책: 소프트웨어를 변경해야 하는 경우 기존 코드를 수정하는 대신 소프트웨어 엔터티의 동작을 확장하여 변경을 달성하도록 노력하세요.

• 단일 책임 원칙: 구현 클래스

• 리히터 대체 원칙: 상속 시스템을 파괴하지 마세요.

• 종속성 반전 원칙: 인터페이스 지향 프로그래밍; 인터페이스 격리 원칙: 인터페이스를 설계할 때 단순해야 합니다.

Dimit 규칙: 결합을 줄입니다.
개폐 원리: 일반 개요, 확장 가능, 수정 불가

• 더 많은 관련 지식을 보려면

  PHP 중국어 웹사이트
를 방문하세요.

위 내용은 경영정보시스템 코드설계에서 코딩의 목적은 무엇인가?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!