Các phương thức init () có phải là mùi mã không?

Có bất kỳ mục đích để khai báo một init()phương thức cho một loại?

Tôi không hỏi liệu chúng ta nên ưu tiên init()hơn một nhà xây dựng hay làm thế nào để tránh khai báoinit() .

Tôi đang hỏi liệu có bất kỳ lý do nào đằng sau việc khai báo một init()phương thức (xem mức độ phổ biến của nó) hoặc nếu đó là một mùi mã và nên tránh.

Thành init()ngữ này khá phổ biến, nhưng tôi chưa thấy lợi ích thực sự nào.

Tôi đang nói về các loại khuyến khích khởi tạo thông qua một phương thức:

class Demo {
    public void init() {
        //...
    }
}

Khi nào thì cái này sẽ được sử dụng trong mã sản xuất?

Tôi cảm thấy nó có thể là một mùi mã vì nó cho thấy hàm tạo không khởi tạo hoàn toàn đối tượng, dẫn đến một đối tượng được tạo một phần. Đối tượng không nên tồn tại nếu trạng thái không được đặt.

Điều này khiến tôi tin rằng nó có thể là một phần của một số loại kỹ thuật được sử dụng để tăng tốc độ sản xuất, theo nghĩa các ứng dụng doanh nghiệp. Đó là lý do hợp lý duy nhất tôi có thể nghĩ đến khi có một thành ngữ như vậy, tôi chỉ không chắc nó sẽ có ích như thế nào nếu như vậy.

Vâng, đó là một mùi mã. Một mùi mã không phải là thứ luôn luôn cần phải loại bỏ. Đó là thứ khiến bạn có cái nhìn thứ hai.

Ở đây bạn có một đối tượng ở hai trạng thái cơ bản khác nhau: pre-init và post-init. Những tiểu bang đó có trách nhiệm khác nhau, các phương pháp khác nhau được phép gọi và hành vi khác nhau. Đó thực sự là hai lớp khác nhau.

Nếu bạn thực sự biến chúng thành hai lớp riêng biệt, bạn sẽ loại bỏ hoàn toàn cả một lớp lỗi tiềm ẩn, với chi phí có thể làm cho mô hình của bạn không khớp với "mô hình thế giới thực" một cách chặt chẽ. Bạn thường đặt tên cho một đầu Confighoặc Setuphoặc một cái gì đó như thế.

Vì vậy, lần tới, hãy thử tái cấu trúc các thành ngữ init-init của bạn thành các mô hình hai lớp và xem nó biến ra như thế nào cho bạn.

Nó phụ thuộc.

Một initphương thức là một mùi mã khi không cần thiết phải khởi tạo đối tượng khỏi hàm tạo. Đôi khi có những trường hợp có ý nghĩa để tách các bước này.

Một tìm kiếm nhanh trên Google đã cho tôi ví dụ này . Tôi có thể dễ dàng tưởng tượng ra nhiều trường hợp trong đó mã được thực thi trong khi cấp phát đối tượng (hàm tạo) có thể được tách ra khỏi chính việc khởi tạo. Có thể bạn có một hệ thống được phân cấp và việc phân bổ / xây dựng diễn ra ở cấp X, nhưng chỉ khởi tạo ở cấp Y, vì chỉ Y mới có thể cung cấp các tham số cần thiết. Có thể "init" tốn kém và chỉ được chạy cho một tập hợp con của các đối tượng được phân bổ và việc xác định tập hợp con đó chỉ có thể được thực hiện ở cấp Y. Hoặc bạn muốn ghi đè phương thức "init" (ảo) trong dẫn xuất lớp không thể được thực hiện với một hàm tạo. Có thể cấp X cung cấp cho bạn các đối tượng được phân bổ từ cây thừa kế, nhưng cấp Y không biết về đạo hàm cụ thể, chỉ về giao diện chung (trong đóinit có thể định nghĩa).

Tất nhiên, theo kinh nghiệm của tôi, những trường hợp này chỉ là một tỷ lệ nhỏ của trường hợp tiêu chuẩn trong đó tất cả việc khởi tạo có thể được thực hiện trực tiếp trong hàm tạo và bất cứ khi nào bạn thấy một initphương thức riêng biệt , có thể nên đặt câu hỏi về sự cần thiết của nó.

Kinh nghiệm của tôi chia thành hai nhóm:

1. Mã nơi init () thực sự được yêu cầu. Điều này có thể xảy ra khi siêu lớp hoặc khung ngăn không cho hàm tạo của lớp bạn nhận được tất cả các phụ thuộc của nó trong quá trình xây dựng.
2. Mã nơi init () được sử dụng nhưng có thể tránh được.

Theo kinh nghiệm cá nhân của tôi, tôi chỉ thấy một vài trường hợp của (1) nhưng nhiều trường hợp khác của (2). Do đó, tôi thường cho rằng init () là mùi mã, nhưng điều này không phải lúc nào cũng đúng. Đôi khi bạn không thể đi xung quanh nó.

Tôi đã tìm thấy bằng cách sử dụng Mẫu xây dựng thường có thể giúp loại bỏ nhu cầu / mong muốn có init ().

