Có phải hình thức xấu để thử và có các lớp khác với chính/form1 tương tác với nhau không?

Question

Tôi đang cố gắng tìm hiểu cách sử dụng đúng các lớp trong mã của mình, khi nó không rõ ràng như một tập hợp khách hàng, những con chó kế thừa từ động vật, v.v.

Tôi đã chia nhỏ các phần lớn của mã thành "các tính năng" chẳng hạn như Installer.cs, Downloader.cs, UiManager.cs. Cách duy nhất tôi có thể tìm thấy để có những lớp tương tác với các thuộc tính và phương pháp của nhau là làm cho chúng tĩnh, mà tôi đã được nói trong một câu hỏi khác là sai đường đi.

Vì vậy, vấn đề của tôi là một trong 3 điều:

1. Có một cách để làm cho các lớp học nói chuyện với nhau mà tôi chỉ không hiểu được nêu ra.

2. Lớp học không bao giờ nên cố gắng nói chuyện với nhau, nhưng thực hiện hành động một lần và sau đó trả lại một cái gì đó về số main/form1, sau đó lớp chính có thể sử dụng để chuyển sang một lớp khác.

3. Lớp học thực sự chỉ hữu ích khi tạo nhiều trường hợp, và có một số cấu trúc khác hoàn toàn tôi cần tìm hiểu để tóm tắt các khối chức năng lớn từ lớp chính.

Tất cả các hướng dẫn tôi có thể tìm và bài giảng tôi xem dường như chỉ cho bạn biết cách lớp việc, nhưng không phải khi nào và làm thế nào để sử dụng chúng trong một sản phẩm thực sự.

EDIT - Một ví dụ cụ thể hơn:

Nói rằng tôi đã một chuỗi mà là trung tâm của toàn bộ ứng dụng, và cần phải được nhìn thấy và/hoặc sửa đổi có khả năng bởi tất cả các lớp. Làm cách nào để di chuyển thông tin đó xung quanh mã mà không có mọi thứ trong một lớp hoặc làm cho nó tĩnh?

Tôi không thể thấy cách để chuỗi đó tồn tại trong Form1 mà không làm cho nó tĩnh (vì tất cả các sự kiện và chức năng biểu mẫu sẽ cần để có thể xem nó để chuyển nó vào một lớp).

Tôi không thể nhìn thấy một cách để đưa chuỗi vào một lớp khác mà không cần phải làm cho chuỗi và toàn bộ lớp tĩnh, vì vậy các lớp khác có thể nhìn thấy nó.

Có thể có điều gì đó tôi thiếu trong việc thực sự khởi tạo các lớp và làm cho các đối tượng tương tác với nhau.

Answer 1

Tôi nghĩ rằng tất cả trực giác của bạn đều đúng.

1. Không, không có. Tĩnh hoặc thể hiện.

2. Đó là lựa chọn thiết kế (và có rất nhiều lựa chọn ở đó). Tôi là một thực dụng, vì vậy tôi xem xét một mô hình thiết kế mà tạo ra mã spaguethi một sự lựa chọn mô hình thiết kế xấu. Nhưng một mẫu thiết kế xấu cho một dự án có thể là một mẫu thiết kế tốt cho một dự án khác. Hãy thử đọc cuốn sách Head First Design Pattern.

3. Có, có các giao diện và lớp trừu tượng.

Một vài suy nghĩ nhiều hơn:

Tôi không nghĩ rằng việc sử dụng các phương pháp tĩnh hoặc các lớp học phải được tránh. Những gì phải tránh là việc sử dụng bỏ lỡ một phương pháp tĩnh hoặc lớp học, giống như việc sử dụng bỏ lỡ tất cả mọi thứ bên trong một ngôn ngữ. Nhưng rất khó để xác định những gì là một sử dụng bỏ lỡ của một tĩnh, và bởi vì phương pháp tĩnh hoặc các lớp học là nguy hiểm đặc biệt, mọi người muốn nói để tránh các từ khóa tĩnh ở tất cả. Một phương thức tĩnh sẽ có trong bộ nhớ trừ khi bạn kết thúc ứng dụng của bạn, vì vậy nếu bạn không bỏ kết nối bên trong một phương thức tĩnh, bạn sẽ có một ngày rất tệ.

Tôi có một dự án tiện ích và bên trong dự án tiện ích tôi có một lớp dữ liệu. Lớp dữ liệu cung cấp quyền truy cập vào cơ sở dữ liệu. Đó là một lớp tĩnh. Tại sao?

