Tại sao nó không phải là ý tưởng tốt cho các tầng ứng dụng của Hạ thấp.

Trong một ứng dụng web MVC điển hình (được thiết kế tốt), cơ sở dữ liệu không nhận biết được mã mô hình, mã mô hình không nhận biết được mã điều khiển và mã điều khiển không nhận biết được mã xem. (Tôi tưởng tượng bạn thậm chí có thể bắt đầu xuống tận phần cứng, hoặc thậm chí xa hơn, và mô hình có thể giống nhau.)

Đi theo hướng khác, bạn có thể đi xuống chỉ một lớp. Khung nhìn có thể nhận biết được bộ điều khiển nhưng không phải mô hình; bộ điều khiển có thể nhận biết mô hình nhưng không phải cơ sở dữ liệu; mô hình có thể nhận biết cơ sở dữ liệu nhưng không phải hệ điều hành. (Bất cứ điều gì sâu hơn có lẽ không liên quan.)

Tôi có thể trực giác nắm bắt tại sao đây là một ý tưởng tốt nhưng tôi không thể nói rõ nó. Tại sao phong cách layering đơn hướng này là một ý tưởng tốt?

Các lớp, mô-đun, thực sự là kiến ​​trúc, là phương tiện giúp con người dễ hiểu hơn . Phương pháp tối ưu hóa số để giải quyết vấn đề hầu như luôn luôn là một mớ hỗn độn vô tận của mã không mô đun, tự tham chiếu hoặc thậm chí tự sửa đổi - cho dù đó là mã trình biên dịch được tối ưu hóa mạnh mẽ trong các hệ thống nhúng với các ràng buộc bộ nhớ bị tê liệt hoặc chuỗi DNA sau hàng triệu năm của áp lực lựa chọn. Các hệ thống như vậy không có lớp, không có hướng rõ ràng của luồng thông tin, trên thực tế không có cấu trúc nào mà chúng ta có thể nhận thấy cả. Đối với tất cả mọi người trừ tác giả của họ, họ dường như làm việc bằng ma thuật thuần túy.

Trong công nghệ phần mềm, chúng tôi muốn tránh điều đó. Kiến trúc tốt là một quyết định có chủ ý để hy sinh một số hiệu quả vì mục đích làm cho hệ thống dễ hiểu bởi những người bình thường. Hiểu một điều tại một thời điểm dễ hơn hiểu hai điều chỉ có ý nghĩa khi được sử dụng cùng nhau. Đó là lý do tại sao các mô-đun và các lớp là một ý tưởng tốt.

Nhưng chắc chắn các mô-đun phải gọi các chức năng từ nhau và các lớp phải được tạo lên nhau. Vì vậy, trong thực tế, luôn luôn cần thiết để xây dựng các hệ thống sao cho một số phần yêu cầu các phần khác. Thỏa hiệp ưa thích là xây dựng chúng theo cách mà một phần yêu cầu một phần khác, nhưng phần đó không yêu cầu phần đầu tiên trở lại. Và đây chính xác là những gì phân lớp đơn hướng mang lại cho chúng ta: có thể hiểu lược đồ cơ sở dữ liệu mà không cần biết các quy tắc kinh doanh và hiểu các quy tắc kinh doanh mà không cần biết về giao diện người dùng. Sẽ thật tuyệt nếu có sự độc lập theo cả hai hướng - cho phép ai đó lập trình UI mới mà không cần biết gìở tất cả về các quy tắc kinh doanh - nhưng trong thực tế, điều này hầu như không bao giờ có thể. Các quy tắc như "Không phụ thuộc theo chu kỳ" hoặc "Phụ thuộc chỉ phải đạt xuống một cấp" chỉ đơn giản là nắm bắt giới hạn thực tế có thể đạt được của ý tưởng cơ bản rằng một điều tại một thời điểm dễ hiểu hơn hai điều.

Động lực cơ bản là thế này: Bạn muốn có thể tách toàn bộ một lớp ra và thay thế một lớp hoàn toàn khác (viết lại), và NOBODY NÊN (ĐƯỢC TỪNG ĐẾN) THÔNG BÁO SỰ KHÁC BIỆT.

Ví dụ rõ ràng nhất là tách lớp dưới cùng ra và thay thế một lớp khác. Đây là những gì bạn làm khi bạn phát triển (các) lớp trên chống lại sự mô phỏng của phần cứng, và sau đó thay thế trong phần cứng thực.

