Bạn gọi lớp nào mà không có phương thức?


10

Bạn gọi lớp nào mà không có phương thức?

Ví dụ,

class A
{
  public string something;
  public int a;
}

Trên đây là một lớp học mà không có phương pháp nào. Loại lớp này có một tên đặc biệt?


1
Một lớp không có phương thức?
ChaosPandion

11
Thuật ngữ kỹ thuật là ghi hoặc cấu trúc .
Kilian Foth

4
Một "túi tài sản"
Martin York

Kilian: Tôi thích "cấu trúc được tôn vinh" cho ý nghĩa được thêm vào.
Jason

Câu trả lời:


23

Hầu hết thời gian: Một mô hình chống.

Tại sao? Bởi vì nó tạo điều kiện cho lập trình thủ tục với các lớp "Toán tử" và cấu trúc dữ liệu. Bạn tách dữ liệu và hành vi không chính xác OOP.

Thông thường: Một DTO (Đối tượng truyền dữ liệu)

Chỉ đọc các cơ sở dữ liệu có nghĩa là để trao đổi dữ liệu, xuất phát từ một đối tượng kinh doanh / tên miền.

Đôi khi: Chỉ là cấu trúc dữ liệu.

Đôi khi, bạn chỉ cần có những cấu trúc đó để chứa dữ liệu đơn giản và đơn giản và không có thao tác nào trên đó. Nhưng sau đó tôi sẽ không sử dụng các lĩnh vực công cộng mà là các bộ truy cập (getters và setters).


4
Tôi không khuyến khích mọi người tham gia các lớp chỉ có getters / setters công khai trong java, nó chết não và một số container thậm chí sẽ không chạy mã setter / getter (nhìn vào Glassfish ...), vì vậy đó là mặc định hoặc bạn có bọ cánh cứng. Tôi không tin rằng đóng gói OOP là đúng, hóa ra, hầu hết thời gian, trong hầu hết các ứng dụng, DTO không chỉ cần thiết, mà chúng còn là các lớp thường được sử dụng nhất. Vì vậy, chúng là bất cứ thứ gì ngoại trừ antipotype, thay vào đó tôi sẽ sử dụng từ "khối xây dựng cơ bản".
Aadaam

8
Chúng có thể là một mẫu chống nếu bạn ở trong môi trường OO nghiêm ngặt. Đối với tất cả phần còn lại của thế giới lập trình, việc có các cấu trúc dữ liệu là các bộ sưu tập các trường không đồng nhất đơn giản là một lợi ích rõ ràng so với các lựa chọn thay thế, và thậm chí được khuyến khích trong một nền tảng OO nổi tiếng .
Telastyn

@Aadaam: Bạn đã không hiểu ý tôi. Một DTO không phải là một antipotype. Đôi khi những đối tượng đó hoàn toàn tốt nếu chúng là DTO! Và khi Glassfish không nhìn vào getters và setters, điều đó chỉ có nghĩa là cá thủy tinh không được viết tốt (mặc dù nó khó trong java mà không có bộ truy cập dựng sẵn). Mã này không phải là bản lĩnh, nó là bản tóm tắt hữu ích.
Falcon

4
Nhanh lên, @Aadaam. Ai đó đang đặt trường thành giá trị không hợp lệ, sẽ tàn phá khi đọc sau. Ném một ngoại lệ để bạn có thể phát hiện ra thủ phạm. Lần đầu tiên bạn phải làm một cái gì đó tương tự cho một lĩnh vực công cộng được sử dụng ở 1.000 địa điểm, bạn sẽ muốn có một setter. Các lĩnh vực công cộng có vị trí của chúng, nhưng mô hình getter / setter là phổ biến vì lý do tốt.
Karl Bielefeldt

@KarlBielefeldt: trong một phiên bản cá thủy tinh, tôi có một ngoại lệ duy nhất trong mã setter là thử nghiệm (không có điều kiện), không bao giờ được thực thi. Khách sạn có một biến riêng và hai getters-and-setters công cộng. Các container chỉ đơn giản là phá vỡ các setter. Nếu một cái gì đó thực sự có một giá trị không hợp lệ, cá nhân tôi thích các lớp loại thay vì các giá trị nguyên thủy, nhưng có lẽ đó chỉ là tôi.
Aadaam

9

Tôi gọi nó structhoặc recordbởi vì nó được sử dụng để lưu trữ dữ liệu và điều này rất phổ biến đối với các ngôn ngữ như Cbạn có thể thấy ở đó: struct (ngôn ngữ lập trình C) . Vì vậy, cá nhân tôi thích sử dụng một structthay vì một lớp phù hợp hơn và dễ đọc hơn:

struct A
{
  public string something;
  public int a;
}

Thông thường chúng được sử dụng làm DTO (Đối tượng truyền dữ liệu) như đã nói.


