Hãy mô tả những hành vi của bạn bằng cách giảm thiểu việc sử dụng các biến toàn cầu

Question

Hầu hết các chương trình mà tôi viết đều là các quy trình tương đối lưu thông, với một sự khởi đầu được xác định và kết thúc được mong đợi. Các vấn đề có thể phức tạp nhưng không sẵn sàng dựa vào việc sử dụng trung tâm của các đối tượng và lập trình hướng sự kiện. Thông thường, tôi chỉ đơn giản là chuyển qua các lô dữ liệu văn bản đa dạng để tạo ra các dữ liệu văn bản khác nhau. Chỉ thỉnh thoảng tôi mới cần tạo một lớp: Ví dụ: để theo dõi cảnh báo, lỗi và thông báo gỡ lỗi, tôi đã tạo một lớp (Vấn đề) với một phiên bản (myErr), mà tôi tin là một ví dụ về mẫu thiết kế Singleton . Như một yếu tố nữa, đồng nghiệp của tôi là trường cũ (thủ tục) hơn tôi và không quen thuộc với lập trình hướng đối tượng, vì vậy tôi không thích tạo ra những thứ mà họ không thể giải đố.

Tuy nhiên, tôi nghe, lặp đi lặp lại, làm thế nào ngay cả mẫu thiết kế Singleton thực sự là một mẫu chống và nên tránh vì Biến toàn cục là xấu.

Chức năng nhỏ cần vài đối số được truyền cho chúng và không cần biết cấu hình (không thay đổi) hoặc trạng thái chương trình (thay đổi) - Tôi đồng ý. Tuy nhiên, các chức năng ở giữa chuỗi, chủ yếu kiểm soát luồng chương trình, có nhu cầu cho một số lượng lớn các biến cấu hình và một số biến trạng thái chương trình. Tôi tin rằng việc vượt qua một chục hoặc nhiều đối số cùng với một chức năng là một "giải pháp", nhưng hầu như không hấp dẫn. Tôi có thể, tất nhiên, các biến cram thành một mảng băm/dict/kết hợp duy nhất, nhưng điều đó có vẻ như gian lận. Ví dụ, kết nối với Active Directory để tạo một tài khoản mới, tôi cần các biến cấu hình như tên người dùng quản trị, mật khẩu, OU mục tiêu, một số nhóm mặc định, tên miền, v.v. Tôi sẽ phải vượt qua các đối số đó thông qua một loạt các chức năng mà thậm chí sẽ không sử dụng chúng, chỉ đơn thuần là xáo trộn chúng thông qua một chuỗi mà cuối cùng sẽ dẫn đến chức năng thực sự cần chúng. Tôi sẽ ít nhất tuyên bố biến cấu hình là hằng số, để bảo vệ chúng, nhưng ngôn ngữ của tôi trong những ngày này (Python) không cung cấp cách đơn giản để làm điều này, mặc dù công thức nấu ăn tồn tại như cách giải quyết.

Nhiều câu hỏi tràn ngăn xếp đã xảy ra tại sao? về sự xấu xa và điều kiện tiên quyết, nhưng không thường đề cập đến những lời khuyên về việc sống với sự hạn chế gần như tôn giáo này. Làm thế nào bạn đã giải quyết, hoặc ít nhất là hòa bình với, vấn đề biến toàn cầu và tình trạng chương trình? Bạn đã thỏa hiệp ở đâu? Thủ đoạn của bạn là gì, ngoài việc xô đẩy xung quanh đàn đối số cho các chức năng?

Answer 1

Tôi nghĩ rằng có thời gian và địa điểm cho mẫu đơn hoặc các tình huống tương tự. Điểm mấu chốt cần nhớ là thời gian và thời gian một lần nữa, nhiều người đã trải qua những kinh dị cụ thể khi nói đến lựa chọn "sai" để sử dụng các biến toàn cục/chia sẻ/tĩnh cũng như mẫu đơn.

Trong trường hợp của bạn, bạn đang nói về cấu hình cụ thể. Tôi thấy không có hại trong việc sử dụng một mẫu kiểu đơn để truy cập vào các mục cấu hình đó. Mỗi ứng dụng có cấu hình, nó NÊN được ở một vị trí mà bạn chỉ có thể gọi, không cần phải chỉ cần vượt qua nó xung quanh, mà phức tạp hơn nó giúp.

Chìa khóa ở đây là đảm bảo rằng bạn thực sự cần thông tin chỉ tồn tại một lần, cấu hình là một trong những lý do tốt nhất mà tôi đã tìm thấy để sử dụng kiểu mẫu này.

Answer 2

Dữ liệu toàn cầu không thay đổi hoặc được xác định rõ, các đối tượng trong toàn bộ quá trình (ví dụ: ghi nhật ký), thường được sử dụng làm dữ liệu chung. Dữ liệu cấu hình, đặc biệt là nếu nó sống trong một tệp cục bộ, sẽ nằm trong cùng một danh mục (chỉ có một tệp cho toàn bộ quá trình/ứng dụng, tương tự như ghi nhật ký).

Nói chung, nếu bạn thấy bạn phải vượt qua các đối số thừa chỉ để chuyển chúng sang hàm khác, bạn nên kéo hàm đó "lên" và có hàm khác làm trung gian. Một cách tiếp cận khác, thực tế hơn, minh họa điều này là phát triển theo hướng thử nghiệm bởi vì nó buộc bạn phải vượt qua các phụ thuộc.

Một cách khác để suy nghĩ về nó là: nếu chức năng đó không thể dễ dàng biết tất cả các chi tiết để gọi hàm phụ, hãy kéo chức năng con lên và buộc lớp cao hơn, hiểu biết hơn để có được sự cần thiết thông tin. Tôi đã tìm thấy kỹ thuật này có tính dẫn điện cao về chất lượng mã, vì nó xây dựng các phần chia nhỏ, thay vì các con thú nguyên khối.

Trong ví dụ của bạn về hoạt động thư mục, thay vì đi qua xung quanh các đối số cho ad_connect, vượt qua xung quanh một đối tượng để xử lý logic cần thiết, sau đó có một chức năng mà trung gian tương tác giữa các đối tượng và chức năng sử dụng nó

def create_user(name, ad_user, ad_pass, ad_ou, ...): 
    conn = ad_connect(ad_user, ad_pass, ...) 
    conn.CreateRecord(ad_user) 

def create_user_mediator(name, ad_controller): 
    ad_controller.CreateRecord("cn=%s" % name) 

Đó chỉ là một cách để làm điều đó, và tất nhiên, có ưu và khuyết điểm của nó. Nó chỉ đơn thuần là một ví dụ về cách create_user có thể tránh phải sử dụng các biến toàn cục.