Tôi nên sử dụng một phương thức nhà máy thay vì một nhà xây dựng. Tôi có thể thay đổi điều đó mà vẫn tương thích ngược không?

Vấn đề

Hãy nói rằng tôi có một lớp được gọi là DataSource cung cấp một ReadDataphương thức (và có thể là các phương thức khác, nhưng hãy giữ mọi thứ đơn giản) để đọc dữ liệu từ một .mdbtệp:

var source = new DataSource("myFile.mdb");
var data = source.ReadData();

Vài năm sau, tôi quyết định rằng tôi muốn có thể hỗ trợ .xmlcác tệp ngoài.mdb các tệp dưới dạng nguồn dữ liệu. Việc thực hiện "đọc dữ liệu" khá khác nhau đối với các tệp .xmlvà .mdbtệp; do đó, nếu tôi thiết kế hệ thống từ đầu, tôi sẽ định nghĩa nó như thế này:

abstract class DataSource {
    abstract Data ReadData();
    static DataSource OpenDataSource(string fileName) {
        // return MdbDataSource or XmlDataSource, as appropriate
    }
}

class MdbDataSource : DataSource {
    override Data ReadData() { /* implementation 1 */ }
}

class XmlDataSource : DataSource {
    override Data ReadData() { /* implementation 2 */ }
}

Tuyệt vời, một triển khai hoàn hảo của mẫu phương thức Factory. Thật không may, DataSourcenằm trong một thư viện và tái cấu trúc mã như thế này sẽ phá vỡ tất cả các cuộc gọi hiện có của

var source = new DataSource("myFile.mdb");

trong các khách hàng khác nhau sử dụng thư viện. Khốn nạn cho tôi, tại sao tôi không sử dụng phương pháp nhà máy ngay từ đầu?

Các giải pháp

Đây là những giải pháp tôi có thể đưa ra:

1. Làm cho hàm tạo DataSource trả về một kiểu con ( MdbDataSourcehoặc XmlDataSource). Điều đó sẽ giải quyết tất cả các vấn đề của tôi. Thật không may, C # không hỗ trợ điều đó.

2. Sử dụng các tên khác nhau:

   abstract class DataSourceBase { ... }    // corresponds to DataSource in the example above
   
   class DataSource : DataSourceBase {      // corresponds to MdbDataSource in the example above
       [Obsolete("New code should use DataSourceBase.OpenDataSource instead")]
       DataSource(string fileName) { ... }
       ...
   }
   
   class XmlDataSource : DataSourceBase { ... }

   Đó là những gì tôi đã kết thúc bằng cách sử dụng vì nó giữ cho mã tương thích ngược (nghĩa là các cuộc gọi new DataSource("myFile.mdb")vẫn hoạt động). Nhược điểm: Các tên không được mô tả như họ cần phải có.

3. Tạo DataSourcemột "trình bao bọc" để thực hiện thực tế:

   class DataSource {
       private DataSourceImpl impl;
   
       DataSource(string fileName) {
           impl = ... ? new MdbDataSourceImpl(fileName) : new XmlDataSourceImpl(fileName);
       }
   
       Data ReadData() {
           return impl.ReadData();
       }
   
       abstract private class DataSourceImpl { ... }
       private class MdbDataSourceImpl : DataSourceImpl { ... }
       private class XmlDataSourceImpl : DataSourceImpl { ... }
   }

   Nhược điểm: Mọi phương thức nguồn dữ liệu (như ReadData) phải được định tuyến bằng mã soạn sẵn. Tôi không thích mã soạn sẵn. Nó dư thừa và làm lộn xộn mã.

Có bất kỳ giải pháp thanh lịch mà tôi đã bỏ lỡ?

Tôi sẽ chọn một biến thể cho tùy chọn thứ hai của bạn cho phép bạn loại bỏ tên cũ, quá chung chung DataSource:

abstract class AbstractDataSource { ... } // corresponds to the abstract DataSource in the ideal solution

class XmlDataSource : AbstractDataSource { ... }
class MdbDataSource : AbstractDataSource { ... } // contains all the code of the existing DataSource class

[Obsolete("New code should use AbstractDataSource instead")]
class DataSource : MdbDataSource { // an 'empty shell' to keep old code working.
    DataSource(string fileName) { ... }
}

Hạn chế duy nhất ở đây là lớp cơ sở mới không thể có tên rõ ràng nhất, vì tên đó đã được yêu cầu cho lớp gốc và cần duy trì như thế để tương thích ngược. Tất cả các lớp khác có tên mô tả của họ.

Giải pháp tốt nhất sẽ là một cái gì đó gần với lựa chọn số 3 của bạn. Giữ DataSourcephần lớn như hiện tại và trích xuất phần độc giả vào lớp riêng của nó.

class DataSource {
    private Reader reader;

    DataSource(string fileName) {
        reader = ... ? new MdbReader(fileName) : new XmlReader(fileName);
    }

    Data ReadData() {
        return reader.next();
    }

    abstract private class Reader { ... }
    private class MdbReader : Reader { ... }
    private class XmlReader : Reader { ... }
}

Bằng cách này, bạn tránh được mã trùng lặp và được mở cho các tiện ích mở rộng hơn nữa.