Hai cấu trúc với cùng một thành viên nhưng đặt tên khác nhau, đó có phải là một ý tưởng tốt?

Tôi đang viết một chương trình liên quan đến việc làm việc với cả tọa độ cực và Cartesian.

Liệu nó có ý nghĩa để tạo ra hai cấu trúc khác nhau cho mỗi loại điểm, một với Xvà Ycác thành viên và một là với Rvà Thetacác thành viên.

Hoặc là quá nhiều và tốt hơn là chỉ có một cấu trúc với firstvà secondlà thành viên.

Những gì tôi đang viết rất đơn giản và nó sẽ không thay đổi nhiều. Nhưng tôi tò mò không biết cái gì tốt hơn từ quan điểm thiết kế.

Tôi đang nghĩ lựa chọn đầu tiên là tốt hơn. Có vẻ dễ đọc hơn và tôi sẽ nhận được lợi ích của việc kiểm tra loại.

Tôi đã thấy cả hai giải pháp, vì vậy nó chắc chắn phụ thuộc vào bối cảnh.

Để dễ đọc, có nhiều cấu trúc như bạn đề xuất là rất hiệu quả. Tuy nhiên, trong một số môi trường, bạn muốn thực hiện các thao tác phổ biến cho các cấu trúc này và bạn thấy mình đang sao chép mã, chẳng hạn như các hoạt động vectơ ma trận *. Nó có thể gây bực bội khi hoạt động cụ thể không có sẵn trong hương vị vector của bạn bởi vì không ai chuyển nó ở đó.

Giải pháp cực đoan (mà cuối cùng chúng tôi đã đưa ra) là có một lớp cơ sở khuôn mẫu CRTP với các hàm get <0> () get <1> () và lấy <2> () để lấy các phần tử theo cách chung. Các hàm này sau đó được định nghĩa trong cấu trúc Cartesian hoặc Polar xuất phát từ lớp cơ sở này. Nó giải quyết tất cả các vấn đề, nhưng có một mức giá khá ngớ ngẩn: phải học lập trình siêu mẫu. Tuy nhiên, nếu siêu lập trình mẫu là trò chơi công bằng cho dự án của bạn, thì đó có thể là một kết hợp tốt.

Vâng, nó rất có ý nghĩa.

Giá trị của một cấu trúc không chỉ là nó đóng gói dữ liệu dưới một tên tiện dụng. Giá trị là nó mã hóa ý định của bạn để trình biên dịch có thể giúp bạn xác minh rằng bạn không vi phạm chúng một ngày nào đó (ví dụ: nhầm một bộ tọa độ cực cho bộ tọa độ cartesian).

Mọi người rất tệ trong việc ghi nhớ những chi tiết gây cười như vậy, nhưng lại giỏi trong việc tạo ra những kế hoạch táo bạo, sáng tạo. Máy tính rất giỏi trong các chi tiết nghịch ngợm và xấu trong các kế hoạch sáng tạo. Do đó, luôn luôn là một ý tưởng tốt để chuyển nhiều bảo trì chi tiết rắc rối sang máy tính, để tâm trí của bạn tự do làm việc trong kế hoạch lớn.

Đúng, trong khi cả Cartesian và Polar đều (ở vị trí của chúng) các sơ đồ biểu diễn tọa độ hợp lý rõ ràng, chúng không bao giờ được trộn lẫn (nếu bạn có một điểm Cartesian {1,1}, thì đó là một điểm rất khác so với Polar {1,1 }).

Tùy thuộc vào nhu cầu của bạn, nó cũng có thể có giá trị thực hiện một giao diện Phối hợp với các phương pháp như X(), Y(), Displacement()và Angle()(hoặc có thể Radius()và Theta(), tùy thuộc vào).

Cuối cùng, mục tiêu của lập trình là chuyển các bit bóng bán dẫn để thực hiện công việc hữu ích. Nhưng suy nghĩ ở mức độ thấp như vậy sẽ dẫn đến sự điên rồ không thể kiểm soát, đó là lý do tại sao có các ngôn ngữ lập trình cấp cao hơn để giúp bạn che giấu sự phức tạp.

Nếu bạn chỉ tạo một cấu trúc với các thành viên được đặt tên firstvà second, thì tên đó không có nghĩa gì cả; về cơ bản bạn sẽ coi chúng là địa chỉ bộ nhớ. Điều đó đánh bại mục đích của ngôn ngữ lập trình cấp cao.

