Khi nào là nỗi ám ảnh nguyên thủy không phải là một mùi mã?

Tôi đã đọc rất nhiều bài báo gần đây mô tả nỗi ám ảnh nguyên thủy như một mùi mã.

Có hai lợi ích của việc tránh nỗi ám ảnh nguyên thủy:

1. Nó làm cho mô hình miền rõ ràng hơn. Ví dụ: tôi có thể nói chuyện với một nhà phân tích kinh doanh về Mã bưu điện thay vì một chuỗi chứa mã bưu điện.

2. Tất cả các xác nhận là ở một nơi thay vì trên ứng dụng.

Có rất nhiều bài viết trên mạng mô tả khi đó là mùi mã. Ví dụ, tôi có thể thấy lợi ích của việc loại bỏ nỗi ám ảnh nguyên thủy đối với một mã bài đăng như thế này:

public class Address
{
    public ZipCode ZipCode { get; set; }
}

Đây là hàm tạo của ZipCode:

public ZipCode(string value)
    {
        // Perform regex matching to verify XXXXX or XXXXX-XXXX format
        _value = value;
    }

Bạn sẽ phá vỡ nguyên tắc DRY khi đưa logic xác thực đó vào mọi nơi sử dụng mã zip.

Tuy nhiên, những gì về các đối tượng sau đây:

1. Ngày sinh: Kiểm tra xem lớn hơn ngày và ít hơn ngày hôm nay.

2. Mức lương: Kiểm tra xem lớn hơn hoặc bằng không.

Bạn có thể tạo đối tượng DateOfBirth và đối tượng Mức lương không? Lợi ích là bạn có thể nói về họ khi mô tả mô hình miền. Tuy nhiên, đây có phải là một trường hợp áp đảo vì không có nhiều xác nhận. Có một quy tắc mô tả khi nào và khi nào không loại bỏ nỗi ám ảnh nguyên thủy hay bạn nên luôn luôn làm điều đó nếu có thể?

Tôi đoán rằng tôi có thể tạo một bí danh loại thay vì một lớp, điều này sẽ giúp với điểm một ở trên.

Nỗi ám ảnh nguyên thủy đang sử dụng các kiểu dữ liệu nguyên thủy để thể hiện ý tưởng miền.

Ngược lại sẽ là "mô hình miền", hoặc có thể là "kỹ thuật quá mức".

Bạn có thể tạo đối tượng DateOfBirth và đối tượng Mức lương không?

Giới thiệu một đối tượng Mức lương có thể là một ý tưởng tốt vì lý do sau: các số hiếm khi đứng một mình trong mô hình miền, chúng hầu như luôn có một thứ nguyên và một đơn vị. Chúng ta thường không mô hình hóa bất cứ điều gì hữu ích nếu chúng ta thêm chiều dài vào thời gian hoặc khối lượng và chúng ta hiếm khi nhận được kết quả tốt khi trộn lẫn mét và chân.

Đối với DateOfBirth, có lẽ - có hai vấn đề cần xem xét. Đầu tiên, việc tạo ra một Ngày không nguyên thủy cung cấp cho bạn một nơi để tập trung tất cả các mối quan tâm kỳ lạ xung quanh toán học ngày. Nhiều ngôn ngữ cung cấp một trong số đó; DateTime , java.util.Date . Đây là những triển khai bất khả tri của miền, nhưng chúng không phải là nguyên thủy.

Thứ hai, DateOfBirthkhông thực sự là một thời gian ngày; ở Mỹ, "ngày sinh" là một cấu trúc văn hóa / tiểu thuyết hợp pháp. Chúng tôi có xu hướng đo ngày tháng năm sinh từ các địa phương ngày một người sinh; Bob, sinh ra ở California, có thể có ngày sinh "sớm hơn" Alice, sinh ra ở New York, mặc dù anh ấy là người trẻ hơn trong hai người.

Có một quy tắc mô tả khi nào và khi nào không loại bỏ nỗi ám ảnh nguyên thủy hay bạn nên luôn luôn làm điều đó nếu có thể.

Chắc chắn không phải lúc nào cũng vậy; tại các ranh giới, các ứng dụng không hướng đối tượng . Nó khá phổ biến để xem các nguyên thủy được sử dụng để mô tả các hành vi trong các bài kiểm tra .

Thành thật mà nói: nó phụ thuộc.

