วิธี refactor แอปพลิเคชั่นที่มีสวิตช์หลายตัว?

ฉันมีแอปพลิเคชั่นซึ่งรับค่าจำนวนเต็มเป็นอินพุตและยึดตามอินพุตที่เรียกใช้เมธอดสแตติกของคลาสที่ต่างกัน ทุกครั้งที่มีการเพิ่มหมายเลขใหม่เราจำเป็นต้องเพิ่มอีกกรณีและเรียกวิธีการคงที่ที่แตกต่างกันของชั้นเรียนที่แตกต่างกัน ตอนนี้มีสวิตช์อยู่ 50 กรณีและทุกครั้งที่ฉันต้องเพิ่มเคสฉันต้องสั่น มีวิธีที่ดีกว่าในการทำเช่นนี้

ฉันคิดและคิดด้วยความคิดนี้ ฉันใช้รูปแบบกลยุทธ์ แทนที่จะมีตัวเรือนสวิตช์ฉันมีแผนที่ของวัตถุกลยุทธ์โดยมีกุญแจเป็นจำนวนเต็มเข้า เมื่อวิธีการถูกเรียกมันจะค้นหาวัตถุและเรียกวิธีการทั่วไปสำหรับวัตถุ ด้วยวิธีนี้ฉันสามารถหลีกเลี่ยงการใช้โครงสร้างกรณีสวิตช์

คุณคิดอย่างไร?

ตอนนี้มีสวิตช์อยู่ 50 กรณีและทุกครั้งที่ฉันต้องเพิ่มเคสฉันต้องสั่น

ฉันรักความแตกต่าง ฉันรักโซลิด ฉันรักการเขียนโปรแกรมเชิงวัตถุบริสุทธิ์ ฉันเกลียดที่จะเห็นสิ่งเหล่านี้ได้รับตัวแทนที่ไม่ดีเพราะพวกเขาได้รับการประยุกต์ใช้ดันทุรัง

คุณไม่ได้เป็นกรณีที่ดีสำหรับการปรับโครงสร้างกลยุทธ์ การรีแฟคเตอร์มีชื่อตามวิธี มันเรียกว่าเปลี่ยนเงื่อนไขที่มีความแตกต่าง

ฉันพบคำแนะนำที่ตรงประเด็นสำหรับคุณจากc2.com :

เป็นเรื่องที่สมเหตุสมผลหากว่ามีการทดสอบซ้ำหลายครั้งหรือหลายครั้งในลักษณะเดียวกัน สำหรับการทดสอบที่เรียบง่ายและไม่ค่อยจะทำซ้ำการแทนที่เงื่อนไขแบบง่าย ๆ ด้วยคำฟุ่มเฟื่อยของคำจำกัดความหลายชั้นและมีแนวโน้มที่จะย้ายทั้งหมดไกลจากรหัสที่ต้องใช้จริงกิจกรรมที่จำเป็นตามเงื่อนไขจะส่งผลในตัวอย่างตำรา ชอบความชัดเจนมากกว่าความบริสุทธิ์ดื้อรั้น - DanMuller

คุณมีสวิตช์ที่มี 50 เคสและทางเลือกของคุณคือสร้างวัตถุ 50 ชิ้น โอ้และ 50 บรรทัดของรหัสการก่อสร้างวัตถุ นี่ไม่ใช่ความคืบหน้า ทำไมจะไม่ล่ะ? เนื่องจากการปรับโครงสร้างใหม่นี้ไม่ได้ทำอะไรเลยเพื่อลดจำนวนจาก 50 คุณใช้การปรับโครงสร้างนี้ใหม่เมื่อคุณพบว่าคุณจำเป็นต้องสร้างคำสั่งสวิตช์อื่นบนอินพุตเดียวกันที่อื่น นั่นคือเมื่อการปรับโครงสร้างใหม่นี้ช่วยได้เพราะจะเปลี่ยน 100 เป็น 50

ตราบใดที่คุณกำลังอ้างถึง "สวิตช์" เหมือนเป็นสิ่งเดียวที่คุณมีฉันไม่แนะนำสิ่งนี้ ข้อได้เปรียบเพียงอย่างเดียวที่มาจากการปรับโครงสร้างในขณะนี้คือช่วยลดโอกาสที่คนโง่บางคนจะคัดลอกและวางสวิตช์ตัวพิมพ์เล็กและใหญ่ 50 ตัวของคุณ

สิ่งที่ฉันแนะนำคือการมองอย่างใกล้ชิดใน 50 กรณีเหล่านี้สำหรับคนธรรมดาสามัญที่สามารถแยกตัวออกได้ ฉันหมายถึง 50 จริงๆ? คุณแน่ใจหรือว่าต้องการหลายกรณี? คุณอาจพยายามทำอะไรมากมายที่นี่

แผนที่วัตถุทางกลยุทธ์เพียงอย่างเดียวซึ่งเริ่มต้นได้ในฟังก์ชั่นบางอย่างของโค้ดของคุณซึ่งคุณมีโค้ดหลายบรรทัด

     myMap.Add(1,new Strategy1());
     myMap.Add(2,new Strategy2());
     myMap.Add(3,new Strategy3());

คุณและเพื่อนร่วมงานของคุณต้องใช้ฟังก์ชั่น / กลยุทธ์ที่จะถูกเรียกในชั้นเรียนแยกกันอย่างสม่ำเสมอ (เนื่องจากวัตถุกลยุทธ์ของคุณจะต้องใช้อินเทอร์เฟซเดียวกันทั้งหมด) รหัสดังกล่าวมักจะครอบคลุมมากกว่าเล็กน้อย

     case 1:
          MyClass1.Doit1(someParameters);
          break;
     case 2:
          MyClass2.Doit2(someParameters);
          break;
     case 3:
          MyClass3.Doit3(someParameters);
          break;

