Home / Blog / ood là gì

OOD LÀ GÌ

admin - 07/01/2023 34

Chuyện về Object Oriented kiến thiết Principles

Thời còn mài lỗ hậu môn ở giảng đường, số đông sinh viên ngành CNTT đa số được dạy đầy đủ khái niệm cơ phiên bản về Object Oriented Programming (OOP) như 4 đặc điểm của nó tương đối là rõ ràng. Trong tương lai khi đi phỏng vấn xin vấn đề thì hình trạng gì cũng được hỏi về nó.

Bạn đang xem: Ood là gì

Thế tuy thế cái bọn họ đề cập đến từ bây giờ là Object Oriented kiến thiết chứ chưa hẳn OOP (yaoming)

Ngày xửa ngày xưa, bạn ta nói rằng

Proper Object Oriented design makes a developer"s life easy, whereas bad design makes it a disaster

Vâng good kiến thiết sẽ làm cho cuộc sống đời thường của lập trình viên dễ dãi hơn. Vậy làm cho sao để sở hữu một good design ? chúng ta có những nguyên tắc (principles).

Khái niệm

Là một tập hợp những hướng dẫn bảo đảm các khái niệm của OOP, giúp bọn họ tránh các xây dựng xấu.

Lợi ích

Việc viết code theo các nguyên tắc giúp mang đến code trở bắt buộc trong sáng, dễ đọc, dễ kiểm tra và đặc trưng nhất là dễ maintain hơn hết sức nhiều. Và họ đều biết, trong vòng đời của một trong những phần mềm, thời hạn code chỉ chiếm khoảng chừng 20-40% sót lại là thời gian dành riêng cho maintain: thêm/bớt chức năng, fix bug...

Design Principles có tương quan gì mang đến Design Patterns ko ???

Câu trả lời là có, nhưng bao gồm chút không giống biệt.

Principles: là những hướng dẫn, mang ý nghĩa trừu tượng nhiều hơn.Patterns: là phần đa ví dụ rõ ràng hóa, cung cấp các chiến thuật tái áp dụng đến các vấn đề thực tế. Patterns xuất sắc nên tuân thủ tốt Principles.

Tất cả các các thư viện/framework chúng ta dùng đều xây đắp trên một vài ba Pattern, rõ ràng bọn họ đang thao tác làm việc trên những nguyên tắc cơ bản, cơ mà code họ viết ra thì chưa cứng cáp tuân theo những nguyên tắc đó (yaoming)

Các nhóm Design Principles

Trong cuốn "Agile Software Development: Principles, Patterns, & Practices", Uncle Bob đã tổng thích hợp lại 11 nguyên tắc và phân chia chúng làm cho 3 nhóm:

Class thiết kế principles – bao hàm 5 nguyên lý(SRP) Single Responsibility Principle(OCP) open Closed Principle(LSP) Liskov Substitution Principle(DIP) Dependency Inversion Principle(ISP) Interface Segregation PrinciplePackage Cohesion Principles - bao gổm 3 nguyên lý(REP) Reuse-Release Equivalence Principle(CRP) Common Reuse Principle(CCP) Common Closure PrinciplePackage Coupling principle - bao gồm 3 nguyên lý(ADP) Acyclic Dependencies Principle(SDP) Stable Dependencies Principle(SAP) Stable Abstractions Principle

Ngoài ra còn tồn tại các nguyên lý khác như

(DRY) Don"t Repeat Yourself(KISS) Keep It Simple Stupid...

Trong bài viết này bọn họ sẽ đề cập mang đến nhóm Class thiết kế principles - SOLID.

Chuyện về SOLID

"SOLID" tức thị "cứng" (là thể rắn nhưng mình đang có nhu cầu muốn gọi là cứng (yaoming)), vận dụng nhiều thì sẽ code "cứng", như cục gạch trong hình (yaoming)

Đùa thôi, "SOLID" là tên gọi tắt được ra mắt bởi Micheal Feathers mang lại "first five principles" của Uncle Bob. đó là nhóm Class kiến thiết principles:

Single Responsibility PrincipleOpen Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle

Trong bài viết này mình sẽ giới thiệu tổng quát mắng về 5 nguyên tắc này.

Single responsibility principle - nguyên lý đơn nhiệm

Nội dung

Một class chỉ nên có một trách nhiệm duy nhất. Nói bí quyết khác, một class nên bao gồm một và duy độc nhất vô nhị một tại sao để cố gắng đổi.

Tưởng tượng class của bọn họ giống như nhỏ dao đa năng kia, có không ít chức năng, nhìn dường như tiện đấy.

