Bạn thường gửi các đối tượng hoặc các biến thành viên của chúng vào các hàm?

Mà thường được chấp nhận thực hành giữa hai trường hợp này:

function insertIntoDatabase(Account account, Otherthing thing) {
    database.insertMethod(account.getId(), thing.getId(), thing.getSomeValue());
}

hoặc là

function insertIntoDatabase(long accountId, long thingId, double someValue) {
    database.insertMethod(accountId, thingId, someValue);
}

Nói cách khác, nói chung là tốt hơn để vượt qua toàn bộ các đối tượng xung quanh hay chỉ các lĩnh vực bạn cần?

Không phải nói chung là tốt hơn so với người khác. Đó là một cuộc gọi phán xét mà bạn phải thực hiện trên cơ sở từng trường hợp.

Nhưng trong thực tế, khi bạn ở một vị trí mà bạn thực sự có thể đưa ra quyết định này, đó là vì bạn phải quyết định lớp nào trong kiến ​​trúc chương trình tổng thể sẽ phá vỡ đối tượng thành nguyên thủy, vì vậy bạn nên suy nghĩ về toàn bộ cuộc gọi ngăn xếp , không chỉ là một phương thức mà bạn hiện đang làm. Có lẽ việc chia tay phải được thực hiện ở đâu đó và sẽ không có ý nghĩa (hoặc sẽ không dễ bị lỗi) để thực hiện nhiều lần. Câu hỏi là nơi đó nên ở đâu.

Cách dễ nhất để đưa ra quyết định này là suy nghĩ về mã nào nên hoặc không cần phải thay đổi nếu đối tượng bị thay đổi . Hãy mở rộng ví dụ của bạn một chút:

function addWidgetButtonClicked(clickEvent) {
    // get form data
    // get user's account
    insertIntoDatabase(account, data);
}
function insertIntoDatabase(Account account, Otherthing data) {
    // open database connection
    // check data doesn't already exist
    database.insertMethod(account.getId(), data.getId(), data.getSomeValue());
}

đấu với

function addWidgetButtonClicked(clickEvent) {
    // get form data
    // get user's account
    insertIntoDatabase(account.getId(), data.getId(), data.getSomeValue());
}
function insertIntoDatabase(long accountId, long dataId, double someValue) {
    // open database connection
    // check data doesn't already exist
    database.insertMethod(accountId, dataId, someValue);
}

Trong phiên bản đầu tiên, mã UI được truyền một cách mù quáng datađối tượng và tùy thuộc vào mã cơ sở dữ liệu để trích xuất các trường hữu ích từ nó. Trong phiên bản thứ hai, mã UI đang chia nhỏ datađối tượng vào các trường hữu ích của nó và mã cơ sở dữ liệu nhận chúng trực tiếp mà không biết chúng đến từ đâu. Hàm ý chính là, nếu cấu trúc của datađối tượng thay đổi theo một cách nào đó, phiên bản đầu tiên sẽ chỉ yêu cầu mã cơ sở dữ liệu để thay đổi, trong khi phiên bản thứ hai sẽ chỉ yêu cầu mã UI thay đổi . Cái nào trong hai cái này đúng phụ thuộc phần lớn vào loại dữ liệu mà datađối tượng chứa, nhưng nó thường rất rõ ràng. Ví dụ, nếudatalà một chuỗi do người dùng cung cấp như "20/05/1999", nó phải tùy thuộc vào mã UI để chuyển đổi nó thành một Dateloại thích hợp trước khi chuyển nó vào.

Đây không phải là một danh sách đầy đủ, nhưng hãy xem xét một số yếu tố sau đây khi quyết định liệu một đối tượng có nên được truyền cho một phương thức như là một đối số hay không:

Là đối tượng bất biến? Là chức năng 'tinh khiết'?

Tác dụng phụ là một xem xét quan trọng cho khả năng duy trì mã của bạn. Khi bạn thấy mã có rất nhiều đối tượng trạng thái có thể thay đổi được truyền đi khắp nơi, mã đó thường ít trực quan hơn (giống như cách các biến trạng thái toàn cầu thường có thể ít trực quan hơn) và việc gỡ lỗi thường trở nên khó khăn và mất thời gian hơn- tiêu thụ.

Như một quy tắc tự nhiên, nhằm mục đích đảm bảo, càng nhiều càng tốt, rằng bất kỳ đối tượng nào bạn truyền đến một phương thức rõ ràng là bất biến.

