Object oriented design là gì

Chuyện về Object Oriented Design Principles

Thời còn mài hậu môn làm việc giảng đường, phần lớn sinh viên ngành CNTT hồ hết được dạy những khái niệm cơ bạn dạng về Object Oriented Programming [OOP] nhỏng 4 đặc thù của chính nó tương đối là ví dụ. Sau này khi đi chất vấn xin vấn đề thì hình dạng gì cũng được hỏi về nó.

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

Thế nhưng chiếc chúng ta đề cùa tới hôm nay là Object Oriented Design chứ đọng chưa hẳn OOPhường [yaoming]

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

Proper Object Oriented Design makes a developer"s life easy, whereas bad kiến thiết makes it a disaster

Vâng good design đang 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 sao để sở hữu một good design ? Chúng ta bao hàm nguyên tắc [principles].

Khái niệm

Là một tập vừa lòng các gợi ý bảo đảm những quan niệm của OOP., góp họ tách những xây đắp xấu.

Lợi ích

Việc viết code theo những nguyên tắc giúp cho code trsinh hoạt bắt buộc trong trắng, đọc dễ dàng, dễ dàng kiểm tra cùng quan trọng đặc biệt độc nhất là dễ maintain hơn không ít. Và bọn họ những biết, trong vòng đời của 1 phần mềm, thời gian code chỉ chiếm khoảng 20-40% sót lại là thời gian dành cho maintain: thêm/sút tính năng, fix bug...

Design Principles bao gồm tương quan gì mang đến Design Patterns ko ???

Câu vấn đáp là tất cả, cơ mà gồm chút biệt lập.

Principles: là những khuyên bảo, mang tính chất trừu tượng nhiều hơn thế.Patterns: là rất nhiều ví dụ ví dụ hóa, cung cấp các chiến thuật tái sử dụng cho những sự việc thực tiễn. Patterns tốt bắt buộc vâng lệnh xuất sắc Principles.

Tất cả những các thỏng viện/framework họ dùng phần lớn kiến tạo bên trên một vài Pattern, ví dụ họ sẽ thao tác làm việc trên những nguyên lý cơ bạn dạng, mà lại code chúng ta viết ra thì không có thể tuân theo phần nhiều nguyên tắc đó [yaoming]

Các team Design Principles

Trong cuốn nắn "Agile Software Development: Principles, Patterns, và Practices", Uncle Bob đã tổng vừa lòng lại 11 nguyên lý cùng chia bọn chúng có tác dụng 3 nhóm:

Class Design principles bao hàm 5 ngulặng lý[SRP] Single Responsibility Principle[OCP] xuất hiện Closed Principle[LSP] Liskov Substitution Principle[DIP] Dependency Inversion Principle[ISP] Interface Segregation PrinciplePackage Cohesion Principles - bao gổm 3 ngulặng lý[REP] Reuse-Release Equivalence Principle[CRP] Common Reuse Principle[CCP] Comtháng Closure PrinciplePackage Coupling principle - bao hàm 3 nguyên lý[ADP] Acyclic Dependencies Principle[SDP] Stable Dependencies Principle[SAP] Stable Abstractions Principle

Hình như còn có những nguyên tắc không giống như

[DRY] Don"t Repeat Yourself[KISS] Keep It Simple Stupid...

Trong nội dung bài viết này chúng ta đã đề cập tới team Class Design principles - SOLID.

Cthị xã về SOLID

"SOLID" tức là "cứng" [là thể rắn tuy thế mình thích Gọi là cứng [yaoming]], áp dụng các thì vẫn code "cứng", như cục gạch men trong hình [yaoming]

Đùa thôi, "SOLID" là tên thường gọi tắt được giới thiệu vì chưng Micheal Feathers mang đến "first five sầu principles" của Uncle Bob. Chính là đội Class Design principles:

Single Responsibility PrincipleOpen Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle

Trong nội dung bài viết này mình đã trình làng tổng thể về 5 nguyên tắc này.

Single responsibility principle - Nguyên lý đối chọi nhiệm

Nội dung

Một class nên làm bao gồm một trách nhiệm duy nhất. Nói bí quyết khác, một class đề xuất tất cả một cùng độc nhất vô nhị một nguyên nhân để đổi khác.

Tưởng tượng class của bọn họ giống hệt như bé dao đa zi năng kia, có nhiều tính năng, quan sát có vẻ luôn tiện đấy.

Thế ví như họ buộc phải cầm cố mới một chức năng trong các số ấy thì sao ? Tất nhiên rồi, bóc hết nó ra rồi tính. Và đây đích thực là một trong những phát minh tồi.

Theo nguyên lý, chúng ta đề xuất tách nó thành nhiều class nhỏ dại hơn. Tuy các class rộng tuy thế class ngắn hơn đọc dễ dàng hơn, thuận tiện thử nghiệm từng tác dụng hơn.

