4부 – WordPress 및 객체 지향 프로그래밍: WordPress 예제 – 디자인

이 시점에서 우리는 이 시리즈의 3부에서 설명한 대로 명확하게 정의된 요구 사항을 가지고 있습니다(놓친 경우 여기에서 확인).

이제 새롭고 개선된 플러그인의 디자인에 대해 생각할 시간입니다!

이 단계를 자신의 프로젝트에서 시도할 때 시간이 오래 걸릴 수 있음을 알려드립니다. 처음에는 모든 것을 제대로 이해하지 못할 수도 있습니다. 디자인을 생각해내고 구현을 시작한 다음 다시 돌아가 접근 방식을 재고해야 한다는 것을 깨닫게 될 가능성이 높습니다.

노력할 가치가 충분하므로 모든 것을 올바르게 수행하는 데 필요한 만큼 많은 시간이 소요됩니다. 잘 구조화된 프로젝트는 유지 및 확장을 더 쉽게 만들고 다른 프로젝트에서 코드를 재사용할 수 있으므로 장기적으로 시간을 잘 활용합니다.

바로 다음으로 플러그인의 일부 핵심 부분에 초점을 맞추고 어떻게 디자인을 생각해 냈는지 논의할 것입니다.

설정 페이지 분석

플러그인의 관리자 페이지를 자세히 살펴보겠습니다.

제목("로그인 시도 제한 설정"), 일부 필드가 포함된 여러 섹션, 페이지 하단에 "옵션 변경" 버튼이 있음을 알 수 있습니다.

각 섹션은 "통계"와 같은 제목과 몇 개의 필드로 구성됩니다.

각 필드의 왼쪽에는 제목이 있고 오른쪽에는 나머지 내용이 있습니다. 텍스트 필드, 라디오 버튼 및 확인란이 있으며 "전체 잠금"과 같은 일부는 정보만 표시하며 관리자가 직접 수정할 수 없습니다.

일부 필드에는 "사이트 연결" 필드와 같은 설명도 포함되지만 전부는 아닙니다.

위의 내용을 염두에 두고 나중에 클래스가 될 개념적 조각으로 분해해야 합니다.

WordPress 설정 API를 사용하면 설정 페이지, 해당 페이지 내의 섹션 및 섹션 내의 필드를 등록할 수 있습니다.

페이지 → 섹션 → 필드

우리는 플러그인을 더 쉽게 확장할 수 있도록 "계층"인 Elements를 하나 더 추가하지 않겠습니까?

페이지 → 섹션 → 필드 → 요소

따라서 페이지 및 섹션은 위에서 이미 설명한 것이며 필드는 오른쪽에 모든 콘텐츠 유형의 요소를 포함합니다.

이러한 모든 다른 종류의 요소를 고려하여 Element 클래스와 여러 클래스를 사용하여 다른 출력을 렌더링할 체크박스, 라디오 버튼, 숫자 등에 대해 확장했습니다.

앞으로 더 많은 페이지와 섹션을 추가해야 할 수도 있습니다. 따라서 이러한 관리 페이지 및 섹션 클래스를 확장해야 할 수 있습니다.

필드도 마찬가지입니다. "전체 잠금", "활성 잠금" 등의 클래스는 동일한(상위) 클래스를 확장합니다.

다음은 이러한 관계를 보여주는 단순화된 시각적 개체입니다.

물론 모든 "구성 요소"가 다이어그램에 포함된 것은 아닙니다.

이와 같은 구조는 플러그인을 확장하기 쉽게 만듭니다. 필요한 경우 필드, 요소 또는 섹션을 쉽게 추가할 수 있습니다. 기존 클래스를 수정할 필요 없이 새 하위 클래스를 만들어 더 많은 구성 요소(필드, 요소 또는 섹션)를 쉽게 추가할 수 있습니다.

생각하고 추상화하기