Trước tiên, nó là tĩnh vì chuỗi kết nối đến từ webconfig. Vì vậy, tôi có một constructor tĩnh (chạy một lần khi ứng dụng bắt đầu và lớp được đề cập) người đọc webconfig và lưu trữ chuỗi trong một biến thành viên riêng tư tĩnh. Tôi nghĩ rằng nó tốt hơn rất nhiều so với đọc các tập tin webconfig và tạo ra một biến phạm vi 10 bilion lần ngày. Các phương thức là tĩnh vì chúng đủ đơn giản, có nghĩa là chúng không cần nhiều cấu hình để hoạt động, chúng chỉ cần một vài tham số và chúng chỉ được sử dụng trong dự án truy cập dữ liệu. Tất cả người dùng trang web của tôi đều sử dụng cùng một phương thức (phương pháp tĩnh), nhưng mọi người đều sử dụng phương pháp tĩnh với các tham số khác nhau, vì vậy họ nhận được các phản hồi khác nhau (họ chia sẻ đường ống, nhưng họ uống nước khác nhau). Nó chỉ cần chăm sóc thêm bên trong phương pháp để làm sạch tất cả mọi thứ (vứt bỏ từng trường hợp phạm vi), bởi vì nếu bạn không họ sẽ ở lại trong bộ nhớ. Và cuối cùng, kinh doanh của tôi là về thao tác dữ liệu, một lớp dữ liệu không tĩnh có nghĩa là sử dụng bộ nhớ nhiều hơn một bộ nhớ tĩnh (việc sử dụng cpu gần như giống nhau trong cả hai mẫu).

public abstract class Data 
{ 

    [...] 

    static Data() 
    { 
     #if DEBUG 
      _Connection = ConfigurationManager.AppSettings["debug"]; 
     #endif 

     #if RELEASE 
      _Connection = ConfigurationManager.AppSettings["release"]; 
     #endif 

     [...] 
    } 

    [...] 

} 

Trong cuối ngày tôi sử dụng tĩnh khi:

1. Nếu nó là đủ đơn giản (mà tôi có thể kiểm soát mọi khía cạnh);
2. Nếu đủ nhỏ (tôi sử dụng các phương pháp mở rộng để xác thực, chúng là tĩnh) và;
3. Nếu được sử dụng nặng.

Bên cạnh đó, tôi sử dụng các lớp để tổ chức dự án của tôi (mẫu nhà máy poco +). Tôi có một dự án tiện ích, sau đó là một dự án mô hình thực thể, sau đó là một dự án truy cập, sau đó là một dự án logic kinh doanh, sau đó một trang web, một api, một người quản lý, v.v. Các lớp trong dự án tiện ích không tương tác với nhau, nhưng các lớp bên trong dự án mô hình thực thể làm (một lớp có thể có một cá thể của một lớp khác bên trong nó). Dự án mô hình thực thể không tương tác với dự án tiện ích vì chúng có cùng cấp độ, chúng tương tác lẫn nhau ở một cấp độ khác, trong dự án truy cập, nhưng nó trực quan hơn trong một dự án thao tác dữ liệu.

Answer 2

lớp nói chuyện với eachother khi họ có một tài liệu tham khảo, để cho A để vượt qua một thông điệp tới B, A cần một tham chiếu đến B (hoặc một thể hiện hoặc tham chiếu tĩnh)

Lớp học có thể một trong hai nói chuyện với nhau , hoặc trả lại thông tin cho một lớp học mà controlls toàn bộ quá trình (điều này thực sự là một mẫu thiết kế)

Đối trừu tượng hóa thông tin từ các lớp học chính (hoặc bất kỳ lớp) bạn có giao diện và lớp trừu tượng

các mẫu thiết kế cuốn sách từ Gang of Four, nó phải được đọc trong trường hợp này. Một cái gì đó khác để ghi nhớ bên cạnh là sự đơn giản của thiết kế của bạn, đôi khi cố gắng để phù hợp với một mẫu thiết kế chỉ gây ra có thể sẽ tạo ra nhiều mã spaguethi hơn. Như một quy tắc của ngón tay cái luôn luôn cố gắng nắm bắt các funcionality trình bày từ logic, và suy nghĩ của các lớp học như người nói chuyện với nhau và thực hiện công việc (đó là kinda lạ iknow nhưng đôi khi nó giúp tôi suy nghĩ theo cách này)