Tránh (một lần nữa, càng xa càng tốt) bất kỳ thiết kế nào theo đó trạng thái của một đối số dự kiến ​​sẽ được thay đổi do kết quả của một cuộc gọi chức năng - một trong những lập luận mạnh mẽ nhất cho phương pháp này là Nguyên tắc tối thiểu ngạc nhiên ; tức là ai đó đang đọc mã của bạn và thấy một đối số được truyền vào một hàm là 'ít có khả năng' để mong đợi trạng thái của nó thay đổi sau khi hàm được trả về.

Có bao nhiêu đối số mà phương thức đã có?

Các phương thức có danh sách đối số quá dài (ngay cả khi hầu hết các đối số đó có giá trị 'mặc định') bắt đầu trông giống như mùi mã. Tuy nhiên, đôi khi các chức năng như vậy là cần thiết và bạn có thể xem xét việc tạo một lớp có mục đích duy nhất là hoạt động như một Đối tượng tham số .

Cách tiếp cận này có thể liên quan đến một lượng nhỏ ánh xạ mã soạn sẵn bổ sung từ đối tượng 'nguồn' của bạn sang đối tượng tham số của bạn, tuy nhiên, đó là một chi phí khá thấp cả về hiệu suất và độ phức tạp, tuy nhiên, có một số lợi ích về việc tách rời và đối tượng bất biến.

Đối tượng được truyền có thuộc về một "lớp" trong ứng dụng của bạn không (ví dụ: ViewModel hoặc Thực thể ORM?)

Hãy suy nghĩ về Tách biệt mối quan tâm (SoC) . Đôi khi, hãy tự hỏi liệu đối tượng "thuộc" của cùng một lớp hoặc mô-đun trong đó phương thức của bạn tồn tại (ví dụ: thư viện trình bao bọc API cuộn tay hoặc Lớp logic nghiệp vụ cốt lõi của bạn, v.v.) có thể thông báo liệu đối tượng đó có thực sự được chuyển đến đó không phương pháp.

SoC là một nền tảng tốt để viết mã mô-đun sạch, kết hợp lỏng lẻo. ví dụ: một đối tượng thực thể ORM (ánh xạ giữa mã của bạn và lược đồ cơ sở dữ liệu của bạn) lý tưởng không nên được chuyển xung quanh trong lớp doanh nghiệp của bạn hoặc tệ hơn trong lớp trình bày / giao diện người dùng của bạn.

Trong trường hợp truyền dữ liệu giữa các 'lớp', việc có các tham số dữ liệu đơn giản được truyền vào một phương thức thường được ưu tiên hơn là truyền vào một đối tượng từ lớp 'sai'. Mặc dù có lẽ nên có các mô hình riêng biệt tồn tại ở lớp 'bên phải' mà bạn có thể ánh xạ thay thế.

Là chức năng chính nó quá lớn và / hoặc phức tạp?

Khi một hàm cần nhiều mục dữ liệu, có thể đáng để xem xét liệu hàm đó có đảm nhận quá nhiều trách nhiệm hay không; tìm kiếm các cơ hội tiềm năng để tái cấu trúc bằng cách sử dụng các đối tượng nhỏ hơn và các hàm ngắn hơn, đơn giản hơn.

Hàm nên là một đối tượng lệnh / truy vấn?

Trong một số trường hợp, mối quan hệ giữa dữ liệu và chức năng có thể gần gũi; trong những trường hợp đó, hãy xem xét liệu Đối tượng lệnh hay Đối tượng truy vấn sẽ phù hợp.

Việc thêm một tham số đối tượng vào một phương thức có buộc lớp chứa phải chấp nhận các phụ thuộc mới không?

Đôi khi, đối số mạnh nhất cho các đối số "Dữ liệu cũ đơn giản" chỉ đơn giản là lớp nhận đã được khép kín gọn gàng và việc thêm một tham số đối tượng vào một trong các phương thức của nó sẽ gây ô nhiễm cho lớp (hoặc nếu lớp đã bị ô nhiễm, thì nó sẽ bị ô nhiễm làm cho entropy hiện tại tồi tệ hơn)

Bạn có thực sự cần phải vượt qua một đối tượng hoàn chỉnh hay bạn chỉ cần một phần nhỏ trong giao diện của đối tượng đó?

Hãy xem xét Nguyên tắc phân chia giao diện liên quan đến các chức năng của bạn - tức là khi truyền vào một đối tượng, nó chỉ nên phụ thuộc vào các phần của giao diện của đối số mà nó (hàm) thực sự cần.