Ví dụ tiếp theo là khi bạn tách một lớp giữa ra và thay thế một lớp giữa khác. Hãy xem xét một ứng dụng sử dụng giao thức chạy trên RS-232. Một ngày nào đó, bạn phải thay đổi hoàn toàn mã hóa giao thức, bởi vì "một thứ khác đã thay đổi". . , một trong những mặt trăng của Sao Mộc và liên kết đó cần sửa lỗi chuyển tiếp tốt hơn nhiều.)

Cách duy nhất để thực hiện công việc này là nếu mỗi lớp xuất một giao diện đã xác định, đã xác định sang lớp bên trên và mong đợi một giao diện đã xác định, đã xác định cho lớp bên dưới.

Bây giờ, nó không chính xác là trường hợp mà các lớp thấp hơn không biết gì về các lớp trên. Thay vào đó, những gì lớp dưới biết là lớp ngay phía trên nó sẽ hoạt động chính xác theo giao diện đã xác định của nó. Nó không thể biết gì hơn, bởi vì theo định nghĩa, bất cứ điều gì không có trong giao diện được xác định đều có thể thay đổi mà KHÔNG CÓ THÔNG BÁO.

Lớp RS-232 không biết liệu nó có đang chạy ASCII, Reed-Solomon, Unicode (trang mã tiếng Ả Rập, trang mã Nhật Bản, trang mã Rigellian Beta) hay không. Nó chỉ biết rằng nó đang nhận được một chuỗi các byte và nó đang ghi các byte đó vào một cổng. Tuần tới, anh ta có thể nhận được một chuỗi byte hoàn toàn khác với thứ hoàn toàn khác. Anh ấy không quan tâm. Anh ta chỉ di chuyển byte.

Giải thích đầu tiên (và tốt nhất) về thiết kế nhiều lớp là bài viết kinh điển "Cấu trúc của hệ thống đa chương trình" của Dijkstra . Nó được yêu cầu đọc trong kinh doanh này.

Bởi vì các cấp cao hơn có thể sẽ thay đổi.

Khi điều đó xảy ra, cho dù do yêu cầu thay đổi, người dùng mới, công nghệ khác, một ứng dụng mô đun (tức là không theo hướng) nên yêu cầu ít bảo trì hơn và dễ dàng thích nghi hơn để phù hợp với nhu cầu mới.

Tôi nghĩ rằng lý do chính là nó làm cho mọi thứ gắn kết chặt chẽ hơn. Khớp nối càng chặt thì càng có nhiều vấn đề xảy ra sau này. Xem bài viết này thêm thông tin: Khớp nối

Đây là một đoạn trích:

Nhược điểm

Các hệ thống kết hợp chặt chẽ có xu hướng thể hiện các đặc điểm phát triển sau, thường được coi là nhược điểm: Một thay đổi trong một mô-đun thường tạo ra hiệu ứng gợn của các thay đổi trong các mô-đun khác. Việc lắp ráp các mô-đun có thể đòi hỏi nhiều nỗ lực và / hoặc thời gian hơn do sự phụ thuộc giữa các mô-đun tăng lên. Một mô-đun cụ thể có thể khó sử dụng lại và / hoặc kiểm tra hơn vì các mô-đun phụ thuộc phải được đưa vào.

Với lý do được nói về lý do để có một hệ thống kết hợp chặt chẽ hơn là vì lý do hiệu suất. Bài báo mà tôi đề cập cũng có một số thông tin về điều này.

IMO, nó rất đơn giản. Bạn không thể sử dụng lại thứ gì đó liên tục tham chiếu đến bối cảnh nó được sử dụng.

Các lớp không nên có phụ thuộc hai chiều

Ưu điểm của kiến ​​trúc phân lớp là các lớp nên có thể sử dụng độc lập:

• bạn sẽ có thể xây dựng một lớp trình bày khác ngoài lớp đầu tiên mà không thay đổi lớp dưới (ví dụ: xây dựng lớp API ngoài giao diện web hiện có)
• bạn sẽ có thể cấu trúc lại hoặc cuối cùng thay thế lớp dưới mà không thay đổi lớp trên cùng

Những điều kiện này về cơ bản là đối xứng . Họ giải thích tại sao nói chung là tốt hơn khi chỉ có một hướng phụ thuộc, nhưng không phải là hướng đó .

