Phương pháp tiếp cận dần dần để tiêm phụ thuộc

Tôi đang làm việc để làm cho các lớp học của tôi có thể kiểm tra được đơn vị, sử dụng phép tiêm phụ thuộc. Nhưng một số trong các lớp này có rất nhiều khách hàng và tôi chưa sẵn sàng cấu trúc lại tất cả chúng để bắt đầu chuyển qua các phụ thuộc. Vì vậy, tôi đang cố gắng làm điều đó dần dần; giữ các phụ thuộc mặc định cho đến bây giờ, nhưng cho phép chúng bị ghi đè để thử nghiệm.

Một cách tiếp cận mà tôi quan tâm là chỉ chuyển tất cả các cuộc gọi "mới" sang các phương thức của riêng họ, ví dụ:

public MyObject createMyObject(args) {
  return new MyObject(args);
}

Sau đó, trong các bài kiểm tra đơn vị của mình, tôi chỉ có thể phân lớp lớp này và ghi đè các hàm tạo, để chúng tạo các đối tượng giả thay thế.

Đây có phải là một cách tiếp cận tốt? Có bất kỳ nhược điểm?

Tổng quát hơn, có ổn không khi có các phụ thuộc được mã hóa cứng, miễn là bạn có thể thay thế chúng để thử nghiệm? Tôi biết cách tiếp cận ưa thích là yêu cầu rõ ràng chúng trong hàm tạo và cuối cùng tôi muốn đến đó. Nhưng tôi tự hỏi nếu đây là một bước đầu tốt.

Một nhược điểm vừa xảy ra với tôi: nếu bạn có các lớp con thực sự mà bạn cần kiểm tra, bạn không thể sử dụng lại lớp con kiểm tra mà bạn đã viết cho lớp cha. Bạn sẽ phải tạo một lớp con thử nghiệm cho mỗi lớp con thực sự và nó sẽ phải ghi đè cùng các hàm tạo.

Đây là một cách tiếp cận tốt để giúp bạn bắt đầu. Lưu ý rằng điều quan trọng nhất là bao gồm mã hiện tại của bạn bằng các bài kiểm tra đơn vị; một khi bạn có các bài kiểm tra, bạn có thể tái cấu trúc một cách tự do hơn để cải thiện thiết kế của bạn hơn nữa.

Vì vậy, điểm ban đầu không phải là làm cho thiết kế thanh lịch và sáng bóng - chỉ để làm cho đơn vị mã có thể kiểm tra được với những thay đổi ít rủi ro nhất . Nếu không có bài kiểm tra đơn vị, bạn phải thận trọng và thận trọng hơn để tránh phá vỡ mã của mình. Những thay đổi ban đầu này thậm chí có thể làm cho mã trông vụng về hoặc xấu xí hơn trong một số trường hợp - nhưng nếu chúng cho phép bạn viết các bài kiểm tra đơn vị đầu tiên, cuối cùng bạn sẽ có thể cấu trúc lại theo thiết kế lý tưởng mà bạn có trong đầu.

Công việc cơ bản để đọc về chủ đề này là Làm việc hiệu quả với Bộ luật kế thừa . Nó mô tả thủ thuật bạn thể hiện ở trên và nhiều, nhiều hơn nữa, bằng cách sử dụng một số ngôn ngữ.

Guice-folks khuyên bạn nên sử dụng

@Inject
public void setX(.... X x) {
   this.x = x;
}

cho tất cả các thuộc tính thay vì chỉ thêm @Inject vào định nghĩa của chúng. Điều này sẽ cho phép bạn coi chúng như những hạt đậu bình thường, điều mà bạn có thể newkhi kiểm tra (và thiết lập các thuộc tính theo cách thủ công) và @Inject trong sản xuất.

Khi tôi gặp phải loại vấn đề này, tôi sẽ xác định từng phụ thuộc của bài kiểm tra lớp của mình và tạo một hàm tạo được bảo vệ cho phép tôi vượt qua chúng. Điều này thực sự giống như tạo một setter cho mỗi, nhưng tôi thích tuyên bố sự phụ thuộc trong các nhà xây dựng của tôi để tôi không quên khởi tạo chúng trong tương lai.

Vì vậy, lớp thử nghiệm đơn vị mới của tôi sẽ có 2 hàm tạo:

public MyClass() { 
  this(new Client1(), new Client2()); 
}

public MyClass(Client1 client1, Client2 client2) { 
  this.client1 = client1; 
  this.client2 = client2; 
}

Bạn có thể muốn xem xét thành ngữ "getter created" cho đến khi bạn có thể sử dụng phần phụ thuộc được thêm vào.

Ví dụ,

public class Example {
  private MyObject myObject=null;

  public MyObject getMyObject() {
    if (myObject==null) {
      myObject=new MyObject();
    } 
    return myObject;
  }

  public void setMyObject(MyObject myObject) {
    this.myObject=myObject;
  }

  private void myMethod() {
    if (getMyObject().doSomething()) {
      // Instance automatically created
    }
  }
}

Điều này sẽ cho phép bạn cấu trúc lại nội bộ để bạn có thể tham chiếu myObject của mình thông qua getter. Bạn không bao giờ phải gọi new. Trong tương lai, khi tất cả các máy khách được cấu hình để cho phép tiêm phụ thuộc, thì tất cả những gì bạn phải làm là xóa mã tạo ở một nơi - getter. Trình thiết lập sẽ cho phép bạn tiêm các đối tượng giả theo yêu cầu.

Đoạn mã trên chỉ là một ví dụ và nó trực tiếp phơi bày trạng thái bên trong. Bạn nên cân nhắc cẩn thận nếu cách tiếp cận này phù hợp với cơ sở mã của bạn.

Tôi cũng khuyên bạn nên đọc " Làm việc hiệu quả với Mã kế thừa " trong đó có vô số lời khuyên hữu ích để thành công trong việc tái cấu trúc chính.