Trong lập trình cơ sở dữ liệu, có một kỹ thuật gọi là "chuẩn hóa" mà bạn thực hiện đối với dữ liệu bạn muốn lưu trữ.

Có ai đã thử áp dụng khái niệm này vào thiết kế đối tượng chưa? Bạn đã làm thế nào Làm thế nào nó làm việc ra?

Chỉnh sửa: Để mở rộng / làm rõ, chuẩn hóa cơ sở dữ liệu không chỉ là một bộ nguyên tắc để giảm sự dư thừa. Thực tế có những bước và giai đoạn bạn trải qua và ít nhất là các biện pháp khách quan vừa phải cho bạn biết bạn đang ở giai đoạn nào. Thiết kế đối tượng có nguyên tắc riêng của nó, và có khái niệm về mùi, nhưng có cách nào để làm điều gì đó tương tự sẽ cho bạn biết rằng bạn đang ở XX-form0,1,2 ... vv ... và các phương pháp để chuyển sang cấp độ "bình thường hóa" tiếp theo?

Trong khi một số căng thẳng cơ bản thúc đẩy quá trình chuẩn hóa cơ sở dữ liệu không có trong hệ thống OO, một số trong số đó là. Những điều này đã làm phát sinh các mẫu và nguyên tắc thiết kế OO theo một số cách tương tự như chuẩn hóa, ít nhất là trong các hệ thống OO tương tự như cơ sở dữ liệu quan hệ. Ví dụ:

• Nguyên tắc trách nhiệm duy nhất
• Tách mối quan tâm
• Một lần và chỉ một lần , còn gọi là DRY

Nói cách khác, có ai đã thử áp dụng các kỹ thuật chuẩn hóa cơ sở dữ liệu vào OOP chưa? Không, bởi vì OOP đã có giải pháp cho các vấn đề chung mà bình thường hóa giải quyết cho cơ sở dữ liệu quan hệ.

Vâng, vâng tôi có

Tôi đã giữ im lặng về chủ đề này trong một thời gian dài; đã đến lúc nói ra.

• Có ai đã thử áp dụng khái niệm này vào thiết kế đối tượng chưa?

Vâng. Tôi đã làm việc về việc chính thức hóa chuẩn hóa đối tượng (và do đó là lý thuyết hướng đối tượng cơ bản) trong hơn 20 năm.

• Bạn đã làm thế nào

Bằng cách nhận ra rằng dữ liệu và mã có thể thay thế cho nhau, ít nhất là trên lý thuyết. Điều này có nghĩa là các nguyên tắc chuẩn hóa và các hoạt động quan hệ có thể áp dụng cho mã cũng như dữ liệu.

• Làm thế nào nó làm việc ra?

Nó hoạt động khá tốt cho đến nay - tôi tin rằng những hiểu biết thu được là "vũ khí bí mật" trong khả năng thiết kế, phân tích và tái cấu trúc của tôi.

Tôi đã không nói bất cứ điều gì về nó một cách công khai trước đó bởi vì tôi nghĩ rằng cuối cùng tôi sẽ có thời gian để hoàn thành nghiên cứu - và tự sản xuất các công cụ ngụ ý - chính tôi.

Nhưng tôi đã đi đến kết luận rằng với mọi thứ khác đang diễn ra trong cuộc sống của tôi quan trọng hơn, vui vẻ hơn và / hoặc có nhiều lợi nhuận hơn, tôi sẽ không có thời gian để tự mình hoàn thành nghiên cứu. Không bao giờ. Cũng có khả năng đáng kể là tôi đơn giản là không có nền tảng lý thuyết CS cần thiết để hoàn thành công việc một mình.

Tôi đã hỏi trường đại học địa phương về việc tài trợ cho một hoặc hai ứng cử viên tiến sĩ nếu họ muốn tìm hiểu nguyên nhân, nhưng than ôi trường đại học địa phương của chúng tôi không dạy một nền tảng đầy đủ về ngữ nghĩa ngôn ngữ lập trình.

Đã có một số nghiên cứu thú vị trong lĩnh vực này, nhưng tất cả trong số đó - mà tôi biết - đã không đạt được mục đích. Hoặc nó giả định không chính xác bởi vì chuẩn hóa xuất phát từ một nền tảng quan hệ, nó không áp dụng cho các mô hình hướng đối tượng hoặc giả định rằng chuẩn hóa chỉ áp dụng cho dữ liệu được xác định bởi các đối tượng. Có một số dự án suýt bỏ lỡ rất thú vị tuy nhiên ...

Các công cụ thực sự thú vị xảy ra khi bạn áp dụng chuẩn hóa cho mã - mà tôi sẽ tranh luận là nền tảng của tất cả tái cấu trúc .

Vì vậy, bây giờ tôi nghĩ rằng điều tốt nhất để làm là nói ra, có lẽ bằng cách yêu cầu phát biểu tại DevDays 2011 ở DC, và tìm hiểu xem có một cộng đồng nào bị kích thích bởi những thứ này như tôi không.