Hướng phụ thuộc phải theo hướng lệnh

Lý do tại sao chúng tôi thích cấu trúc phụ thuộc từ trên xuống là vì các đối tượng trên cùng tạo và sử dụng các đối tượng dưới cùng . Một phụ thuộc về cơ bản là một mối quan hệ có nghĩa là "A phụ thuộc vào B nếu A không thể làm việc mà không có B". Vì vậy, nếu các đối tượng trong A sử dụng các đối tượng trong B, đó là cách các phụ thuộc sẽ đi.

Đây là một cách hơi tùy tiện. Trong các mẫu khác, chẳng hạn như MVVM, điều khiển dễ dàng chảy từ các lớp dưới cùng. Ví dụ: bạn có thể thiết lập nhãn có chú thích hiển thị được liên kết với một biến và thay đổi với nhãn đó. Tuy nhiên, thông thường vẫn nên có các phụ thuộc từ trên xuống, bởi vì các đối tượng chính luôn là đối tượng mà người dùng tương tác và các đối tượng đó làm phần lớn công việc.

Trong khi từ trên xuống chúng tôi sử dụng lời gọi phương thức, từ dưới lên (thông thường) chúng tôi sử dụng các sự kiện. Các sự kiện cho phép các phụ thuộc đi từ trên xuống ngay cả khi điều khiển chảy theo cách khác. Các đối tượng lớp trên cùng đăng ký các sự kiện trên lớp dưới cùng. Lớp dưới cùng không biết gì về lớp trên cùng, hoạt động như một phích cắm.

Ngoài ra còn có các cách khác để duy trì một hướng duy nhất, ví dụ:

• tiếp tục (truyền lambda hoặc phương thức được gọi và sự kiện cho phương thức async)
• phân lớp (tạo một lớp con trong A của lớp cha trong B, sau đó được chèn vào lớp dưới cùng, hơi giống như một plugin)

Tôi muốn thêm hai xu của mình vào những gì Matt Fenwick và Kilian Foth đã giải thích.

Một nguyên tắc của kiến ​​trúc phần mềm là các chương trình phức tạp nên được xây dựng bằng cách soạn các khối nhỏ hơn, khép kín (hộp đen): điều này giảm thiểu sự phụ thuộc do đó làm giảm độ phức tạp. Vì vậy, sự phụ thuộc đơn hướng này là một ý tưởng tốt vì nó giúp dễ hiểu phần mềm hơn và quản lý sự phức tạp là một trong những vấn đề quan trọng nhất trong phát triển phần mềm.

Vì vậy, trong một kiến ​​trúc lớp, các lớp bên dưới là các hộp đen thực hiện các lớp trừu tượng trên đó các lớp trên được xây dựng. Nếu một lớp thấp hơn (giả sử, lớp B) có thể nhìn thấy chi tiết của lớp trên A, thì B không còn là hộp đen nữa: chi tiết triển khai của nó phụ thuộc vào một số chi tiết của người dùng của chính nó, nhưng ý tưởng về hộp đen là nội dung (thực hiện của nó) là không liên quan cho người dùng của nó!

Chỉ để cho vui.

Hãy nghĩ về một kim tự tháp của đội cổ vũ. Hàng dưới cùng đang hỗ trợ các hàng phía trên chúng.

Nếu đội cổ vũ ở hàng đó nhìn xuống thì họ ổn định và sẽ giữ thăng bằng để những người phía trên cô không ngã.

Nếu cô ấy nhìn lên để xem mọi người phía trên đang làm gì, cô ấy sẽ mất thăng bằng khiến cả đống rơi xuống.

Không thực sự kỹ thuật, nhưng đó là một sự tương tự tôi nghĩ có thể giúp đỡ.

Mặc dù dễ hiểu và ở một mức độ nào đó, các thành phần có thể thay thế chắc chắn là lý do chính đáng, một lý do quan trọng không kém (và có lẽ là lý do mà các lớp được phát minh ra ngay từ đầu) là từ quan điểm bảo trì phần mềm. Điểm mấu chốt là sự phụ thuộc gây ra khả năng phá vỡ mọi thứ.