Thế nếu bọn họ cần thay bắt đầu một chức năng trong kia thì sao ? tất yếu rồi, gỡ hết nó ra rồi tính. Với đây thực sự là một ý tưởng tồi.

Theo nguyên lý, bọn họ nên tách nó thành những class nhỏ tuổi hơn. Tuy nhiều class hơn nhưng lại class ngắn thêm dễ đọc hơn, dễ dàng test từng tính năng hơn.

Open/closed principle - nguyên tắc mở rộng/hạn chế

Nội dung

Một thực thể phần mềm (class, modules, function...) buộc phải mở (dễ) cùng với sự mở rộng và đóng (hạn chế) với việc thay đổi.

Xem thêm: Spoiler Anime Conan Tập 1000, Thám Tử Lừng Danh Conan Tập 1000

Theo nguyên tắc này, mỗi lúc ta ao ước thêm chức năng,.. Mang đến chương trình, chúng ta nên viết class mới không ngừng mở rộng class cũ ( bằng phương pháp kế quá hoặc thiết lập class cũ) không nên sửa đổi class cũ.

Liskov Substitution Principle - nguyên tắc thay thay Liskov

Nội dung

Nếu S là 1 subtype của T, thì các đối tượng người dùng kiểu T rất có thể được thay thế sửa chữa bằng các đối tượng người sử dụng kiểu S mà không cụ đổi bất kỳ tính đúng đắn nào của lịch trình đó.

Nói một cách dễ dàng nắm bắt hơn class con hoàn toàn có thể thay chũm class thân phụ mà không làm biến hóa tính đúng đắn của chương trình.

Hãy tưởng tượng họ có một class phụ thân là Vịt. Những class VịtNhà, VịtTrời thừa kế class Vịt thì trả toàn có thể có thể thay thế sửa chữa class cha. Nhưng lại nếu class VịtĐồChơi bắt buộc pin mới chạy được, thừa kế class Vịt thì liệu gồm còn đảm bảo an toàn tính đúng đắn.

Interface Segregation Principle - nguyên tắc phân bóc tách giao tiếp

Nội dung

Client ko nên dựa vào vào giao tiếp (interface) mà chúng không sử dụng.

Hãy tưởng tượng bọn họ có 1 interface lớn, khoảng chừng 100 methods. Việc implements sẽ tương đối cực khổ, dường như còn rất có thể dư thừa vì 1 class không đề xuất dùng không còn 100 method.

Thay do dùng 1 interface lớn, ta nên tách bóc thành những interface nhỏ, với nhiều mục đích vậy thể. Khi đó việc implement và thống trị sẽ dễ dàng hơn.

Dependency inversion principle - nguyên lý nghịch đảo phụ thuộc

Nội dung

Các module cấp cao không nên dựa vào vào những modules cung cấp thấp. Cả 2 nên nhờ vào vào các chiếc trừu tượng (abstractions).Những mẫu trừu tượng không nên dựa vào vào bỏ ra tiết, nhưng mà ngược lại.

Có thể gọi nguyên lí này như sau: phần lớn thành phần trong 1 chương trình chỉ nên nhờ vào vào những chiếc trừu tượng (abstractions). Gần như thành phần trừu tượng không nên nhờ vào vào các thành phần có tính ví dụ mà phải ngược lại.

Những mẫu trừu tượng (abstraction) là những cái ít chuyển đổi và phát triển thành động, nó tập hợp đông đảo đặc tính phổ biến nhất của không ít cái nạm thể. Phần đông cái rõ ràng dù không giống nhau thế như thế nào đi nữa đông đảo tuân theo những quy tắc chung mà dòng trừu tượng vẫn định ra. Việc dựa vào vào mẫu trừu tượng để giúp chương trình biến hóa năng động và mê thích ứng tốt với các sự chuyển đổi diễn ra liên tục.

Chúng ta đầy đủ biết 2 loại đèn: đèn tròn và đèn huỳnh quang. Chúng cùng gồm đuôi tròn, cho nên ta hoàn toàn có thể thay chũm đèn tròn bởi đèn huỳnh quanh cho nhau một cách dễ dàng.

Ở đây, interface chính là đuôi tròn, implementation là đèn điện tròn và bóng đèn huỳnh quang. Ta hoàn toàn có thể swap dễ ợt giữa 2 loại bóng bởi vì ổ năng lượng điện chỉ thân thiện tới interface (đuôi tròn), không niềm nở tới implementation.

Lưu ý: tất cả một thứ bọn họ hay sử dụng rất dễ nhầm lẫn với nguyên lý này đó là Dependency Injection. Nên chăm chú Dependency Injection là 1 design pattern hiện thực Dependency inversion principle.

Xem thêm: Devil May Cry 4 For Windows, Devil May Cry 4 Special Edition On Steam