Vì vậy, khi bạn tạo một hàm, bạn đang ngầm tuyên bố một số hợp đồng với mã đang gọi nó. "Hàm này lấy thông tin này và biến nó thành thứ khác (có thể có tác dụng phụ)".

Vì vậy, hợp đồng của bạn nên hợp lý với các đối tượng (tuy nhiên chúng được triển khai) hoặc với các trường chỉ là một phần của những đối tượng khác này. Bạn đang thêm khớp nối, nhưng với tư cách là lập trình viên, bạn phải quyết định nơi nó thuộc về.

Nói chung , nếu nó không rõ ràng, thì hãy ưu tiên các dữ liệu nhỏ nhất cần thiết để chức năng hoạt động. Điều đó thường có nghĩa là chỉ truyền vào các trường, vì hàm không cần các thứ khác được tìm thấy trong các đối tượng. Nhưng đôi khi lấy toàn bộ đối tượng là chính xác hơn vì nó dẫn đến ít tác động hơn khi mọi thứ chắc chắn thay đổi trong tương lai.

Nó phụ thuộc.

Để giải thích, các tham số mà phương thức của bạn chấp nhận phải phù hợp về mặt ngữ nghĩa với những gì bạn đang cố gắng thực hiện. Xem xét một EmailInvitervà ba triển khai có thể có của một invitephương pháp:

void invite(String emailAddressString) {
  invite(EmailAddress.parse(emailAddressString));
}
void invite(EmailAddress emailAddress) {
  ...
}
void invite(User user) {
  invite(user.getEmailAddress());
}

Đi qua một Stringnơi mà bạn nên vượt qua trong một EmailAddressthiếu sót vì không phải tất cả các chuỗi đều là địa chỉ email. Các EmailAddresslớp học tốt hơn ngữ nghĩa phù hợp với hành vi của phương pháp. Tuy nhiên, đi qua trong một Usercũng là thiếu sót bởi vì tại sao trên trái đất nên EmailInviterhạn chế mời người dùng? Còn doanh nghiệp thì sao? Điều gì xảy ra nếu bạn đang đọc địa chỉ email từ một tệp hoặc một dòng lệnh và chúng không được liên kết với người dùng? Danh sách mail? Danh sách cứ kéo dài.

Có một vài dấu hiệu cảnh báo bạn có thể sử dụng để được hướng dẫn ở đây. Nếu bạn đang sử dụng một loại giá trị đơn giản như Stringhoặc intnhưng không phải tất cả các chuỗi hoặc số nguyên đều hợp lệ hoặc có gì đó "đặc biệt" về chúng, bạn nên sử dụng loại có ý nghĩa hơn. Nếu bạn đang sử dụng một đối tượng và điều duy nhất bạn làm là gọi một getter, thì bạn nên chuyển trực tiếp đối tượng trong getter. Những hướng dẫn này không khó cũng không nhanh, nhưng ít hướng dẫn.

Clean Code khuyên bạn nên có càng ít đối số càng tốt, điều đó có nghĩa là Object thường sẽ là cách tiếp cận tốt hơn và tôi nghĩ nó có ý nghĩa. bởi vì

insertIntoDatabase(new Account(id) , new Otherthing(id, "Value"));

là một cuộc gọi dễ đọc hơn

insertIntoDatabase(myAccount.getId(), myOtherthing.getId(), myOtherthing.getValue() );

Đi qua đối tượng, không phải là trạng thái cấu thành của nó. Điều này hỗ trợ các nguyên tắc hướng đối tượng của đóng gói và ẩn dữ liệu. Phơi bày bộ phận bên trong của một đối tượng trong các giao diện phương thức khác nhau khi không cần thiết vi phạm các nguyên tắc OOP cốt lõi.

Điều gì xảy ra nếu bạn thay đổi các lĩnh vực trong Otherthing? Có thể bạn thay đổi một loại, thêm một trường hoặc xóa một trường. Bây giờ tất cả các phương pháp như phương pháp bạn đề cập trong câu hỏi của bạn cần phải được cập nhật. Nếu bạn vượt qua xung quanh đối tượng, không có thay đổi giao diện.

Lần duy nhất bạn nên viết một phương thức chấp nhận các trường trên một đối tượng là khi viết một phương thức để truy xuất đối tượng:

public User getUser(String primaryKey) {
  return ...;
}

Tại điểm thực hiện cuộc gọi đó, mã gọi chưa có tham chiếu đến đối tượng vì điểm gọi phương thức đó là để lấy đối tượng.

Từ góc độ bảo trì, các đối số nên được phân biệt rõ ràng với nhau tốt nhất là ở cấp độ trình biên dịch.