Ví dụ: giả sử A phụ thuộc vào B. Vì không có gì phụ thuộc vào A, các nhà phát triển có thể tự do thay đổi A thành nội dung trái tim của họ mà không phải lo lắng rằng họ có thể phá vỡ bất cứ điều gì ngoài A. Tuy nhiên, nếu nhà phát triển muốn thay đổi B thì mọi thay đổi Trong B được tạo ra có khả năng phá vỡ A. Đây là vấn đề thường gặp trong những ngày đầu máy tính (nghĩ là phát triển có cấu trúc) trong đó các nhà phát triển sẽ sửa một lỗi trong một phần của chương trình và nó sẽ phát sinh lỗi trong các phần rõ ràng không liên quan của chương trình ở nơi khác. Tất cả chỉ vì sự phụ thuộc.

Để tiếp tục với ví dụ, bây giờ giả sử A phụ thuộc vào B VÀ B phụ thuộc vào A. IOW, một phụ thuộc vòng tròn. Bây giờ, bất cứ khi nào một thay đổi được thực hiện ở bất cứ đâu nó có khả năng phá vỡ mô-đun khác. Một thay đổi trong B vẫn có thể phá vỡ A, nhưng bây giờ thay đổi trong A cũng có thể phá vỡ B.

Vì vậy, trong câu hỏi ban đầu của bạn, nếu bạn ở trong một nhóm nhỏ cho một dự án nhỏ thì tất cả điều này là quá mức cần thiết bởi vì bạn có thể tự do thay đổi các mô-đun theo ý thích của mình. Tuy nhiên, nếu bạn đang ở trong một dự án lớn, nếu tất cả các mô-đun phụ thuộc vào các dự án khác thì mỗi khi cần thay đổi, nó có khả năng phá vỡ các mô-đun khác. Trong một dự án lớn, việc biết tất cả các tác động có thể khó xác định nên bạn có thể sẽ bỏ lỡ một số tác động.

Nó trở nên tồi tệ hơn trên một dự án lớn, nơi có nhiều nhà phát triển, (ví dụ một số người chỉ làm việc lớp A, một số lớp B và một số lớp C). Vì có thể mỗi thay đổi phải được xem xét / thảo luận với các thành viên trên các lớp khác để đảm bảo các thay đổi của bạn không bị phá vỡ hoặc buộc phải làm lại những gì họ đang làm. Nếu những thay đổi của bạn buộc phải thay đổi người khác, thì bạn phải thuyết phục họ rằng họ nên thực hiện thay đổi, vì họ sẽ không muốn đảm nhận nhiều công việc hơn chỉ vì bạn có cách làm việc mới tuyệt vời này trong mô-đun của mình. IOW, một cơn ác mộng quan liêu.

Nhưng nếu bạn giới hạn phụ thuộc vào A phụ thuộc vào B, B phụ thuộc vào C thì chỉ có lớp C mọi người cần phối hợp các thay đổi của họ cho cả hai đội. Lớp B chỉ cần phối hợp các thay đổi với nhóm Lớp A và lớp A có thể tự do làm bất cứ điều gì họ muốn vì mã của họ không ảnh hưởng đến lớp B hoặc C. Vì vậy, lý tưởng nhất là bạn sẽ thiết kế lớp của mình để lớp C thay đổi rất nhiều ít, lớp B thay đổi phần nào và lớp A thực hiện hầu hết các thay đổi.

Lý do cơ bản nhất mà các lớp thấp hơn không nên biết về các lớp cao hơn là có nhiều loại lớp cao hơn. Chẳng hạn, có hàng ngàn và hàng ngàn chương trình khác nhau trên hệ thống Linux của bạn, nhưng chúng gọi cùng mallocchức năng thư viện C. Vì vậy, sự phụ thuộc là từ các chương trình này đến thư viện đó.

Lưu ý rằng "lớp dưới" thực sự là lớp giữa.

Hãy suy nghĩ về một ứng dụng giao tiếp qua thế giới bên ngoài thông qua một số trình điều khiển thiết bị. Hệ điều hành nằm ở giữa .