Luôn có nguy cơ áp đảo mã của bạn. DateOfBirth và Salary sẽ được sử dụng rộng rãi như thế nào? Bạn sẽ chỉ sử dụng chúng trong ba lớp kết hợp chặt chẽ, hoặc chúng sẽ được sử dụng trên tất cả các ứng dụng? Bạn có "chỉ" gói chúng trong Loại / Lớp của riêng mình để thực thi một ràng buộc đó hay bạn có thể nghĩ ra nhiều ràng buộc / chức năng thực sự thuộc về nó không?

Hãy lấy Mức lương làm ví dụ: Bạn có bất kỳ hoạt động nào với "Mức lương" (ví dụ: xử lý các loại tiền tệ khác nhau hoặc có thể là hàm toString ()) không? Hãy xem xét mức lương là gì / khi bạn không xem nó như một người nguyên thủy đơn giản, và có một cơ hội tốt để Salary trở thành lớp học của riêng mình.

Một quy tắc có thể có thể phụ thuộc vào lớp của chương trình. Đối với miền (DDD) aka Lớp thực thể (Martin, 2018), điều này cũng có thể là "để tránh các nguyên thủy cho bất cứ điều gì đại diện cho một khái niệm kinh doanh / tên miền". Các biện minh được OP tuyên bố: một mô hình miền biểu cảm hơn, xác thực quy tắc kinh doanh, làm cho các khái niệm ngầm rõ ràng (Evans, 2004).

Một bí danh loại có thể là một thay thế nhẹ (Ghosh, 2017) và được tái cấu trúc thành một lớp thực thể khi cần thiết. Ví dụ, đầu tiên chúng ta có thể yêu cầu Salarybe >=0, và sau đó quyết định không cho phép $100.33333và bất cứ điều gì ở trên $10,000,000(trong đó sẽ bị phá sản các khách hàng). Việc sử dụng Nonnegativenguyên thủy để đại diện Salaryvà các khái niệm khác sẽ làm phức tạp việc tái cấu trúc này.

Tránh nguyên thủy cũng có thể giúp tránh kỹ thuật quá mức. Giả sử chúng ta cần kết hợp Mức lương và Ngày sinh thành một cấu trúc dữ liệu: ví dụ: để có ít tham số phương thức hơn hoặc truyền dữ liệu giữa các mô-đun. Sau đó, chúng ta có thể sử dụng một tuple với loại (Salary, DateOfBirth). Thật vậy, một tuple với nguyên thủy, (Nonnegative, Nonnegative)là không chính xác, trong khi một số cồng kềnh class EmployeeDatasẽ ẩn các trường bắt buộc trong số những người khác. Chữ ký được nói calcPension(d: (Salary, DateOfBirth))là tập trung hơn so với trong calcPension(d: EmployeeData), vi phạm Nguyên tắc phân chia giao diện. Tương tự như vậy, một chuyên ngành class SalaryAndDateOfBirthcó vẻ khó xử và có lẽ là một quá mức cần thiết. Sau đó, chúng ta có thể chọn định nghĩa một lớp dữ liệu; bộ dữ liệu và các loại miền nguyên tố cho phép chúng tôi trì hoãn các quyết định đó.

Trong một lớp bên ngoài (ví dụ GUI), có thể có ý nghĩa để "lột" các thực thể xuống các nguyên hàm cấu thành của chúng (ví dụ để đưa vào DAO). Điều này ngăn chặn sự trừu tượng miền bị rò rỉ vào các lớp bên ngoài, như được ủng hộ trong Martin (2018).

Tài liệu tham khảo
E. Evans, "Thiết kế hướng tên miền", 2004
D. Ghosh, "Mô hình miền chức năng và phản ứng", 2017
RC Martin, "Kiến trúc sạch", 2018

Tốt hơn chịu đựng nỗi ám ảnh nguyên thủy hoặc là một phi hành gia kiến ​​trúc ?

Cả hai trường hợp đều là bệnh lý, trong một trường hợp bạn có quá ít sự trừu tượng, dẫn đến sự lặp lại và dễ dàng nhầm một quả táo với một quả cam, và trong trường hợp khác, bạn đã quên dừng lại với nó và bắt đầu hoàn thành công việc, khiến bạn khó có thể hoàn thành mọi việc .

Như gần như luôn luôn, bạn muốn điều độ, một cách trung bình được coi là tốt.

Hãy nhớ rằng một tài sản có một tên, ngoài một loại. Ngoài ra, việc phân tách một địa chỉ thành các phần cấu thành của nó có thể quá hạn chế nếu luôn được thực hiện theo cùng một cách. Không phải tất cả thế giới là trung tâm thành phố NY.

Nếu bạn đã có một lớp lương, nó có thể có các phương thức như ApplyRaise.