// this has exactly one way to call it
insertIntoDatabase(Account ..., Otherthing ...)

// the parameter order can be confused in practice
insertIntoDatabase(long ..., long ...)

Thiết kế đầu tiên dẫn đến việc phát hiện sớm các lỗi. Thiết kế thứ hai có thể dẫn đến các vấn đề thời gian chạy tinh tế không hiển thị trong thử nghiệm. Do đó, thiết kế đầu tiên sẽ được ưu tiên.

Trong hai, sở thích của tôi là phương pháp đầu tiên:

function insertIntoDatabase(Account account, Otherthing thing) { database.insertMethod(account.getId(), thing.getId(), thing.getSomeValue()); }

Lý do là những thay đổi được thực hiện cho một trong hai đối tượng trên đường, miễn là những thay đổi đó bảo toàn những getters đó để thay đổi được minh bạch bên ngoài đối tượng, thì bạn có ít mã để thay đổi và kiểm tra và ít có cơ hội phá vỡ ứng dụng.

Đây chỉ là quá trình suy nghĩ của tôi, chủ yếu dựa trên cách tôi thích làm việc và cấu trúc những thứ có tính chất này và điều đó chứng tỏ là khá dễ quản lý và có thể duy trì trong thời gian dài.

Tôi sẽ không tham gia vào các quy ước đặt tên nhưng sẽ chỉ ra rằng mặc dù phương thức này có từ "cơ sở dữ liệu" trong đó, cơ chế lưu trữ đó có thể thay đổi. Từ mã được hiển thị, không có gì buộc chức năng vào nền tảng lưu trữ cơ sở dữ liệu đang được sử dụng - hoặc ngay cả khi đó là cơ sở dữ liệu. Chúng tôi chỉ giả định vì nó là trong tên. Một lần nữa, giả sử những getters đó luôn được bảo tồn, việc thay đổi cách thức / nơi các đối tượng này được lưu trữ sẽ dễ dàng.

Tôi sẽ nghĩ lại chức năng và hai đối tượng mặc dù bởi vì bạn có một chức năng có sự phụ thuộc vào hai cấu trúc đối tượng và đặc biệt là các getters đang được sử dụng. Có vẻ như chức năng này đang buộc hai đối tượng đó vào một điều tích lũy được duy trì. Ruột của tôi đang nói với tôi rằng một đối tượng thứ ba có thể có ý nghĩa. Tôi cần biết thêm về các đối tượng này và cách chúng liên quan đến thực tế và lộ trình dự đoán. Nhưng ruột của tôi đang nghiêng về hướng đó.

Khi mã hiện tại, câu hỏi đặt ra "Hàm này sẽ ở đâu hoặc nên ở đâu?" Đây có phải là một phần của Tài khoản hay OtherThing không? Nó đi đâu?

Tôi đoán đã có một "cơ sở dữ liệu" đối tượng thứ ba và tôi đang nghiêng về việc đưa chức năng này vào đối tượng đó, và sau đó nó trở thành công việc cho các đối tượng đó để có thể xử lý một Tài khoản và một cách khác, chuyển đổi, và sau đó cũng duy trì kết quả .

Nếu bạn đã đi xa như làm cho đối tượng thứ 3 đó phù hợp với mẫu ánh xạ quan hệ đối tượng (ORM), thì tốt hơn hết. Điều đó sẽ làm cho rất rõ ràng đối với bất kỳ ai làm việc với mã để hiểu "Ah, đây là nơi Tài khoản và OtherThing bị đập vỡ cùng nhau và tồn tại".

Nhưng nó cũng có thể có ý nghĩa để giới thiệu một đối tượng thứ tư, xử lý công việc kết hợp và chuyển đổi một Tài khoản và OtherThing, nhưng không xử lý các cơ chế tồn tại. Tôi sẽ làm điều đó nếu bạn dự đoán được nhiều tương tác hơn với hoặc giữa hai đối tượng này, bởi vì khi phát triển, tôi sẽ muốn các bit kiên trì được đưa vào một đối tượng chỉ quản lý sự bền bỉ.

Tôi sẽ bắn để giữ thiết kế sao cho bất kỳ một trong các Tài khoản, OtherThing hoặc đối tượng ORM thứ ba có thể được thay đổi mà không phải thay đổi ba đối tượng khác. Trừ khi có một lý do chính đáng để không, tôi muốn Tài khoản và Khác được độc lập và không phải biết các hoạt động và cấu trúc bên trong của nhau.