Hệ điều hành không phụ thuộc vào chi tiết trong các ứng dụng cũng như trong trình điều khiển thiết bị. Có nhiều loại trình điều khiển thiết bị cùng loại và chúng có chung khung trình điều khiển thiết bị. Đôi khi các tin tặc hạt nhân phải đưa một số trường hợp xử lý đặc biệt vào khung vì lợi ích của một phần cứng hoặc thiết bị cụ thể (ví dụ gần đây tôi bắt gặp: mã đặc trưng PL2303 trong khung nối tiếp USB của Linux). Khi điều đó xảy ra, họ thường đưa ra ý kiến ​​về việc hút và nên loại bỏ bao nhiêu. Mặc dù HĐH gọi các chức năng trong trình điều khiển, các cuộc gọi đi qua các móc nối làm cho trình điều khiển trông giống nhau, trong khi đó, trình điều khiển gọi HĐH, chúng thường sử dụng các chức năng cụ thể trực tiếp theo tên.

Vì vậy, theo một số cách, hệ điều hành thực sự là một lớp thấp hơn từ góc độ của ứng dụng và từ góc độ của ứng dụng: một loại trung tâm truyền thông nơi mọi thứ kết nối và dữ liệu được chuyển sang các con đường thích hợp. Nó giúp thiết kế trung tâm truyền thông xuất một dịch vụ linh hoạt có thể được sử dụng bởi bất cứ thứ gì và không di chuyển bất kỳ thiết bị hoặc ứng dụng cụ thể nào vào trung tâm.

Sự quan tâm của các mối quan tâm và cách tiếp cận chia / chinh phục có thể là một cách giải thích khác cho câu hỏi này. Sự quan tâm của các mối quan tâm mang lại khả năng di động và trong một số kiến ​​trúc phức tạp hơn, nó mang lại lợi thế cho quy mô và hiệu suất độc lập của nền tảng.

Trong bối cảnh này, nếu bạn nghĩ về kiến ​​trúc 5 tầng (khách hàng, trình bày, kinh doanh, tích hợp và tầng tài nguyên) thì cấp độ kiến ​​trúc thấp hơn không nên nhận thức về logic và kinh doanh của các cấp cao hơn và ngược lại. Ý tôi là ở cấp độ thấp hơn là cấp độ tích hợp và tài nguyên. Giao diện tích hợp cơ sở dữ liệu được cung cấp trong tích hợp và cơ sở dữ liệu thực và dịch vụ web (nhà cung cấp dữ liệu bên thứ 3) thuộc về lớp tài nguyên. Vì vậy, giả sử bạn sẽ thay đổi cơ sở dữ liệu MySQL của mình thành DB tài liệu NoQuery như MangoDB về khả năng mở rộng hoặc bất cứ điều gì.

Theo cách tiếp cận này, tầng bussiness không quan tâm đến cách tầng tích hợp cung cấp kết nối / truyền bởi tài nguyên. Nó chỉ tìm kiếm các đối tượng truy cập dữ liệu được cung cấp bởi tầng tích hợp. Điều này có thể được mở rộng sang nhiều kịch bản hơn nhưng về cơ bản, sự lo ngại có thể là lý do số một cho việc này.

Mở rộng theo câu trả lời của Kilian Foth, hướng xếp lớp này tương ứng với hướng mà con người khám phá một hệ thống.

Hãy tưởng tượng rằng bạn là một nhà phát triển mới được giao nhiệm vụ sửa lỗi trong hệ thống lớp.

Lỗi thường là sự không phù hợp giữa những gì khách hàng cần và những gì anh ta nhận được. Khi khách hàng giao tiếp với hệ thống thông qua UI và nhận được kết quả thông qua UI (UI có nghĩa đen là 'giao diện người dùng'), các lỗi cũng được báo cáo theo giao diện người dùng. Vì vậy, là một nhà phát triển, bạn không có nhiều sự lựa chọn ngoài việc bắt đầu nhìn vào UI, để tìm hiểu điều gì đã xảy ra.

Đó là lý do tại sao có kết nối lớp từ trên xuống là cần thiết. Bây giờ, tại sao chúng ta không có kết nối đi cả hai chiều?

Chà, bạn có ba kịch bản làm thế nào lỗi đó có thể xảy ra.

Nó có thể xảy ra trong chính mã UI và do đó được bản địa hóa ở đó. Điều này thật dễ dàng, bạn chỉ cần tìm một nơi và sửa nó.

Nó có thể xảy ra ở các phần khác của hệ thống do các cuộc gọi được thực hiện từ UI. Khó khăn vừa phải, bạn theo dõi một cây các cuộc gọi, tìm một nơi xảy ra lỗi và sửa nó.