Open/closed principle - Ngulặng lý msống rộng/hạn chế

Nội dung

Một thực thể ứng dụng [class, modules, function...] đề nghị msống [dễ] với việc mở rộng cùng đóng góp [hạn chế] với việc biến hóa.

Xem thêm: Ttc Là Gì ? Ttc Nghĩa Là Gì

Theo nguyên lý này, mọi khi ta ao ước thêm chức năng,.. mang lại chương trình, họ bắt buộc viết class mới không ngừng mở rộng class cũ [ bằng phương pháp thừa kế hoặc tải class cũ] tránh việc sửa đổi class cũ.

Liskov Substitution Principle - Ngulặng lý thay thế sửa chữa Liskov

Nội dung

Nếu S là một trong subtype của T, thì các đối tượng người sử dụng hình trạng T có thể được thay thế sửa chữa bởi những đối tượng người tiêu dùng loại S mà không biến đổi bất kỳ tính đúng chuẩn nào của lịch trình đó.

Nói một cách dễ dàng nắm bắt rộng class nhỏ hoàn toàn có thể sửa chữa class thân phụ cơ mà ko có tác dụng biến hóa tính đúng mực của lịch trình.

Hãy tưởng tượng bọn họ gồm một class cha là Vịt. Các class VịtNhà, VịtTrời thừa kế class Vịt thì trọn vẹn có thể rất có thể thay thế class phụ vương. Nhưng nếu như class VịtĐồChơi yêu cầu pin bắt đầu chạy được, kế thừa class Vịt thì liệu tất cả còn đảm bảo tính đúng chuẩn.

Interface Segregation Principle - Nguyên ổn lý phân bóc tách giao tiếp

Nội dung

Client tránh việc phụ thuộc vào giao tiếp [interface] mà chúng ko sử dụng.

Hãy tưởng tượng họ có một interface lớn, khoảng tầm 100 methods. Việc implements sẽ tương đối đau đớn, hơn nữa còn rất có thể dư quá vì 1 class ko phải dùng hết 100 method.

Txuất xắc bởi dùng 1 interface Khủng, ta cần bóc thành các interface nhỏ, với tương đối nhiều mục đích cụ thể. khi đó bài toán implement cùng cai quản đang dễ rộng.

Dependency inversion principle - Nguim lý nghịch hòn đảo phú thuộc

Nội dung

Các module V.I.P không nên nhờ vào vào những modules cấp thấp. Cả 2 đề xuất phụ thuộc vào vào những cái trừu tượng [abstractions].Những cái trừu tượng tránh việc phụ thuộc vào vào cụ thể, mà hoàn toàn trái ngược.

cũng có thể hiểu nguyên ổn lí nàhệt như sau: đều yếu tố trong một công tác chỉ nên dựa vào vào các cái trừu tượng [abstractions]. Những thành phần trừu tượng tránh việc phụ thuộc vào các yếu tắc mang tính chất rõ ràng nhưng cần ngược lại.

Những cái trừu tượng [abstraction] là những chiếc ít biến đổi với biến động, nó tập hợp những đặc tính chung tuyệt nhất của rất nhiều mẫu ví dụ. Những cái rõ ràng cho dù không giống nhau cố như thế nào đi nữa hồ hết tuân theo những luật lệ thông thường cơ mà loại trừu tượng vẫn định ra. Việc nhờ vào vào loại trừu tượng sẽ giúp đỡ chương trình linh động với thích ứng giỏi với những sự biến hóa ra mắt liên tiếp.

Chúng ta đầy đủ biết 2 nhiều loại đèn: đèn tròn cùng đèn huỳnh quang. Chúng cùng bao gồm đuôi tròn, vì thế ta hoàn toàn có thể thay thế đèn tròn bằng đèn huỳnh quanh lẫn nhau 1 cách thuận lợi.

Ở đây, interface chính là đuôi tròn, implementation là bóng đèn tròn với đèn điện huỳnh quang. Ta có thể swap dễ dãi thân 2 loại nhẵn bởi vì ổ năng lượng điện chỉ quan tâm cho tới interface [đuôi tròn], không quyên tâm cho tới implementation.

Lưu ý: Có một thiết bị bọn họ hay được sử dụng rất đơn giản lầm lẫn với nguyên lý này chính là Dependency Injection. Nên chú ý Dependency Injection là 1 trong những kiến thiết pattern thực tại Dependency inversion principle.

Kết

Bài viết tương đối nhiều năm cái, toàn chữ chả tất cả code hy vọng chúng ta không ngủ [yaoming]

Trong các bài viết sau họ đang mày mò kĩ rộng từng nguyên lý cố nhiên code minh họa [cùng ngắn thêm nữa [yaoming] ]

Cảm ơn hồ hết fan đang theo dõi và quan sát.

Tsay đắm Khảo