4
Vấn đề với struct là, "struct" là một từ khóa trong nhiều ngôn ngữ. Ví dụ, C # coi các cấu trúc là các loại giá trị có ngữ nghĩa khác nhau. Điều này cũng đúng với "bản ghi" trong một số ngôn ngữ (PL / SQL).
Falcon

5

Chúng được gọi là Các đối tượng __ cũ (PO_Os) trong đó khoảng trống là Java hoặc C hoặc CIL hoặc bất kỳ ngôn ngữ nào bạn đang sử dụng.

Nếu chúng được sử dụng như các khối dữ liệu đơn giản để liên lạc, thì chúng có thể được gọi là Đối tượng truyền dữ liệu (DTO).

Nếu họ đại diện cho một số dữ liệu được cung cấp bên ngoài, họ có thể được gọi là Thực thể .


6
Bạn đang nghĩ về POD - một ý tưởng rất khác. POJO rõ ràng bao gồm "logic kinh doanh", nhưng loại trừ các phụ thuộc vào các khung cụ thể.
Tom Hawtin - tackline

POD được phép có các phương thức, ít nhất là trong C ++. Họ chỉ cần có các hàm tạo nhỏ, hàm hủy, sao chép hàm tạo và hàm tạo gán, chỉ các thành viên dữ liệu công khai, không có lớp cơ sở và không có hàm ảo. Về cơ bản, chúng chỉ cần tương thích với các cấu trúc C.
Dirk Holsopple

2

Tôi sẽ gọi một lớp như vậy là một người giữ dữ liệu có thể thay đổi và đôi khi đã sử dụng một hình thức chung:

class DataHolder<T>
{
   public T dat;
}

Lưu ý rằng việc bọc dattrong một tài sản sẽ làm giảm hiệu suất và không mang lại lợi ích gì, vì không có gì mà người truy cập tài sản có thể làm (ngoài việc đọc / ghi trường) sẽ không phá vỡ một số triển khai. Hơn nữa, có thể cần phải sử dụng Interlockedcác phương thức với dat(hoặc, nếu đó là một cấu trúc, với các trường của chúng), nhưng điều đó sẽ không thể thực hiện được nếu datđược bọc trong một thuộc tính.

Lưu ý rằng mặc dù chủ sở hữu dữ liệu có thể thay đổi có thể hữu ích cho các loại (có thể thay đổi hoặc không) có thể giữ dữ liệu, chúng không thể được sử dụng một cách an toàn để trao đổi dữ liệu theo cách tương tự như các loại không thay đổi. Ví dụ: một tuyên bố như:

myData = myCollection.GetData(myKey);

sẽ có ý nghĩa rõ ràng nếu GetDatatrả về một loại lớp bất biến hoặc một cấu trúc ("có thể thay đổi" hoặc không) không chứa các tham chiếu đến dữ liệu có thể thay đổi. Tuy nhiên, nếu nó trả về một đối tượng lớp có thể thay đổi, thì sẽ không rõ liệu có bất kỳ thay đổi nào đối với đối tượng đó sẽ bị bỏ qua bởi bộ sưu tập bên dưới hay không, dẫn đến cập nhật sạch cho nó hoặc gây ra một số hành vi không thể đoán trước hoặc không thể đoán trước.

Nếu một người muốn có một dữ liệu trả về bộ sưu tập trong một đối tượng có thể thay đổi, mô hình chính xác thường sẽ là một cái gì đó như:

var myData = new WhateverType();
myCollection.GetData(myKey, myData);
myData.ModifySomehow();
myCollection.StoreData(myKey, myData);

Sử dụng phương pháp đó, có một hàm ý rõ ràng GetDatasẽ gây ra myDatadữ liệu từ bộ sưu tập, nhưng myCollectionsẽ không được dự kiến ​​sẽ giữ một tham chiếu đến nó sau khi chức năng hoàn thành, cũng không sử dụng nó cho bất kỳ mục đích nào khác. StoreDatacũng muốn sao chép thông tin myDatavào cấu trúc dữ liệu nội bộ của chính nó mà không giữ tham chiếu. Lưu ý rằng một ưu điểm của phương pháp này là nếu mã máy khách sẽ đọc nhiều mục dữ liệu trong một vòng lặp, thì nó có thể tạo một phiên bản myDatabên ngoài vòng lặp một cách an toàn , sau đó sử dụng lại ví dụ đó mỗi lần. Tương tự như vậy, myCollectioncó thể có thể sử dụng lại thể hiện đối tượng được liên kết với khóa (sao chép dữ liệu từ thể hiện được truyền vào) mà không phải tạo một thể hiện mới.


0

Tùy thuộc vào bối cảnh, tôi gọi chúng là Thực thể. Trên các ứng dụng kinh doanh nhàm chán của tôi, chúng thường ánh xạ 1: 1 đến DER của tôi.


0

Tôi sẽ gọi nó là a Schema.

Điều này bao gồm nhiều cách sử dụng, chẳng hạn như biểu diễn một bảng cơ sở dữ liệu hoặc một bản ghi được giải trừ hoặc DTO, v.v.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.