Và nó có thể xảy ra do một cuộc gọi VÀO mã UI của bạn. Cái nào khó, bạn phải bắt cuộc gọi, tìm nguồn của nó, sau đó tìm ra lỗi xảy ra ở đâu. Xem xét rằng một điểm bạn bắt đầu nằm sâu trong một nhánh của cây cuộc gọi, VÀ bạn cần tìm một cây gọi chính xác trước, có thể có một số cuộc gọi vào mã UI, bạn đã gỡ lỗi cho bạn.

Để loại bỏ trường hợp khó nhất có thể, các phụ thuộc vòng tròn được khuyến khích mạnh mẽ, các lớp kết nối chủ yếu theo kiểu từ trên xuống. Ngay cả khi một kết nối theo cách khác là cần thiết, nó thường bị giới hạn và được xác định rõ ràng. Ví dụ, ngay cả với các cuộc gọi lại, là một loại kết nối ngược, mã được gọi trong cuộc gọi lại thường cung cấp cuộc gọi lại này ngay từ đầu, thực hiện một loại "chọn tham gia" cho các kết nối ngược và hạn chế tác động của chúng trong việc hiểu hệ thống.

Layering là một công cụ và chủ yếu nhắm vào các nhà phát triển hỗ trợ một hệ thống hiện có. Vâng, kết nối giữa các lớp cũng phản ánh điều đó.

Một lý do khác mà tôi muốn thấy được đề cập rõ ràng ở đây là khả năng sử dụng lại mã . Chúng ta đã có ví dụ về phương tiện truyền thông RS232 được thay thế, vì vậy hãy tiến thêm một bước nữa ...

Hãy tưởng tượng bạn đang phát triển trình điều khiển. Đó là công việc của bạn và bạn viết khá nhiều. Các giao thức có thể có thể bắt đầu lặp lại tại một số điểm, như phương tiện vật lý.

Vì vậy, những gì bạn sẽ bắt đầu làm - trừ khi bạn là một người hâm mộ tuyệt vời để làm điều tương tự lặp đi lặp lại - là viết các lớp có thể tái sử dụng cho những điều này.

Giả sử bạn phải viết 5 trình điều khiển cho các thiết bị Modbus. Một trong số họ sử dụng Modbus TCP, hai sử dụng Modbus trên RS485 và phần còn lại đi qua RS232. Bạn sẽ không thực hiện lại Modbus 5 lần, vì bạn đang viết 5 trình điều khiển. Ngoài ra, bạn sẽ không thực hiện lại Modbus 3 lần, bởi vì bạn có 3 lớp Vật lý khác nhau bên dưới bạn.

Những gì bạn làm là, bạn viết TCP Media Access, RS485 Media Access và có thể là truy cập phương tiện truyền thông RS232. Tại thời điểm này, có thông minh không khi biết rằng sẽ có một lớp modbus ở trên? Chắc là không. Trình điều khiển tiếp theo bạn sẽ triển khai cũng có thể sử dụng Ethernet nhưng sử dụng HTTP-REST. Sẽ thật xấu hổ nếu bạn phải thực hiện lại Ethernet Media Access để giao tiếp qua HTTP.

Một lớp ở trên, bạn sẽ triển khai Modbus chỉ một lần. Lớp Modbus đó một lần nữa, sẽ không biết về trình điều khiển, đó là một lớp. Những trình điều khiển này, tất nhiên sẽ phải biết rằng họ phải nói chuyện với modbus và họ phải biết rằng họ đang sử dụng Ethernet. Howevever thực hiện theo cách tôi vừa mô tả, bạn không chỉ có thể tách ra một lớp và thay thế nó. tất nhiên bạn có thể - và với tôi đó là lợi ích lớn nhất của tất cả, hãy tiếp tục và sử dụng lại lớp Ethernet hiện tại cho một thứ hoàn toàn không liên quan đến dự án ban đầu gây ra nó.

Đây là một cái gì đó, có lẽ chúng ta thấy mỗi ngày là nhà phát triển và điều đó giúp chúng ta tiết kiệm hàng tấn thời gian. Có vô số Thư viện cho tất cả các loại giao thức và những thứ khác. Chúng tồn tại bởi vì các nguyên tắc như hướng phụ thuộc theo hướng lệnh, cho phép chúng tôi xây dựng các lớp phần mềm có thể sử dụng lại.