Hơn nữa, chỉ vì tất cả chúng đều có thể được đại diện vì doubleđiều đó không có nghĩa là bạn có thể sử dụng chúng thay thế cho nhau. Ví dụ, θ là góc không thứ nguyên, trong khi y có các đơn vị chiều dài. Vì các loại không thể thay thế một cách hợp lý, chúng phải là hai cấu trúc không tương thích.

Nếu bạn thực sự cần chơi các thủ thuật tái sử dụng bộ nhớ - và bạn gần như chắc chắn không nên - bạn có thể sử dụng một unionloại trong C để làm rõ ý định của mình.

Thứ nhất, có cả hai câu trả lời rõ ràng, theo câu trả lời hoàn toàn đúng đắn của @ Kilian-foth.

Tuy nhiên, tôi muốn thêm:

Hỏi: Bạn có thực sự có các hoạt động chung cho cả hai khi được coi là cặp double? Lưu ý điều này không giống như nói rằng bạn có các thao tác áp dụng cho cả hai theo cách riêng của chúng. Ví dụ: 'cốt truyện (Tọa độ)' quan tâm xem đó Coordlà Polar hay Cartesian. Mặt khác, kiên trì nộp hồ sơ chỉ xử lý dữ liệu như hiện tại. Nếu bạn thực sự có hoạt động chung, hãy xem xét một trong hai xác định một lớp cơ sở, hoặc xác định một chuyển đổi để một std::pair<double, double>hoặc tuplehoặc bất cứ điều gì bạn có trong ngôn ngữ của bạn.

Hơn nữa, một cách tiếp cận có thể là coi một loại Phối hợp là cơ bản hơn và loại khác chỉ đơn thuần là hỗ trợ cho người dùng hoặc tương tác bên ngoài.

Vì vậy, bạn có thể đảm bảo tất cả các hoạt động cơ bản được mã hóa Cartesianvà sau đó cung cấp hỗ trợ để chuyển đổi Polarsang Cartesian. Điều này tránh thực hiện các phiên bản khác nhau của nhiều hoạt động.

Một giải pháp khả thi, tùy thuộc vào ngôn ngữ và nếu bạn biết rằng cả hai lớp sẽ có các phương thức và thao tác tương tự nhau, sẽ là định nghĩa lớp một lần và sử dụng các bí danh loại để đặt tên rõ ràng cho các loại khác nhau.

Điều này cũng có một ưu điểm là miễn là các lớp giống hệt nhau, bạn chỉ có thể duy trì một lớp, nhưng ngay khi bạn cần thay đổi chúng, bạn không cần phải sửa đổi mã bằng cách sử dụng chúng vì các loại đã được sử dụng phân biệt

Một tùy chọn khác, tùy thuộc vào việc sử dụng các lớp (nếu bạn cần đa hình và như vậy) là sử dụng kế thừa công khai cho cả hai loại mới, vì vậy chúng có cùng giao diện chung như loại chung mà cả hai đại diện. Điều này cũng cho phép tiến hóa riêng biệt của các loại.

Tôi tin rằng có cùng tên thành viên là một ý tưởng tồi trong trường hợp này, vì nó làm cho mã dễ bị lỗi hơn.

Hãy tưởng tượng kịch bản: bạn có một vài điểm cartesian: pntA và pntB. Sau đó, bạn quyết định, vì một số lý do, tốt hơn là chúng nên được biểu diễn theo tọa độ cực và thay đổi khai báo và hàm tạo.

Bây giờ, nếu tất cả các hoạt động của bạn chỉ là các cuộc gọi phương thức như:

double distance = pntA.distanceFrom(pntB);

sau đó bạn ổn Nhưng nếu bạn sử dụng các thành viên một cách rõ ràng thì sao? So sánh

double leftMargin = abs(pntA.x - pntB.x);
double leftMargin = abs(pntA.first - pntB.first);

Trong trường hợp đầu tiên, mã sẽ không biên dịch. Bạn sẽ thấy lỗi ngay lập tức và sẽ có thể sửa nó. Nhưng nếu bạn có cùng tên thành viên, lỗi sẽ chỉ ở mức logic, khó phát hiện hơn nhiều.

Nếu bạn viết bằng ngôn ngữ không hướng đối tượng, thì việc chuyển cấu trúc sai sang hàm sẽ dễ dàng hơn. Điều gì ngăn bạn viết mã sau đây?

double distance = calculate_distance_polar(cartesianPointA, polarPointB);

Mặt khác, các loại dữ liệu khác nhau sẽ cho phép bạn tìm ra lỗi trong quá trình biên dịch.