อย่างไรก็ตามมันจะไม่ปล่อยคุณจากภาระของการแก้ไขไฟล์รหัสนี้เมื่อใดก็ตามที่จำเป็นต้องเพิ่มหมายเลขใหม่ ประโยชน์ที่แท้จริงของวิธีนี้แตกต่างกัน

• การเริ่มต้นของแผนที่ในขณะนี้กลายเป็นแยกออกจากรหัสการจัดส่งซึ่งอันที่จริงเรียกฟังก์ชั่นที่เชื่อมโยงไปยังหมายเลขที่เฉพาะเจาะจงและหลังไม่ได้มีผู้ที่ 50 myMap[number].DoIt(someParameters)ซ้ำอีกมันก็จะมีลักษณะเช่น ดังนั้นรหัสการจัดส่งนี้ไม่จำเป็นต้องแตะเมื่อใดก็ตามที่มีหมายเลขใหม่มาถึงและสามารถใช้งานได้ตามหลักการ Open-Closed ยิ่งไปกว่านั้นเมื่อคุณได้รับข้อกำหนดที่คุณต้องการขยายรหัสการจัดส่งเองคุณจะไม่ต้องเปลี่ยนสถานที่ 50 แห่งอีกต่อไป แต่จะมีเพียงแห่งเดียวเท่านั้น

• เนื้อหาของแผนที่จะถูกกำหนดในเวลาทำงาน (ในขณะที่เนื้อหาของโครงสร้างสวิตช์ถูกกำหนดก่อนที่จะคอมไพล์เวลา) ดังนั้นสิ่งนี้จะทำให้คุณมีโอกาสที่จะทำให้ตรรกะการเริ่มต้นมีความยืดหยุ่นมากขึ้นหรือขยายได้

ดังนั้นใช่มีประโยชน์บางอย่างและนี่เป็นขั้นตอนต่อรหัส SOLID เพิ่มเติม อย่างไรก็ตามถ้ามันจ่ายให้กับ refactor เป็นสิ่งที่คุณหรือทีมของคุณจะต้องตัดสินใจด้วยตัวเอง หากคุณไม่คาดหวังว่ารหัสการจัดส่งจะเปลี่ยนแปลงตรรกะการเริ่มต้นที่จะเปลี่ยนแปลงและความสามารถในการอ่านของswitchไม่ใช่ปัญหาจริงดังนั้นการปรับโครงสร้างของคุณอาจไม่สำคัญในตอนนี้

ฉันขอสนับสนุนกลยุทธ์ที่ระบุไว้ในคำตอบของ @DocBrown@DocBrown

ฉันจะแนะนำการปรับปรุงคำตอบ

การโทรออก

 myMap.Add(1,new Strategy1());
 myMap.Add(2,new Strategy2());
 myMap.Add(3,new Strategy3());

สามารถกระจาย คุณไม่จำเป็นต้องกลับไปที่ไฟล์เดียวกันเพื่อเพิ่มกลยุทธ์อื่นซึ่งปฏิบัติตามหลักการ Open-Closed ที่ดียิ่งขึ้น

สมมติว่าคุณใช้งานStrategy1ในไฟล์ Strategy1.cpp คุณสามารถมีบล็อคของรหัสต่อไปนี้ได้

namespace Strategy1_Impl
{
   struct Initializer
   {
      Initializer()
      {
         getMap().Add(1, new Strategy1());
      }
   };
}
using namespace Strategy1_Impl;

static Initializer initializer;

คุณสามารถทำซ้ำรหัสเดียวกันในทุกไฟล์ StategyN.cpp อย่างที่คุณเห็นนั่นจะเป็นรหัสซ้ำหลายครั้ง เพื่อลดความซ้ำซ้อนของรหัสคุณสามารถใช้เทมเพลตที่สามารถใส่ในไฟล์ที่ทุกStrategyคลาสสามารถเข้าถึงได้

namespace StrategyHelper
{
   template <int N, typename StrategyType> struct Initializer
   {
      Initializer()
      {
         getMap().Add(N, new StrategyType());
      }
   };
}

หลังจากนั้นสิ่งเดียวที่คุณต้องใช้ใน Strategy1.cpp คือ:

static StrategyHelper::Initializer<1, Strategy1> initializer;

บรรทัดที่เกี่ยวข้องใน StrategyN.cpp คือ:

static StrategyHelper::Initializer<N, StrategyN> initializer;

คุณสามารถใช้เทมเพลตไปอีกระดับโดยใช้เทมเพลตชั้นเรียนสำหรับชั้นเรียนกลยุทธ์ที่เป็นรูปธรรม

class Strategy { ... };

template <int N> class ConcreteStrategy;

และจากนั้นแทนการใช้Strategy1ConcreteStrategy<1>

template <> class ConcreteStrategy<1> : public Strategy { ... };

เปลี่ยนคลาสตัวช่วยเพื่อลงทะเบียนStrategys เป็น:

namespace StrategyHelper
{
   template <int N> struct Initializer
   {
      Initializer()
      {
         getMap().Add(N, new ConcreteStrategy<N>());
      }
   };
}

เปลี่ยนรหัสใน Strateg1.cpp เป็น:

static StrategyHelper::Initializer<1> initializer;

เปลี่ยนรหัสใน StrategN.cpp เป็น:

static StrategyHelper::Initializer<N> initializer;