Thiết kế giao diện nơi các chức năng cần được gọi theo một trình tự cụ thể

Nhiệm vụ là cấu hình một phần cứng trong thiết bị, theo một số đặc điểm kỹ thuật đầu vào. Điều này cần đạt được như sau:

1) Thu thập thông tin cấu hình. Điều này có thể xảy ra ở những thời điểm và địa điểm khác nhau. Ví dụ, mô-đun A và mô-đun B có thể yêu cầu (tại các thời điểm khác nhau) một số tài nguyên từ mô-đun của tôi. Những "tài nguyên" đó thực sự là cấu hình.

2) Sau khi rõ ràng rằng sẽ không có thêm yêu cầu nào được thực hiện, một lệnh khởi động, đưa ra một bản tóm tắt các tài nguyên được yêu cầu, cần phải được gửi đến phần cứng.

3) Chỉ sau đó, có thể (và phải) cấu hình chi tiết của các tài nguyên nói trên được thực hiện.

4) Ngoài ra, chỉ sau 2), có thể (và phải) định tuyến các tài nguyên đã chọn đến người gọi được khai báo.

Một nguyên nhân phổ biến cho các lỗi, ngay cả đối với tôi, người đã viết điều này, đang nhầm lẫn thứ tự này. Những quy ước, thiết kế hoặc cơ chế đặt tên nào tôi có thể sử dụng để làm cho giao diện có thể sử dụng được bởi người lần đầu tiên nhìn thấy mã?

Đây là một thiết kế lại nhưng bạn có thể ngăn chặn việc sử dụng sai nhiều API nhưng không có sẵn bất kỳ phương thức nào không nên gọi.

Ví dụ, thay vì first you init, then you start, then you stop

Hàm tạo của bạn initlà một đối tượng có thể được bắt đầu và starttạo một phiên có thể dừng lại.

Tất nhiên, nếu bạn có một hạn chế đối với một phiên tại một thời điểm, bạn cần xử lý trường hợp ai đó cố gắng tạo một phiên với một phiên đã hoạt động.

Bây giờ áp dụng kỹ thuật đó cho trường hợp của riêng bạn.

Bạn có thể có phương thức khởi động trả về một đối tượng là tham số bắt buộc cho cấu hình:

Tài nguyên * MyModule :: GetResource ();
MySession * MyModule :: Startup ();
void Resource :: Configure (phiên MySession *);

Ngay cả khi bạn MySessionchỉ là một cấu trúc trống, điều này sẽ thực thi thông qua loại an toàn mà không có Configure()phương thức nào có thể được gọi trước khi khởi động.

Dựa trên câu trả lời của Cashcow - tại sao bạn phải trình bày một Đối tượng mới cho người gọi, khi bạn có thể trình bày một Giao diện mới? Mô hình Rebrand:

class IStartable     { public: virtual IRunnable      start()     = 0; };
class IRunnable      { public: virtual ITerminateable run()       = 0; };
class ITerminateable { public: virtual void           terminate() = 0; };

Bạn cũng có thể để ITerminatizable triển khai IRunnable, nếu một phiên có thể được chạy nhiều lần.

Đối tượng của bạn:

class Service : IStartable, IRunnable, ITerminateable
{
  public:
    IRunnable      start()     { ...; return this; }
    ITerminateable run()       { ...; return this; }
    void           terminate() { ...; }
}

// And use it like this:
IStartable myService = Service();

// Now you can only call start() via the interface
IRunnable configuredService = myService.start();

// Now you can also call run(), because it is wrapped in the new interface...

Theo cách này, bạn chỉ có thể gọi đúng phương thức, vì ban đầu bạn chỉ có Giao diện IStartable-Giao diện và sẽ chỉ có thể truy cập Phương thức run () khi bạn đã gọi start (); Nhìn từ bên ngoài, nó trông giống như một mẫu có nhiều lớp và Đối tượng, nhưng lớp bên dưới vẫn là một lớp, luôn được tham chiếu.

Có rất nhiều cách tiếp cận hợp lệ để giải quyết vấn đề của bạn. Basile Starynkevitch đã đề xuất một cách tiếp cận không quan liêu, không để lại cho bạn một giao diện đơn giản và dựa vào lập trình viên bằng cách sử dụng giao diện một cách thích hợp. Trong khi tôi thích cách tiếp cận này, tôi sẽ trình bày một cách khác có nhiều tính năng hơn nhưng cho phép trình biên dịch bắt được một số lỗi.

1. Xác định các trạng thái khác nhau thiết bị của bạn có thể ở, như Uninitialised, Started, Configuredvà vân vân. Danh sách này phải là hữu hạn.¹

2. Đối với mỗi trạng thái, xác định structviệc giữ thông tin bổ sung cần thiết có liên quan đến trạng thái đó, ví dụ DeviceUninitialised, DeviceStartedv.v.

3. Đóng gói tất cả các nghiệm thức trong một đối tượng DeviceStrategytrong đó các phương thức sử dụng các cấu trúc được xác định trong 2. làm đầu vào và đầu ra. Do đó, bạn có thể có một DeviceStarted DeviceStrategy::start (DeviceUninitalised dev)phương thức (hoặc bất cứ điều gì tương đương có thể theo các quy ước dự án của bạn).