Mặt khác, lớp ZipCode của bạn không cần phải xác thực nội bộ để tránh trùng lặp xác thực ở mọi nơi bạn có thể có lớp ZipCodeValidator có thể được tiêm, vì vậy nếu hệ thống của bạn chạy cả hai địa chỉ ở Hoa Kỳ và Vương quốc Anh, bạn chỉ cần tiêm trình xác nhận chính xác và khi bạn phải xử lý các địa chỉ AUS, bạn chỉ cần thêm trình xác nhận mới.

Một mối quan tâm khác là nếu bạn phải ghi dữ liệu vào cơ sở dữ liệu thông qua EntityFramework thì nó sẽ cần biết cách xử lý Mức lương hoặc ZipCode.

Không có câu trả lời rõ ràng về việc vẽ ranh giới giữa các lớp thông minh nên như thế nào, nhưng tôi sẽ nói rằng tôi có xu hướng chuyển logic kinh doanh, như xác nhận hợp lệ, sang các lớp logic nghiệp vụ có các lớp dữ liệu là dữ liệu thuần túy để làm việc tốt hơn với EntityFramework.

Đối với việc sử dụng bí danh loại, tên thành viên / thuộc tính sẽ cung cấp tất cả thông tin cần thiết về nội dung, vì vậy tôi sẽ không sử dụng bí danh loại.

(Câu hỏi có lẽ thực sự là gì)

Khi nào việc sử dụng loại nguyên thủy không phải là mùi mã?

(Câu trả lời)

Khi tham số không có quy tắc trong đó - hãy sử dụng kiểu nguyên thủy.

Sử dụng loại nguyên thủy cho các mục như:

htmlEntityEncode(string value)

Sử dụng đối tượng cho các mục như:

numberOfDaysSinceUnixEpoch(SimpleDate value)

Ví dụ thứ hai có quy tắc trong nó, ví dụ, đối tượng SimpleDatebao gồm Year, Monthvà Day. Thông qua việc sử dụng Object trong trường hợp này, khái niệm SimpleDatehợp lệ có thể được gói gọn trong đối tượng.