Một kịch bản điển hình khi phương thức init có ích là khi bạn có tệp cấu hình mà bạn muốn thay đổi và phải tính đến thay đổi mà không cần khởi động lại ứng dụng. Tất nhiên, điều này không có nghĩa là một phương thức init phải được gọi riêng với hàm tạo. Bạn có thể gọi một phương thức init từ một hàm tạo, rồi gọi nó sau khi / nếu các tham số cấu hình thay đổi.

Tóm lại: như đối với hầu hết các tình huống khó xử ngoài kia, cho dù đây có phải là mùi mã hay không, tùy thuộc vào tình huống và hoàn cảnh.

Phụ thuộc vào cách bạn sử dụng chúng.

Tôi sử dụng mô hình đó trong các ngôn ngữ được thu thập rác như Java / C # khi tôi không muốn tiếp tục phân bổ lại một đối tượng trên đống (như khi tôi tạo trò chơi video và cần duy trì hiệu suất cao, trình thu gom rác giết chết hiệu suất). Tôi sử dụng hàm tạo để thực hiện các phân bổ heap khác mà nó cần và initđể tạo trạng thái hữu ích cơ bản ngay trước mỗi lần tôi muốn sử dụng lại nó. Điều này có liên quan đến khái niệm nhóm đối tượng.

Nó cũng hữu ích nếu bạn có một số hàm tạo chia sẻ một tập hợp con chung của các hướng dẫn khởi tạo, nhưng trong trường hợp đó initsẽ là riêng tư. Bằng cách đó tôi có thể giảm thiểu mỗi hàm tạo càng nhiều càng tốt, vì vậy mỗi hàm chỉ chứa các hướng dẫn duy nhất của nó và một lệnh gọi initđể thực hiện phần còn lại.

Nói chung, mặc dù nó là một mùi mã.

init()các phương thức có thể có ý nghĩa khá lớn khi bạn có các đối tượng cần tài nguyên bên ngoài (ví dụ như kết nối mạng) được các đối tượng khác sử dụng đồng thời. Bạn có thể không muốn / cần hog tài nguyên cho vòng đời của đối tượng. Trong các tình huống như vậy, bạn có thể không muốn phân bổ tài nguyên trong hàm tạo khi phân bổ tài nguyên có khả năng thất bại.

Đặc biệt trong lập trình nhúng, bạn muốn có một dấu chân bộ nhớ xác định, do đó, thông thường (tốt?) Để gọi các nhà xây dựng của bạn sớm, thậm chí có thể tĩnh và chỉ khởi tạo sau khi đáp ứng một số điều kiện nhất định.

Khác với những trường hợp như vậy tôi nghĩ mọi thứ nên đi vào một nhà xây dựng.

Nói chung, tôi thích một hàm tạo nhận tất cả các đối số cần thiết cho một thể hiện chức năng. Điều đó làm rõ tất cả các phụ thuộc của đối tượng đó.

Mặt khác, tôi sử dụng một khung cấu hình đơn giản đòi hỏi một hàm tạo công khai không tham số và các giao diện để thêm các giá trị phụ thuộc và cấu hình. Sau khi hoàn thành, khung cấu hình gọi initphương thức của đối tượng: bây giờ bạn đã nhận được tất cả những thứ tôi có cho bạn, thực hiện các bước cuối cùng để sẵn sàng cho công việc. Nhưng lưu ý: đó là khung cấu hình tự động gọi phương thức init, vì vậy bạn sẽ không quên gọi nó.

Không có mùi mã nếu phương thức init () - được nhúng vào ngữ nghĩa trong vòng đời trạng thái của đối tượng.

Nếu bạn cần gọi init () để đặt đối tượng vào trạng thái nhất quán thì đó là mùi mã.

Có một số lý do kỹ thuật mà cấu trúc như vậy tồn tại:

1. khung móc
2. Đặt lại đối tượng về trạng thái ban đầu (tránh dư thừa)
3. khả năng ghi đè trong các bài kiểm tra

Tên init đôi khi có thể mờ đục. Hãy lấy một chiếc xe hơi và một động cơ. Để khởi động xe (chỉ bật nguồn, nghe radio), bạn muốn xác minh rằng tất cả các hệ thống đã sẵn sàng để đi.

Vì vậy, bạn xây dựng một động cơ, một cánh cửa, một bánh xe, vv màn hình của bạn hiển thị động cơ = tắt.

Không cần phải bắt đầu theo dõi động cơ, vv vì tất cả đều đắt tiền. Sau đó, khi bạn bật chìa khóa để kích hoạt, bạn gọi công cụ-> bắt đầu. Nó bắt đầu chạy tất cả các quy trình đắt tiền.

Bây giờ bạn thấy engine = on. Và quá trình đánh lửa bắt đầu.

Chiếc xe sẽ không tăng sức mạnh nếu không có động cơ.

Bạn có thể thay thế động cơ với tính toán phức tạp của bạn. Giống như một ô Excel. Không phải tất cả các ô cần phải hoạt động với tất cả các trình xử lý sự kiện mọi lúc. Khi bạn tập trung vào một tế bào, bạn có thể bắt đầu nó. Tăng hiệu suất theo cách đó.