Với phương pháp này, một chương trình hợp lệ phải gọi một số phương thức trong chuỗi được thi hành bởi các nguyên mẫu phương thức.

Các trạng thái khác nhau là các đối tượng không liên quan, điều này là do nguyên tắc thay thế. Nếu nó hữu ích cho bạn khi các cấu trúc này có chung một tổ tiên chung, hãy nhớ rằng mẫu khách truy cập có thể được sử dụng để khôi phục loại cụ thể của thể hiện của một lớp trừu tượng.

Trong khi tôi mô tả trong 3. một DeviceStrategylớp duy nhất , có những tình huống bạn có thể muốn phân chia chức năng mà nó cung cấp trên một số lớp.

Để tóm tắt chúng, những điểm chính của thiết kế tôi đã mô tả là:

1. Do nguyên tắc thay thế, các đối tượng đại diện cho trạng thái thiết bị phải khác biệt và không có quan hệ thừa kế đặc biệt.

2. Đóng gói các phương pháp điều trị thiết bị trong các đối tượng bắt đầu thay vì trong các đối tượng đại diện cho chính các thiết bị, sao cho mỗi trạng thái thiết bị hoặc thiết bị chỉ nhìn thấy chính nó và chiến lược nhìn thấy tất cả chúng và thể hiện sự chuyển tiếp có thể giữa chúng.

Tôi sẽ thề rằng tôi đã thấy một lần mô tả về việc triển khai máy khách telnet theo những dòng này, nhưng tôi không thể tìm lại được. Nó sẽ là một tài liệu tham khảo rất hữu ích!

: Đối với điều này, hãy làm theo trực giác của bạn hoặc tìm các lớp phương thức tương đương trong triển khai thực tế của bạn cho phương thức mối quan hệ “₁ phương thức “iff. sử dụng chúng trên cùng một đối tượng là hợp lệ - giả sử bạn có một đối tượng lớn gói gọn tất cả các phương pháp điều trị trên thiết bị của bạn. Cả hai phương pháp liệt kê các quốc gia đều cho kết quả tuyệt vời.

Sử dụng một mô hình xây dựng.

Có một đối tượng có các phương thức cho tất cả các hoạt động bạn đã đề cập ở trên. Tuy nhiên, nó không thực hiện các hoạt động này ngay lập tức. Nó chỉ nhớ mỗi hoạt động cho sau này. Bởi vì các hoạt động không được thực hiện ngay lập tức, thứ tự mà bạn chuyển chúng cho nhà xây dựng không thành vấn đề.

Sau khi bạn xác định tất cả các hoạt động trên trình xây dựng, bạn gọi một execute-method. Khi phương thức này được gọi, nó thực hiện tất cả các bước bạn đã liệt kê ở trên theo đúng thứ tự với các thao tác bạn đã lưu trữ ở trên. Phương pháp này cũng là một nơi tốt để thực hiện một số kiểm tra vệ sinh kéo dài hoạt động (như cố gắng định cấu hình tài nguyên chưa được thiết lập) trước khi ghi chúng vào phần cứng. Điều này có thể giúp bạn tránh làm hỏng phần cứng với cấu hình vô nghĩa (trong trường hợp phần cứng của bạn dễ bị ảnh hưởng).

Bạn chỉ cần ghi lại chính xác cách sử dụng giao diện và đưa ra một ví dụ hướng dẫn.

Bạn cũng có thể có một biến thể thư viện gỡ lỗi mà một số kiểm tra thời gian chạy.

Có lẽ việc xác định và lập hồ sơ một cách chính xác một số quy ước đặt tên (ví dụ preconfigure*, startup*, postconfigure*, run*....)

BTW, rất nhiều giao diện hiện có theo một mẫu tương tự (ví dụ: bộ công cụ X11).

Đây thực sự là một loại lỗi phổ biến và xảo quyệt, bởi vì trình biên dịch chỉ có thể thực thi các điều kiện cú pháp, trong khi bạn cần các chương trình máy khách của mình phải "đúng ngữ pháp".

Thật không may, các quy ước đặt tên gần như hoàn toàn không hiệu quả đối với loại lỗi này. Nếu bạn thực sự muốn khuyến khích mọi người không làm những điều phi ngôn ngữ, bạn nên đưa ra một đối tượng lệnh thuộc loại nào đó phải được khởi tạo với các giá trị cho các điều kiện tiên quyết, để họ không thể thực hiện các bước không theo thứ tự.

public class Executor {

private Executor() {} // helper class

  public void execute(MyStepsRunnable r) {
    r.step1();
    r.step2();
    r.step3();
  }
}

interface MyStepsRunnable {

  void step1();
  void step2();
  void step3();
}

Sử dụng mẫu này, bạn chắc chắn rằng bất kỳ người triển khai nào cũng sẽ thực hiện theo thứ tự chính xác này. Bạn có thể tiến thêm một bước và tạo ExecutorFactory để xây dựng Executor với các đường dẫn thực thi tùy chỉnh.