javascript - 유사한 제품 관리 백엔드 페이지를 작성하는 js, 확장 및 유지 관리가 더 쉬운 디자인 패턴은 무엇입니까?
간단한 싱글톤 모드를 사용하여 백그라운드 관리 페이지를 작성했습니다.
와 유사함 으아아아이런 종류의 프로젝트를 작성해 본 경험이 있는 분에게 물어보고 싶습니다. 확장 및 유지 관리를 더 쉽게 하기 위해 코드 구조를 구성하는 방법입니다.
간단한 싱글톤 모드를 사용하여 백그라운드 관리 페이지를 작성했습니다.
와 유사함 으아아아이런 종류의 프로젝트를 작성해 본 경험이 있는 분에게 물어보고 싶습니다. 확장 및 유지 관리를 더 쉽게 하기 위해 코드 구조를 구성하는 방법입니다.
曾经蜡笔没有小新2017-07-05 11:08:52
프로그램의 유지 관리를 위해 일반적인 디자인 패턴을 사용합니다. 특히, 변경되기 쉬운 일부 부분을 예방적으로 처리하기 위해 노력하므로 향후 유지 관리 시 원본 코드가 너무 많이 수정되지 않도록 하며, 특히 로직 코드가 통합되었습니다. 위의 이해를 바탕으로 이제 이에 대해 생각해 볼 수 있습니다. 귀하의 프로젝트에는 많은 추가, 삭제, 수정 및 검색이 필요할 수 있으며 삭제가 더 간단할 수 있으며 특별한 디자인 패턴이 사용되지 않을 것입니다. 증가부터 시작해 보겠습니다:
1. 제품 추가: 다양한 매개변수를 추가하고 프롬프트하는 것에 지나지 않습니다. 예를 들어 처음에는 하나의 제품만 추가할 수 있습니다. , 목록, 텍스트 소개, 슬라이드 등. 그러나 나중에 God의 제품 관리자는 우리가 한 프로젝트가 할랄이 충분하지 않다고 말했습니다. 우리 세계의 재배 사용자는 더 많은 요구 사항이 있을 수 있으며 몇 가지 채우기를 더 추가해야 합니다. 고객이 다양한 사양의 제품을 게시할 때 가격을 표시하는 열을 제공하거나 고객이 다양한 휴일 동안 다양한 할인 가격을 표시할 수 있도록 열을 추가하는 등의 옵션이 있습니다. 결국 요구사항은 더 늘어날 뿐입니다. 나중에 그런 말도 안 되는 일로 짜증을 내고 싶지 않다면 관련 문제를 처리할 수 있는 좋은 디자인 패턴이 필요합니다. 여기서 제공할 수 있는 모드 중 하나는 중간 모드입니다(모듈 간의 결합을 최대한 피할 수 있습니다. 새 열을 추가하려면 캡슐화된 모듈을 중간 함수에 전달하기만 하면 되며 내부 내용은 신경 쓰지 않아도 됩니다.) 이를 처리하는 방법은 통일된 인터페이스를 제공하는 것뿐입니다. 향후에 얼마나 많은 매개변수가 추가되더라도 관련 논리 모듈만 완료하면 됩니다.
2. 여전히 제품 추가 중: 위 기능을 일정 기간 사용한 후 제품 관리자가 황금 비약을 완성하여 자신의 능력을 과시하려고 할 수도 있습니다. 그러나 이번에도 당신은 그 안에 갇혀 있었습니다. 요구 사항은 "다양한 제품 유형에 따라 해당 매개변수 입력 및 선택 기능을 제공하는 것"일 수 있습니다. 예를 들어 전자 제품은 세부 매개변수를 입력해야 하지만 게임 쿠폰은 그렇지 않습니다. 이때 우리가 사용할 수 있고 가장 일반적으로 사용되는 것은 "객체 지향", 즉 템플릿 메서드 패턴이라고도 불리는 단순히 상속과 재작성입니다. 아버지 한 명, 아들 무리, 모호함 없이 타야 할 사람은 타게 될 것입니다. 이 모드는 비교적 간단합니다. 문제는 코드의 복잡성으로 인해 다소 고통스러울 수 있다는 것입니다.
3. 제품 수정: 실제로 대부분의 상황은 새로운 제품을 추가하는 것과 유사하며 특정한 요구 사항을 고려해야 할 수도 있습니다. 예를 들어, 사용자는 현재 제품 정보를 수정하고 있지만 제출 후 즉시 적용되기를 원하지 않으며 향후 언제든지 관련 정보의 공개를 수동으로 제어할 수 있기를 원합니다. 이때 페이지에 정보 게시 상태와 정보 저장 상태 사이를 전환하는 추가 버튼을 제공합니다. 이는 향후 두 가지 상태에서 데이터의 다양한 처리 방법을 구별하는 데 사용됩니다. . 이때, 다양한 전략이나 상태에 따른 행위 방식을 처리하기 위해서는 전략 패턴이나 상태 패턴을 사용해야 할 수도 있습니다.
4. 제품 확인: 가장 간단한 방법은 1번과 마찬가지로 다양한 필터(예: 지역, 유형, 가격 등)를 추가하는 것입니다. 또는 이미 읽은 일부 데이터 콘텐츠에 대해 검색을 수행해야 합니다. 예를 들어 "불멸을 키우고 싶습니다"라는 키워드와 일치하는 제품이 표시되고 나머지는 제거됩니다. 서로 다른 열의 정보를 하나씩 일치시켜야 할 수 있으므로 책임 사슬 모델을 사용할 수 있습니다.
일반적으로 몇 가지 일반적인 디자인 패턴을 나열했지만 실제 개발 과정에서는 더 많은 문제가 발생합니다. 예를 들어 다음과 같습니다. 이제 신제품의 기능을 업데이트해야 하며 요구 사항은 사용자가 새 제품의 경우 사용자가 이전에 유사한 제품 템플릿을 입력했는지 확인하기 위해 테스트를 수행해야 합니다. 그렇다면 사용자에게 이를 직접 적용하라는 메시지가 표시되고, 그렇지 않은 경우에는 사용자에게 메시지가 표시되지 않습니다. 하지만 당신은 이 모듈이 이전에 당신의 동료를 담당했고 당신은 그의 소스 코드를 읽고 싶지 않기 때문에 당신이 재앙을 극복할 것이라고 느낄 수도 있습니다. 관련 코드를 업데이트하세요. 정상적인 기능을 보장하면서 소스 코드를 수정하지 마십시오. . . . . 이와 같은 예는 많이 있으며, 핵심은 일을 올바르게 수행하는 것입니다. 프로젝트를 시작하기 전에 그렇게 많은 것을 고려해야 하는지에 대해서는 단순히 생각할 수 없기 때문에 필요하지 않다고 생각합니다. 때로는 생각하는 것과 실제로 직면하게 될 것 사이에 차이가 있을 수 있습니다. 좀 더 분명한 부분만 선택하세요. 회피, 제가 여러분을 위해 너무 많은 글을 쓴 것과 같지만 좀 더 분명한 부분에만 머물렀고 아직 이런 유형의 프로젝트에 대해서는 글을 쓰지 않았기 때문에 할 수 있습니다. 어떤 구체적인 문제가 발생할지 추측해 보세요. 그러니 패턴 문제에 너무 얽매이지 마세요. 정신을 차리면 코드를 리팩토링하는 것이 더 나을 수도 있습니다.