Tất nhiên, nếu tôi biết bối cảnh đầy đủ rằng điều này sẽ xảy ra, tôi có thể thay đổi hoàn toàn ý tưởng của mình. Một lần nữa, đây chỉ là cách tôi nghĩ khi tôi nhìn thấy những thứ như thế này, và một người gầy.

Cả hai phương pháp đều có ưu và nhược điểm riêng. Điều gì là tốt hơn trong một kịch bản phụ thuộc rất nhiều vào trường hợp sử dụng trong tầm tay.

Nhiều tham số Pro, tham chiếu đối tượng Con:

• Người gọi không bị ràng buộc với một lớp cụ thể , nó có thể chuyển các giá trị từ các nguồn khác nhau hoàn toàn
• Trạng thái đối tượng an toàn khỏi bị sửa đổi bất ngờ bên trong thực thi phương thức.

Tham chiếu đối tượng Pro:

• Xóa giao diện rằng phương thức được liên kết với loại tham chiếu Đối tượng, khiến việc vô tình chuyển các giá trị không liên quan / không hợp lệtrở nên khó khăn
• Đổi tên một trường / getter yêu cầu thay đổi ở tất cả các yêu cầu của phương thức và không chỉ trong việc thực hiện nó
• Nếu một thuộc tính mới được thêm vào và cần được thông qua, không cần thay đổi trong chữ ký phương thức
• Phương thức có thể biến đổi trạng thái đối tượng
• Việc truyền quá nhiều biến của các kiểu nguyên thủy tương tự làm cho người gọi bối rối về thứ tự (vấn đề mẫu Builder)

Vì vậy, những gì cần phải được sử dụng và khi phụ thuộc rất nhiều vào các trường hợp sử dụng

1. Truyền các tham số riêng lẻ: Nói chung, nếu phương thức không liên quan gì đến loại đối tượng, tốt hơn là truyền danh sách tham số riêng để nó có thể áp dụng cho đối tượng rộng hơn.
2. Giới thiệu đối tượng mô hình mới: nếu danh sách tham số tăng lên lớn (hơn 3), tốt hơn là giới thiệu một đối tượng mô hình mới thuộc API được gọi (ưu tiên mẫu xây dựng)
3. Truyền tham chiếu đối tượng: Nếu phương thức có liên quan đến các đối tượng miền, thì tốt hơn là từ quan điểm duy trì và khả năng đọc để chuyển các tham chiếu đối tượng.

Ở một bên, bạn có một Tài khoản và một đối tượng khác. Mặt khác, bạn có khả năng chèn một giá trị vào cơ sở dữ liệu, được cung cấp id của tài khoản và id của một thứ khác. Đó là hai thứ đã cho.

Bạn có thể viết một phương thức lấy Tài khoản và các thứ khác làm đối số. Về mặt chuyên nghiệp, người gọi không cần biết bất kỳ chi tiết nào về Tài khoản và các thứ khác. Về mặt tiêu cực, callee cần biết về các phương pháp của Tài khoản và các thứ khác. Ngoài ra, không có cách nào để chèn bất cứ thứ gì khác vào cơ sở dữ liệu hơn giá trị của đối tượng Otherthing và không có cách nào để sử dụng phương thức này nếu bạn có id của một đối tượng tài khoản, nhưng không phải chính đối tượng đó.

Hoặc bạn có thể viết một phương thức lấy hai id và một giá trị làm đối số. Về mặt tiêu cực, người gọi cần biết chi tiết về Tài khoản và các thứ khác. Và có thể có một tình huống mà bạn thực sự cần nhiều chi tiết hơn về Tài khoản hoặc Thứ khác ngoài chỉ là id để chèn vào cơ sở dữ liệu, trong trường hợp đó giải pháp này hoàn toàn vô dụng. Mặt khác, hy vọng không có kiến ​​thức về Tài khoản và các thứ khác là cần thiết trong callee, và có sự linh hoạt hơn.

Cuộc gọi phán xét của bạn: Có cần linh hoạt hơn không? Đây thường không phải là vấn đề của một cuộc gọi, nhưng sẽ nhất quán trong tất cả các phần mềm của bạn: Bạn sử dụng id của Tài khoản hầu hết thời gian hoặc bạn sử dụng các đối tượng. Trộn nó sẽ giúp bạn trở thành tồi tệ nhất của cả hai thế giới.

Trong C ++, bạn có thể có một phương thức lấy hai id cộng với giá trị và một phương thức nội tuyến lấy Tài khoản và Thứ khác, vì vậy bạn có cả hai cách với chi phí bằng không.