이제 플러그인의 다양한 구성 요소가 수행하는 작업에 대해 생각할 때입니다. 디자인 단계에서는 작동 방식 에 대해 자세히 설명할 필요가 없습니다.

예를 들어, 모든 요소, 테이블, 통계 및 사용자에게 표시될 거의 모든 것을 고려하십시오. 공통점이 없는 별도의 구성 요소일 수 있지만 결국에는 모두 일부 출력을 렌더링합니다. 따라서 일부 기능은 완전히 관련이 없는 구성 요소에 대해 공통적입니다. 물론 이것은 나머지 구성 요소에도 적용됩니다.

위의 시각적 개체에서 UI 인터페이스가 여러 클래스에 의해 구현되는 방식을 볼 수 있습니다.

UI 인터페이스는 상위 클래스라고 하는 Statistics, Lockout Logs, Table 및 Element 클래스에 의해 구현된다는 점에 유의하십시오. Radio/Number/Checkbox Element 클래스는 부모 클래스에서 모든 인터페이스를 상속하므로 인터페이스를 직접 구현할 필요가 없습니다. 그러나 자식 클래스는 부모 클래스의 메서드를 재정의 할 수 있습니다.

플러그인이 설정을 처리한다는 것을 알고 있기 때문에 해당 값을 읽고 쓸 것이라고 안전하게 가정할 수 있습니다. 즉, 옵션을 가져 오고, 설정 하고, 제거할 수 있습니다.

이러한 모든 작업은 클래스에 함께 묶입니다. 우리는 아마도 WordPress 데이터베이스 또는 이와 유사한 것에 옵션을 저장할 것입니다. 현재로서는 데이터를 저장 하는 방법 이나 위치 에 대해 신경 쓸 필요가 없습니다.

get/set/remove 옵션을 추상화 하여 개념적으로 단순화하고 플러그인을 계속 디자인할 수 있습니다.

메인 플러그인 파일

여기서는 헤더 주석을 통해 WordPress에 플러그인에 대한 정보를 제공하고 일부 초기화를 수행합니다. 우리는 모든 것을 작은 클래스로 래핑하여 코드를 구성할 것입니다.

플러그인의 클래스가 함께 작동하는 방식에 따라 메인 클래스는 대부분을 인스턴스화해야 합니다. 우리가 아는 한 여기에는 옵션, 관리 페이지, 재시도 및 잠금과 관련된 클래스가 포함됩니다.

잠재적 클래스

우리는 어떤 수업이 필요한지 알아내려고 시간을 들이고 다음과 같은 목록을 만들었습니다.

• 재시도
• 잠금
• 쿠키
• 오류 메시지
• 이메일 알림
• 관리자 알림
• 버튼
• 잠금 로그
• 활성/전체 잠금
• IP 주소

플러그인을 구성하는 단 하나의 "올바른" 방법은 없다는 점을 명심하십시오. 소프트웨어 개발의 대부분의 경우와 마찬가지로 문제를 해결하는 여러 가지 동등하게 유효한 방법이 있습니다.

예를 들어 "일반" 섹션에서 클래스 간의 관계는 다음과 같습니다.

"통계" 섹션은 다음과 유사합니다.

마지막으로 "잠금 로그"는 "통계"와 매우 유사합니다.

결론

지금까지 우리는 요구 사항을 정의하고 새롭고 개선된 플러그인에 대한 디자인을 생각했습니다. 우리는 우리가 어떻게 구조를 생각해 냈는지 설명하고 클래스가 서로 어떻게 관련되는지 보여주는 간단한 다이어그램을 제공했습니다.

객체 지향 프로그래밍 시리즈의 5부를 읽으려면 여기를 클릭하십시오.

또한보십시오

• WordPress 및 객체 지향 프로그래밍 – 개요
• 2부 – WordPress와 객체 지향 프로그래밍: 실제 사례
• 3부 – WordPress 및 객체 지향 프로그래밍: Α WordPress 예제 – 범위 정의