Ngoài các ví dụ điển hình về địa chỉ email hoặc mã zip được đưa ra ở nơi khác trong câu hỏi này, tôi thấy việc tái cấu trúc khỏi Nỗi ám ảnh nguyên thủy có thể đặc biệt hữu ích với ID thực thể (xem https://andrewlock.net/USE-strongly-typed-entity -ids-to-tránh-primitive-obsession-part-1 / cho một ví dụ về cách thực hiện trong .NET).

Tôi đã mất số lần một lỗi xuất hiện do một phương thức có chữ ký như thế này:

int leaveId = 12345;
int submitterId = 23456;
int approverId = 34567;

SubmitLeaveApplication(leaveId, approverId, submitterId);

public void SubmitLeaveApplication(int leaveId, int submitterId, int approverId) {
  // implementation here
}

Biên dịch tốt, và nếu bạn không nghiêm ngặt với thử nghiệm đơn vị của mình, nó cũng có thể vượt qua điều đó. Tuy nhiên, hãy cấu trúc lại các ID thực thể đó thành các lớp dành riêng cho miền và các lỗi thời gian biên dịch:

LeaveId leaveId = 12345;
SubmitterId submitterId = 23456;
ApproverId approverId = 34567;

SubmitLeaveApplication(leaveId, approverId, submitterId);

public void SubmitLeaveApplication(LeaveId leaveId, SubmitterId submitterId, ApproverId approverId) {
  // implementation here
}

Hãy tưởng tượng phương thức đó có tỷ lệ lên tới 10 tham số trở lên, tất cả các intloại dữ liệu (không bao giờ ngửi thấy mùi mã Danh sách tham số dài ). Điều đó còn tồi tệ hơn khi bạn sử dụng một cái gì đó như AutoMapper để trao đổi giữa các đối tượng miền và DTO và tái cấu trúc mà bạn làm không được chọn bởi ánh xạ tự động.

Bạn sẽ phá vỡ nguyên tắc DRY khi đưa logic xác thực đó vào mọi nơi sử dụng mã zip.

Mặt khác, khi giao dịch với nhiều quốc gia khác nhau và các hệ thống mã zip khác nhau của họ, điều đó có nghĩa là bạn không thể xác thực mã zip trừ khi bạn biết quốc gia đó. Vậy bạnZipCode lớp học cũng cần phải lưu trữ đất nước.

Nhưng sau đó, bạn có lưu trữ riêng quốc gia như là một phần của Address(mà mã zip cũng là một phần của) và một phần của mã zip (để xác thực) không?

• Nếu bạn làm thế, bạn cũng đang vi phạm DRY. Ngay cả khi bạn không gọi đó là vi phạm DRY (vì mỗi trường hợp phục vụ một mục đích khác nhau), thì vẫn không cần chiếm thêm bộ nhớ, trên cùng là mở cửa cho các lỗi khi hai giá trị quốc gia khác nhau (mà chúng không bao giờ hợp lý được).
  • Hoặc, thay vào đó, điều đó dẫn đến việc bạn cần đồng bộ hóa hai điểm dữ liệu để đảm bảo rằng chúng luôn giống nhau, điều này cho thấy rằng bạn thực sự nên lưu trữ dữ liệu này trong một điểm duy nhất, do đó đánh bại mục đích.
• Nếu bạn không, thì đó không phải là một ZipCodelớp mà là một Addresslớp, một lần nữa sẽ chứa một string ZipCodeđiều đó có nghĩa là chúng ta đã đến vòng tròn đầy đủ.

Ví dụ: tôi có thể nói chuyện với một nhà phân tích kinh doanh về Mã bưu điện thay vì một chuỗi chứa mã bưu điện.

Lợi ích là bạn có thể nói về họ khi mô tả mô hình miền.

Tôi không hiểu khẳng định cơ bản của bạn rằng khi một phần thông tin có một loại biến nhất định, thì bằng cách nào đó bạn bắt buộc phải đề cập đến loại đó bất cứ khi nào bạn nói chuyện với một nhà phân tích kinh doanh.

Tại sao? Tại sao bạn không thể chỉ đơn giản nói về "mã zip" và bỏ hoàn toàn loại cụ thể? Bạn đang có loại thảo luận nào với nhà phân tích doanh nghiệp (không phải kỹ thuật!) Trong đó loại tài sản là tinh túy cho cuộc trò chuyện?

Tôi đến từ đâu, mã bưu điện luôn là số. Vì vậy, chúng tôi có một sự lựa chọn, chúng tôi có thể lưu trữ nó như một inthoặc như một string. Chúng tôi có xu hướng sử dụng một chuỗi vì không có kỳ vọng về các phép toán trên dữ liệu, nhưng không bao giờ có một nhà phân tích kinh doanh nói với tôi rằng nó cần phải là một chuỗi. Quyết định đó thuộc về nhà phát triển (hoặc được cho là nhà phân tích kỹ thuật, mặc dù theo kinh nghiệm của tôi, họ không trực tiếp đối phó với sự cặn bã của nitty).

Một nhà phân tích kinh doanh không quan tâm đến loại dữ liệu, miễn là ứng dụng làm những gì nó dự kiến ​​sẽ làm.

Xác nhận là một con thú khó khăn để giải quyết, bởi vì nó dựa vào những gì con người mong đợi.

Đối với một người, tôi không đồng ý với lập luận xác thực là một cách để cho thấy tại sao nên tránh sự ám ảnh nguyên thủy, bởi vì tôi không đồng ý rằng dữ liệu (như một sự thật phổ quát) luôn luôn cần được xác thực.

Ví dụ, nếu đây là một tra cứu phức tạp hơn thì sao? Thay vì kiểm tra định dạng đơn giản, điều gì xảy ra nếu xác thực của bạn đòi hỏi phải liên hệ với API bên ngoài và chờ phản hồi? Bạn có thực sự muốn buộc ứng dụng của mình gọi API bên ngoài này cho mọi ZipCodeđối tượng bạn khởi tạo không?
Có lẽ đó là một yêu cầu kinh doanh nghiêm ngặt, và sau đó tất nhiên là hợp lý. Nhưng đây không phải là một sự thật phổ quát. Sẽ có rất nhiều trường hợp sử dụng trong đó đây là một gánh nặng nhiều hơn là một giải pháp.

Ví dụ thứ hai, khi nhập địa chỉ của bạn dưới dạng, việc nhập mã bưu điện trước quốc gia của bạn là điều phổ biến. Mặc dù thật tuyệt khi có phản hồi xác thực ngay lập tức trong giao diện người dùng, nhưng thực sự nó sẽ gây trở ngại cho tôi (với tư cách là người dùng) nếu ứng dụng cảnh báo tôi về định dạng mã zip "sai", vì nguồn gốc thực sự của vấn đề là (ví dụ) Quốc gia của tôi không phải là quốc gia được chọn theo mặc định và do đó, xác thực đã xảy ra cho quốc gia sai.
Đó là thông báo lỗi sai, làm mất tập trung người dùng và gây nhầm lẫn không cần thiết.

Giống như cách xác nhận vĩnh viễn không phải là một sự thật phổ quát, cũng không phải là ví dụ của tôi. Đó là bối cảnh . Một số miền ứng dụng yêu cầu xác thực dữ liệu trên hết. Các tên miền khác không đặt xác thực cao trong danh sách ưu tiên vì rắc rối mà nó mang lại mâu thuẫn với các ưu tiên thực tế của chúng (ví dụ: trải nghiệm người dùng hoặc khả năng lưu trữ dữ liệu ban đầu bị lỗi để có thể sửa chữa thay vì không bao giờ cho phép được lưu trữ)

Ngày sinh: Kiểm tra xem lớn hơn ngày và ít hơn ngày hôm nay.
Mức lương: Kiểm tra xem lớn hơn hoặc bằng không.

Vấn đề với các xác nhận này là chúng không đầy đủ, dư thừa hoặc chỉ ra một vấn đề lớn hơn nhiều .

Kiểm tra rằng một ngày lớn hơn tâm trí là dư thừa. Tâm trí theo nghĩa đen có nghĩa là nó là ngày nhỏ nhất có thể. Bên cạnh đó, bạn vẽ đường liên quan ở đâu? Điểm nào trong việc ngăn chặn DateTime.MinDatenhưng cho phép DateTime.MinDate.AddSeconds(1)? Bạn đang chọn một giá trị cụ thể không đặc biệt sai so với nhiều giá trị khác.

Sinh nhật của tôi là ngày 2 tháng 1 năm 1978 (không phải vậy, nhưng giả sử là vậy). Nhưng hãy nói rằng dữ liệu trong ứng dụng của bạn là sai và thay vào đó nó nói ngày sinh nhật của tôi là:

• Ngày 1 tháng 1 năm 1978
• Ngày 1 tháng 1 năm 1722
• Ngày 1 tháng 1 năm 2355

Tất cả những ngày này là sai. Không ai trong số họ là "đúng" hơn người khác. Nhưng quy tắc xác nhận của bạn sẽ chỉ bắt được một trong ba ví dụ này.

Bạn cũng đã hoàn toàn bỏ qua bối cảnh về cách bạn đang sử dụng dữ liệu này. Nếu điều này được sử dụng trong ví dụ bot nhắc nhở sinh nhật, tôi sẽ nói việc xác nhận là vô nghĩa vì không có hậu quả xấu đặc biệt nào trong việc điền sai ngày.
Mặt khác, nếu đây là dữ liệu của chính phủ và bạn cần ngày sinh để xác thực danh tính của ai đó (và không làm như vậy dẫn đến hậu quả xấu, ví dụ như từ chối an ninh xã hội của ai đó), thì tính chính xác của dữ liệu là tối quan trọng và bạn cần phải hoàn toàn xác thực dữ liệu. Xác nhận đề xuất mà bạn có bây giờ là không đầy đủ.

Đối với một mức lương, có một số ý nghĩa phổ biến ở chỗ nó không thể âm. Nhưng nếu bạn thực sự mong đợi rằng dữ liệu vô nghĩa đang được nhập vào, tôi sẽ đề nghị bạn điều tra nguồn gốc của dữ liệu vô nghĩa này. Bởi vì nếu họ không thể tin tưởng để nhập dữ liệu nhạy cảm, bạn cũng không thể tin tưởng họ nhập dữ liệu chính xác .

Nếu thay vào đó, tiền lương được tính theo ứng dụng của bạn và bằng cách nào đó có thể kết thúc bằng số âm (và chính xác)), thì cách tiếp cận tốt hơn là làm gì Math.Max(myValue, 0)để biến số âm thành 0, thay vì không xác thực. Bởi vì nếu logic của bạn quyết định rằng kết quả là một số âm, việc không xác thực có nghĩa là nó sẽ phải làm lại phép tính và không có lý do gì để nghĩ rằng nó sẽ đưa ra một số khác vào lần thứ hai.
Và nếu nó xuất hiện với một số khác, điều đó một lần nữa khiến bạn nghi ngờ rằng phép tính không nhất quán và do đó không thể tin cậy được.

Điều này không có nghĩa là xác nhận không hữu ích. Nhưng xác nhận vô nghĩa là xấu, cả hai vì nó cần nỗ lực trong khi không thực sự giải quyết vấn đề và mang lại cho mọi người cảm giác an toàn sai lầm.