Đây là một lén lút: Bình thường hóa là quá trình tạo ra một cái gì đó tối thiểu và không dư thừa. Do đó, nguyên tắc Đừng lặp lại chính mình (DRY) của lập trình hướng đối tượng là một biểu hiện rõ ràng của các mục tiêu của chuẩn hóa. Tôi tin rằng tôi có thể chỉ ra rằng tất cả các nguyên tắc thiết kế / lập trình / tái cấu trúc hướng đối tượng nổi tiếng là hệ quả logic của việc chuẩn hóa đối tượng. Tôi nghĩ rằng tôi cũng có thể chỉ ra rằng có nhiều điều thú vị hơn có thể được thực hiện với các hệ thống trong Mẫu đối tượng bình thường (ONF) thay vì chỉ tái cấu trúc.

Điều này bắt đầu như một nhận xét về câu trả lời xuất sắc của Rein Henrichs , nhưng đã quá lâu ...

Chuẩn hóa áp dụng cho dữ liệu quan hệ. Nó được sử dụng để tránh trùng lặp, giúp đảm bảo tính toàn vẹn dữ liệu dễ dàng hơn vì mỗi mốc được lưu trữ ở một nơi duy nhất. Bạn bình thường hóa cơ sở dữ liệu bằng cách tìm vi phạm biểu mẫu đã chuẩn hóa và sửa chúng.

Lập trình hướng đối tượng áp dụng cho các hoạt động trên dữ liệu. Nó có nghĩa là để nhóm các cách thao tác dữ liệu với nhau. Bạn có thể áp dụng các kỹ thuật tương tự cho các lớp để loại bỏ các phương thức trùng lặp, có lẽ bằng cách xem dữ liệu mà thao tác thao tác hoặc phụ thuộc vào. Ví dụ: 1NF trong phối cảnh OO sẽ không có bất kỳ hoạt động trùng lặp nào trong một lớp. 3NF có thể tương ứng với cấu trúc kế thừa tốt trong đó mã thường được sử dụng trong một siêu lớp. Tôi chắc rằng bạn cũng có thể tìm thấy một nơi phù hợp để tiêm phụ thuộc vào đó. Bạn đạt đến một thiết kế tốt hơn (mặc dù không có gì giống như các hình thức bình thường đã được phát hiện) bằng cách phát hiện vi phạm các nguyên tắc thiết kế tốt và tái cấu trúc.

Thực sự không có bất kỳ phương pháp thuật toán nào để đạt được một thiết kế tốt ở cả hai thế giới. Như Rein Hendrichs chỉ ra, có nhiều nguyên tắc có thể xác định các vấn đề tiềm ẩn (hay còn gọi là mùi mã). Các mẫu thiết kế và thực tiễn tốt nhất là một số cách mọi người đã cố gắng giải quyết chúng. Phát triển dựa trên thử nghiệm cố gắng tìm ra chúng sớm bằng cách thực thi mã vì nó sẽ ở bên ngoài. Cũng giống như trong phát triển cơ sở dữ liệu, giải pháp tốt nhất được tìm thấy với kinh nghiệm và phân tích.

Một cách tiếp cận rất tốt để thiết kế các đối tượng mô hình kinh doanh tương tự như chuẩn hóa là UML Modelling in Color .

Đó là một chiến lược thiết kế được tìm thấy bởi Peter Coad giúp trừu tượng hóa các đối tượng mô hình kinh doanh.

Thật không may, cuốn sách - Mô hình hóa Java có màu với UML: Các thành phần và quy trình doanh nghiệp - đã được bán hết và bạn chỉ có thể mua những cuốn đã sử dụng.

Có một vài bài báo qua internet về kỹ thuật này.

Nếu bạn quen thuộc với thiết kế quan hệ, bạn sẽ thấy Mô hình UML có màu hữu ích để hướng dẫn bạn:

• 'Mô hình hóa màu sắc' của Peter Coad - Ghi chú của Stephen R. Palmer

Bạn đã điều tra để sử dụng các chú thích java ORM trong mã của bạn trong khi tạo sơ đồ lớp của bạn chưa? Hibernate sẽ tạo cơ sở dữ liệu khi giai đoạn mô hình kết thúc. Sơ đồ trong ví dụ này chỉ có người xem mã.

Tham chiếu đối tượng hoặc con trỏ tương tự như khóa ngoại. Điều đó sâu sắc như tôi sẵn sàng nghĩ về điều này. :)

Thật ra tôi sẽ suy nghĩ sâu hơn. Nếu bạn lập mô hình các đối tượng của mình với 0 sao chép dữ liệu và có thể "truy vấn" các đối tượng của bạn và thực hiện các cập nhật dựa trên thiết lập trên chúng thì sẽ không có ngắt kết nối. Trong thực tế, bạn CÓ THỂ làm điều này bằng cách tạo một thư viện đối tượng tiêu dùng. Microsoft đã thực hiện điều này nhưng đã đi theo hướng biến phần cú pháp LINQ dựa trên tập hợp của C # qua một "thư viện truy vấn".