Trừu tượng là gì? [đóng cửa]

Có một định nghĩa chung đã được thống nhất cho việc trừu tượng hóa lập trình là gì, như được sử dụng bởi các lập trình viên? [Lưu ý, trừu tượng hóa lập trình không được nhầm lẫn với các định nghĩa từ điển cho từ "trừu tượng hóa".] Có một định nghĩa rõ ràng, hoặc thậm chí là toán học không? Một số ví dụ rõ ràng về trừu tượng là gì?

Câu trả lời cho "Bạn có thể định nghĩa một sự trừu tượng hóa lập trình là nhiều hay ít về mặt toán học?" là "không." Trừu tượng không phải là một khái niệm toán học. Nó sẽ giống như yêu cầu ai đó giải thích màu sắc của một quả chanh một cách toán học.

Nếu bạn muốn có một định nghĩa tốt: trừu tượng là quá trình chuyển từ một ý tưởng cụ thể sang một ý tưởng tổng quát hơn. Ví dụ, hãy nhìn vào con chuột của bạn. Có phải là không dây? Nó có loại cảm biến nào? Có bao nhiêu nút? Có tiện dụng không? Nó lớn như thế nào Câu trả lời cho tất cả các câu hỏi này có thể mô tả chính xác con chuột của bạn, nhưng bất kể câu trả lời là gì, nó vẫn là chuột, bởi vì đó là một thiết bị trỏ với các nút. Đó là tất cả những gì nó cần để trở thành một con chuột. "Silver Logitech MX518" là một mặt hàng cụ thể, cụ thể và "chuột" là một sự trừu tượng hóa của điều đó. Một điều quan trọng cần suy nghĩ là không có vật thể cụ thể như "chuột", đó chỉ là một ý tưởng. Con chuột trên bàn của bạn luôn là một cái gì đó cụ thể hơn - nó '

Sự trừu tượng có thể được xếp lớp và tạo hạt mịn hoặc thô tùy thích (MX518 là một con chuột, là một vật thể trỏ, là một thiết bị ngoại vi máy tính, là một vật thể được cung cấp bởi điện), có thể đi xa như bạn muốn và gần như theo bất kỳ hướng nào bạn muốn (chuột của tôi có một sợi dây, nghĩa là tôi có thể phân loại nó thành một vật thể bằng một sợi dây. Nó cũng nằm ở phía dưới, vì vậy tôi có thể phân loại nó thành một loại vật thể sẽ không lăn khi đặt thẳng đứng trên một mặt phẳng nghiêng).

Lập trình hướng đối tượng được xây dựng trên khái niệm trừu tượng và gia đình hoặc nhóm của chúng. OOP tốt có nghĩa là chọn trừu tượng tốt ở mức độ chi tiết phù hợp có ý nghĩa trong miền của chương trình của bạn và không "rò rỉ". Điều này có nghĩa là phân loại chuột là một vật thể không lăn trên mặt phẳng nghiêng không có ý nghĩa đối với một ứng dụng kiểm kê thiết bị máy tính, nhưng nó có thể có ý nghĩa đối với một trình giả lập vật lý. Điều thứ hai có nghĩa là bạn nên cố gắng tránh "tự đấm bốc" vào một hệ thống phân cấp không có ý nghĩa đối với một số loại đối tượng. Ví dụ, trong hệ thống phân cấp của tôi ở trên, chúng tôi chắc chắn rằng tất cảthiết bị ngoại vi máy tính được cung cấp bởi điện? Còn bút stylus thì sao? Nếu chúng ta muốn nhóm bút stylus vào danh mục "ngoại vi", chúng ta sẽ gặp vấn đề, vì nó không sử dụng điện và chúng ta đã định nghĩa các thiết bị ngoại vi máy tính là các đối tượng sử dụng điện. Bài toán hình elip hình tròn là ví dụ nổi tiếng nhất của câu hỏi hóc búa này.

Tôi không đồng ý với hầu hết các câu trả lời.

Đây là câu trả lời của tôi:

Cho hai bộ G và H, một kết nối Galois (alpha, beta) có thể được xác định giữa chúng và có thể nói là một bộ cụ thể hóa của bộ kia; đảo ngược kết nối, và cái này là sự trừu tượng của cái kia. Các chức năng là một chức năng cụ thể hóa và một chức năng trừu tượng hóa.

Đây là từ lý thuyết giải thích trừu tượng các chương trình máy tính, thường là một phương pháp phân tích tĩnh cho đến nay.

Trừu tượng là tập trung nhiều hơn Whatvà ít hơn vào How. Hoặc bạn có thể nói, chỉ biết những điều bạn cần và chỉ tin tưởng nhà cung cấp cho tất cả các dịch vụ khác. Nó đôi khi thậm chí che giấu danh tính của nhà cung cấp dịch vụ.

Ví dụ: trang web này cung cấp một hệ thống để đặt câu hỏi và trả lời chúng. Hầu như tất cả mọi người ở đây đều biết các thủ tục để hỏi, trả lời, bỏ phiếu và những thứ khác của trang web này là gì. Nhưng rất ít người biết các công nghệ cơ bản là gì. Giống như liệu trang web được phát triển với ASP.net mvc hay Python, cho dù trang này chạy trên máy chủ Windows hay Linux, v.v. Bởi vì đó không phải là việc của chúng tôi. Vì vậy, trang web này đang giữ một lớp trừu tượng trên cơ chế cơ bản của nó để chúng tôi cung cấp dịch vụ.

Một số ví dụ khác:

• Một chiếc xe che giấu tất cả các cơ chế của nó nhưng cung cấp một cách để lái xe, tiếp nhiên liệu và duy trì nó cho chủ sở hữu của nó.

• Bất kỳ API nào ẩn tất cả các chi tiết triển khai của nó cung cấp dịch vụ cho các lập trình viên khác.

• Một lớp trong OOP che giấu các thành viên tư nhân của mình và triển khai các thành viên công cộng cung cấp dịch vụ để gọi các thành viên công cộng.

• Trong khi sử dụng một đối tượng thuộc loại Interfacehoặc một abstract classtrong Java hoặc C ++, việc triển khai thực sự bị ẩn đi. Và không chỉ ẩn, việc triển khai các phương thức được khai báo trong Interfacecũng có khả năng khác nhau trong các lớp được thực hiện / kế thừa khác nhau. Nhưng khi bạn đang nhận được cùng một dịch vụ, đừng bận tâm Hownó được triển khai và chính xác Who/ Whatđang cung cấp dịch vụ.

• Ẩn danh tính : Đối với câu "Tôi biết Sam có thể viết chương trình máy tính." sự trừu tượng có thể là - "Sam là một lập trình viên. Các lập trình viên biết cách viết chương trình máy tính." Trong tuyên bố thứ hai, người không quan trọng. Nhưng khả năng làm lập trình của anh ấy rất quan trọng.

Một sự trừu tượng hóa lập trình là một mô hình đơn giản hóa của một vấn đề.

Ví dụ: kết nối TCP / IP là sự trừu tượng trong việc gửi dữ liệu. Bạn chỉ bao gồm một địa chỉ IP và số cổng và gửi nó đến API. Bạn không quan tâm đến tất cả các chi tiết về dây dẫn, tín hiệu, định dạng tin nhắn và lỗi.

Một sự trừu tượng chỉ là phiên bản lập trình của một định lý.

Bạn có một hệ thống chính thức, bạn đề xuất một suy nghĩ về hệ thống đó. Bạn làm một bằng chứng về nó, và nếu nó hoạt động, thì bạn có một định lý. Biết rằng định lý của bạn giữ, sau đó bạn có thể sử dụng nó trong các bằng chứng tiếp theo về hệ thống. Các nguyên hàm được cung cấp bởi hệ thống (như nếu các câu lệnh và các loại giá trị int) thường được xem là tiên đề, mặc dù điều đó không đúng hoàn toàn vì bất kỳ điều gì không phải là các lệnh CPU được viết bằng mã máy là một loại trừu tượng.

Trong lập trình chức năng, ý tưởng về một chương trình như một câu lệnh toán học rất mạnh và thường là hệ thống kiểu (trong một ngôn ngữ được gõ tĩnh, mạnh như Haskell, F # hoặc OCAML) có thể được sử dụng để kiểm tra định lý thông qua các bằng chứng.

Ví dụ: chúng ta hãy nói rằng chúng ta có kiểm tra cộng và kiểm tra dưới dạng các phép toán nguyên thủy, và các số nguyên và booleans là các kiểu dữ liệu nguyên thủy. Đây là những tiên đề của chúng tôi. Vì vậy, chúng ta có thể nói đó 1 + 3 == 2 + 2là một định lý, sau đó sử dụng các quy tắc cộng, số nguyên và đẳng thức để xem đó có phải là một tuyên bố đúng hay không.

Bây giờ chúng ta hãy giả sử rằng chúng ta muốn nhân, và nguyên thủy của chúng ta (vì sự ngắn gọn) bao gồm một cấu trúc lặp và một phương tiện để gán các tham chiếu tượng trưng. Chúng tôi có thể đề nghị rằng

ref x (*) y := loop y times {x +}) 0

Tôi sẽ giả vờ rằng tôi đã chứng minh điều đó, chứng minh rằng phép nhân giữ. Bây giờ tôi có thể sử dụng phép nhân để làm nhiều thứ hơn với hệ thống của mình (ngôn ngữ lập trình).

Tôi cũng có thể kiểm tra hệ thống loại của tôi. (*) có loại int -> int -> int. Phải mất 2 ints và xuất ra một int. Bổ sung có một loại int -> int -> int vì vậy 0 + (phần còn lại) giữ miễn là (phần còn lại) dẫn đến một int. Vòng lặp của tôi có thể làm tất cả mọi thứ, nhưng tôi đang nói rằng nó tạo ra một chuỗi các hàm bị biến dạng sao cho (x + (x + (x ... + 0))) là kết quả. Hình thức của chuỗi bổ sung đó chỉ là (int -> (int -> (int ... -> int))) vì vậy tôi biết đầu ra cuối cùng của mình sẽ là một int. Vì vậy, hệ thống loại của tôi giữ kết quả bằng chứng khác của tôi!

Hợp nhất loại ý tưởng này trong nhiều năm, nhiều lập trình viên, và nhiều dòng mã, và bạn có ngôn ngữ lập trình hiện đại: một tập hợp nguyên thủy và các thư viện khổng lồ về trừu tượng mã đã được chứng minh.

Câu trả lời của Wikipedia có đủ tốt không? http://en.wikipedia.org/wiki/ Abstraction_% 28programming% 29

Trong khoa học máy tính, cơ chế và thực hành trừu tượng làm giảm và đưa ra các chi tiết để người ta có thể tập trung vào một vài khái niệm tại một thời điểm.

Về mặt toán học, "số nguyên" là một sự trừu tượng. Và khi bạn thực hiện các bằng chứng chính thức như thế x + y = y + x cho tất cả các số nguyên, bạn đang làm việc với "số nguyên" trừu tượng thay vì các số cụ thể như 3 hoặc 4. Điều tương tự xảy ra trong phát triển phần mềm khi bạn tương tác với máy ở mức trên các thanh ghi và vị trí bộ nhớ. Bạn có thể nghĩ những suy nghĩ mạnh mẽ hơn ở mức độ trừu tượng hơn, trong hầu hết các trường hợp.

Bạn đang nhận được câu trả lời tốt ở đây. Tôi chỉ thận trọng - mọi người nghĩ rằng sự trừu tượng bằng cách nào đó là điều tuyệt vời này cần được đặt trên bệ, và rằng bạn không thể có đủ. Không phải vậy. Đó chỉ là ý thức chung. Nó chỉ là nhận ra sự tương đồng giữa các thứ, vì vậy bạn có thể áp dụng một giải pháp vấn đề cho một loạt các vấn đề.

Cho phép tôi đi tiểu ...

Cao trong danh sách phiền toái của tôi là khi mọi người nói về "các lớp trừu tượng" như thể đó là một điều tốt. Họ tạo ra "trình bao bọc" xung quanh các lớp học hoặc thói quen mà họ không thích và gọi chúng là "trừu tượng hơn", như thể điều đó sẽ làm cho chúng tốt hơn. Bạn còn nhớ câu chuyện ngụ ngôn về "Công chúa và hạt đậu" không? Công chúa tinh tế đến mức nếu có một hạt đậu dưới nệm, cô sẽ không thể ngủ được, và thêm nhiều lớp nệm sẽ không giúp ích gì. Ý tưởng rằng việc thêm nhiều lớp "trừu tượng" sẽ giúp ích giống như vậy - thường thì không. Nó chỉ có nghĩa là bất kỳ thay đổi nào đối với thực thể cơ sở phải được gợn qua nhiều lớp mã.

Tôi nghĩ rằng bạn có thể tìm thấy một bài viết trên blog của tôi về trừu tượng rò rỉ hữu ích. Đây là nền tảng có liên quan:

Trừu tượng là một cơ chế giúp lấy những gì phổ biến giữa một tập hợp các đoạn chương trình liên quan, loại bỏ sự khác biệt của chúng và cho phép các lập trình viên làm việc trực tiếp với một cấu trúc đại diện cho khái niệm trừu tượng đó. Cấu trúc mới này (hầu như) luôn có các tham số hóa : một phương tiện để tùy chỉnh việc sử dụng cấu trúc để phù hợp với nhu cầu cụ thể của bạn.

Ví dụ, một Listlớp có thể trừu tượng hóa các chi tiết của việc thực hiện danh sách được liên kết - trong đó thay vì suy nghĩ về các thao tác nextvà previouscon trỏ, bạn có thể suy nghĩ về mức độ thêm hoặc xóa các giá trị vào một chuỗi. Trừu tượng là một công cụ thiết yếu để tạo ra các tính năng hữu ích, phong phú và đôi khi phức tạp từ một tập hợp nhỏ hơn nhiều các khái niệm nguyên thủy hơn.

Trừu tượng có liên quan đến đóng gói và mô đun hóa, và những khái niệm này thường bị hiểu sai.

Trong Liství dụ, đóng gói có thể được sử dụng để ẩn các chi tiết thực hiện của danh sách liên kết; trong một ngôn ngữ hướng đối tượng, chẳng hạn, bạn có thể đặt nextvà previouscon trỏ ở chế độ riêng tư, trong đó chỉ thực hiện Danh sách mới được phép truy cập vào các trường này.

Đóng gói là không đủ cho sự trừu tượng, bởi vì nó không nhất thiết ngụ ý bạn có một quan niệm mới hoặc khác về các cấu trúc. Nếu tất cả một Listlớp đã cung cấp cho bạn các phương thức truy cập kiểu ' getNext' / ' setNext', nó sẽ gói gọn từ bạn từ các chi tiết triển khai (ví dụ: bạn đã đặt tên trường ' prev' hay ' previous'? Kiểu tĩnh của nó là gì?), Nhưng nó sẽ có một mức độ trừu tượng rất thấp.

Tính mô đun liên quan đến việc ẩn thông tin : Các thuộc tính ổn định được chỉ định trong một giao diện và mô-đun thực hiện giao diện đó, giữ tất cả các chi tiết triển khai trong mô-đun. Tính mô đun giúp lập trình viên đối phó với sự thay đổi, bởi vì các mô-đun khác chỉ phụ thuộc vào giao diện ổn định.

Việc ẩn thông tin được hỗ trợ bởi đóng gói (để mã của bạn không phụ thuộc vào chi tiết triển khai không ổn định), nhưng đóng gói là không cần thiết cho mô đun. Ví dụ, bạn có thể thực hiện một Listcấu trúc trong C, để lộ ' next' và ' prev' con trỏ với thế giới, mà còn cung cấp một giao diện, có chứa initList(), addToList()vàremoveFromList()chức năng. Với điều kiện là các quy tắc của giao diện được tuân theo, bạn có thể đảm bảo rằng các thuộc tính nhất định sẽ luôn được giữ, chẳng hạn như đảm bảo cấu trúc dữ liệu luôn ở trạng thái hợp lệ. [Ví dụ, bài báo kinh điển của Parnas về tính mô đun, được viết với một ví dụ trong lắp ráp. Giao diện là một hợp đồng và một hình thức truyền thông về thiết kế, nó không nhất thiết phải được kiểm tra một cách máy móc, mặc dù đó là những gì chúng ta dựa vào ngày nay.]

Mặc dù các thuật ngữ như trừu tượng, mô-đun và đóng gói được sử dụng làm mô tả thiết kế tích cực, điều quan trọng cần nhận ra là sự hiện diện của bất kỳ phẩm chất nào trong số này không tự động mang lại cho bạn thiết kế tốt:

• Nếu thuật toán n ^ 3 được "đóng gói độc đáo", nó vẫn sẽ hoạt động kém hơn thuật toán n log n được cải tiến.

• Nếu một giao diện cam kết với một hệ điều hành cụ thể, sẽ không có bất kỳ lợi ích nào của thiết kế mô-đun khi nhận ra, một trò chơi video cần phải được chuyển từ Windows sang iPad.

• Nếu sự trừu tượng được tạo ra phơi bày quá nhiều chi tiết không cần thiết, nó sẽ thất bại trong việc tạo ra một cấu trúc mới với các hoạt động riêng của nó: Nó đơn giản sẽ là một tên khác cho cùng một thứ.

Ok, tôi nghĩ rằng tôi đã tìm ra những gì bạn đang hỏi: "Định nghĩa chặt chẽ về mặt toán học của 'Một sự trừu tượng'."

Nếu đó là trường hợp, tôi nghĩ bạn không gặp may - 'trừu tượng' là một thuật ngữ thiết kế / kiến ​​trúc phần mềm và không có sự hỗ trợ toán học nào theo như tôi biết (có lẽ ai đó thành thạo hơn về lý thuyết CS sẽ sửa lỗi cho tôi ở đây), bất kỳ nhiều hơn "khớp nối" hoặc "ẩn thông tin" đều có định nghĩa toán học.

Trừu tượng là khi bạn bỏ qua các chi tiết được coi là không liên quan có lợi cho những người được coi là có liên quan.

Trừu tượng bao gồm đóng gói, ẩn thông tin và khái quát hóa. Nó không bao gồm các phép loại suy, ẩn dụ hoặc heuristic.

Bất kỳ chủ nghĩa hình thức toán học nào cho khái niệm trừu tượng tự nó sẽ là một sự trừu tượng hóa, vì nó nhất thiết đòi hỏi điều cơ bản phải được trừu tượng hóa thành một tập hợp các thuộc tính toán học! Khái niệm lý thuyết phạm trù của một hình thái có lẽ là gần nhất với những gì bạn đang tìm kiếm.

Trừu tượng không phải là thứ bạn tuyên bố, nó là thứ bạn làm .

Như một cách giải thích cho người khác, tôi sẽ đi theo một cách khác, từ kết quả trở lại:

Trừu tượng hóa trong lập trình máy tính là hành động khái quát hóa một cái gì đó đến mức nhiều hơn một thứ tương tự có thể được coi là giống nhau và được xử lý như nhau.

Nếu bạn muốn mở rộng trên đó, bạn có thể thêm:

Đôi khi điều này được thực hiện để đạt được hành vi đa hình (giao diện và kế thừa) để cắt giảm mã lặp đi lặp lại, lần khác nó được thực hiện để hoạt động bên trong của một cái gì đó có thể được thay thế vào một ngày trong tương lai bằng một giải pháp tương tự mà không phải thay đổi mã ở phía bên kia của thùng chứa trừu tượng hoặc trình bao bọc, hy vọng sẽ cắt giảm việc làm lại trong tương lai.

Ngoài ra, tôi nghĩ bạn phải bắt đầu vào các ví dụ ...

Bạn có thể muốn kiểm tra một số số liệu của Bob Martin

http://en.wikipedia.org/wiki/Software_package_metrics

Điều đó nói rằng, tôi không nghĩ "Trừu tượng" của anh ấy giống như của bạn. Đây là một biện pháp "thiếu thực hiện trên một lớp" nghĩa là sử dụng các giao diện / lớp trừu tượng. Sự không ổn định và Khoảng cách từ Chuỗi chính có thể phát huy nhiều hơn những gì bạn đang tìm kiếm.

Merriam-webster định nghĩa trừu tượng như một tính từ: tách rời khỏi bất kỳ trường hợp cụ thể nào.

Một sự trừu tượng là một mô hình của một số hệ thống. Họ thường liệt kê một nhóm các giả định phải đáp ứng cho một hệ thống thực sự để có thể được mô hình hóa bằng sự trừu tượng hóa và chúng thường được sử dụng để cho phép chúng ta khái niệm hóa các hệ thống ngày càng phức tạp. Đi từ một hệ thống thực sự đến một sự trừu tượng không có bất kỳ phương pháp toán học chính thức nào để làm như vậy. Điều đó tùy thuộc vào sự phán xét của bất cứ ai đang xác định sự trừu tượng hóa, và mục đích của sự trừu tượng hóa là gì.

Thông thường, mặc dù, trừu tượng được xác định theo các cấu trúc toán học. Điều đó có lẽ bởi vì chúng thường được sử dụng trong khoa học và kỹ thuật.

Một ví dụ là cơ học Newton. Nó giả định rằng tất cả mọi thứ là vô cùng nhỏ, và tất cả năng lượng được bảo tồn. Các tương tác giữa các đối tượng được xác định rõ ràng bằng các công thức toán học. Bây giờ, như chúng ta đã biết, vũ trụ không hoàn toàn hoạt động theo cách đó, và trong nhiều tình huống, sự trừu tượng bị rò rỉ. Nhưng trong rất nhiều tình huống, nó hoạt động rất tốt.

Một mô hình trừu tượng khác là các phần tử mạch tuyến tính, điện trở, tụ điện và cuộn cảm điển hình. Một lần nữa các tương tác được xác định rõ ràng bằng các công thức toán học. Đối với các mạch tần số thấp, hoặc trình điều khiển rơle đơn giản và những thứ khác, phân tích RLC hoạt động tốt và cung cấp kết quả rất tốt. Nhưng các tình huống khác, như các mạch vô tuyến vi sóng, các phần tử quá lớn và các tương tác tốt hơn và các tóm tắt RLC đơn giản không giữ được. Làm gì vào thời điểm đó là tùy theo phán đoán của kỹ sư. Một số kỹ sư đã tạo ra một sự trừu tượng khác trên các công cụ khác, một số thay thế các op-amp lý tưởng bằng các công thức toán học mới cho cách chúng hoạt động, một số khác thay thế các ampe op lý tưởng bằng các op-amp thực được mô phỏng, lần lượt được mô phỏng bằng một mạng phức tạp nhỏ hơn yếu tố lý tưởng.

Như những người khác đã nói, nó là một mô hình đơn giản hóa. Nó là một công cụ được sử dụng để hiểu rõ hơn các hệ thống phức tạp.

Một sự trừu tượng đại diện cho một cái gì đó (ví dụ như một khái niệm, cấu trúc dữ liệu, chức năng) dưới dạng một cái gì đó khác. Ví dụ chúng ta sử dụng từ ngữ để giao tiếp. Một từ là một thực thể trừu tượng có thể được thể hiện dưới dạng âm thanh (lời nói) hoặc về mặt biểu tượng đồ họa (chữ viết). Ý tưởng chính của một sự trừu tượng là thực thể trong câu hỏi khác với biểu diễn cơ bản, giống như một từ không phải là âm thanh được sử dụng để nói ra nó hoặc các chữ cái được sử dụng để viết nó.

Do đó, ít nhất là về mặt lý thuyết, biểu diễn cơ bản của một sự trừu tượng có thể được thay thế bằng một biểu diễn khác. Tuy nhiên, trong thực tế, sự trừu tượng hiếm khi hoàn toàn khác biệt với biểu diễn cơ bản và đôi khi biểu diễn " rò rỉ " thông qua. Ví dụ, bài phát biểu mang âm hưởng cảm xúc rất khó truyền đạt bằng văn bản. Bởi vì điều này một bản ghi âm và bản phiên âm của cùng một từ có thể có hiệu ứng rất khác nhau đối với khán giả. Nói cách khác, sự trừu tượng của các từ thường bị rò rỉ.

Trừu tượng thường đến trong các lớp. Các từ là trừu tượng có thể được biểu thị bằng các chữ cái, đến lượt chúng là trừu tượng của âm thanh, đến lượt chúng trừu tượng hóa mô hình chuyển động của các hạt không khí được tạo ra bởi các hợp âm của một người và được phát hiện bởi trống tai của một người .

Trong bit khoa học máy tính thường là mức độ đại diện thấp nhất. Byte, vị trí bộ nhớ, hướng dẫn lắp ráp và thanh ghi CPU là mức trừu tượng tiếp theo. Sau đó, chúng ta có các kiểu dữ liệu nguyên thủy và hướng dẫn của ngôn ngữ cấp cao hơn, được triển khai theo byte, vị trí bộ nhớ và hướng dẫn lắp ráp. Sau đó, các hàm và các lớp (giả sử một ngôn ngữ OO) được triển khai theo các kiểu dữ liệu nguyên thủy và được xây dựng theo các hướng dẫn ngôn ngữ. Sau đó, các hàm và lớp phức tạp hơn được thực hiện theo các hàm đơn giản hơn. Một số các hàm và lớp này triển khai các cấu trúc dữ liệu, chẳng hạn như danh sách, ngăn xếp, hàng đợi, v.v ... Lần lượt chúng được sử dụng để thể hiện các thực thể cụ thể hơn như hàng đợi các quy trình hoặc danh sách nhân viên hoặc bảng băm của tiêu đề sách .

Một cách tôi cố gắng để mô tả nó với mọi người, có thể không phải là cách tốt nhất

Hãy xem xét một Chương trình có thêm 2 + 2 và xuất ra 4

Hãy xem xét một chương trình thêm hai số đầu vào của người dùng, x + y = z

Cái nào hữu ích và tổng quát hơn?

Tôi sẽ lập luận rằng một sự trừu tượng là một cái gì đó che giấu các chi tiết không cần thiết. Một trong những đơn vị trừu tượng cơ bản nhất là thủ tục. Chẳng hạn, tôi không muốn lo lắng về cách tôi lưu dữ liệu vào cơ sở dữ liệu khi tôi đọc dữ liệu đó từ một tệp. Vì vậy, tôi tạo một hàm save_to_database.

Trừu tượng cũng có thể được nối với nhau để tạo thành trừu tượng lớn hơn. Ví dụ, các hàm có thể được đặt cùng nhau trong một lớp, các lớp có thể được đặt cùng nhau để tạo thành một chương trình, các chương trình có thể được đặt cùng nhau để tạo thành một hệ thống phân tán, v.v.

Tôi luôn nghĩ về sự trừu tượng trong lập trình là ẩn các chi tiết và cung cấp một giao diện đơn giản hóa. Đó là lý do chính khiến các lập trình viên có thể chia nhỏ các nhiệm vụ hoành tráng thành các phần có thể quản lý được. Với tính trừu tượng, bạn có thể tạo giải pháp cho một phần của vấn đề, bao gồm tất cả các chi tiết nghiệt ngã, sau đó cung cấp giao diện đơn giản để sử dụng giải pháp. Sau đó, bạn có thể có hiệu lực "quên" về các chi tiết. Điều này rất quan trọng vì không có cách nào một người có thể giữ tất cả các chi tiết của một hệ thống siêu phức tạp trong tâm trí họ cùng một lúc. Điều này không có nghĩa là các chi tiết bên dưới sự trừu tượng sẽ không bao giờ phải xem lại, nhưng hiện tại, chỉ có giao diện phải được ghi nhớ.

Trong lập trình, giao diện đơn giản hóa này có thể là bất cứ thứ gì từ một biến (trừu tượng hóa một nhóm bit và cung cấp giao diện toán học đơn giản hơn) cho một hàm (trừu tượng hóa bất kỳ số lượng xử lý nào thành một cuộc gọi một dòng) cho một lớp và hơn thế nữa.

Cuối cùng, công việc chính của lập trình viên là thường trừu tượng hóa tất cả các chi tiết tính toán và cung cấp một giao diện đơn giản như GUI mà ai đó không biết một điều về cách máy tính hoạt động có thể sử dụng.

Một số ưu điểm của sự trừu tượng là:

• Cho phép một vấn đề lớn được chia thành các phần có thể quản lý. Khi thêm hồ sơ của một người vào cơ sở dữ liệu, bạn không muốn phải lộn xộn với việc chèn và cân bằng cây chỉ mục trên cơ sở dữ liệu. Công việc này có thể đã được thực hiện tại một số điểm, nhưng bây giờ đã được trừu tượng hóa và bạn không còn phải lo lắng về nó.

• Cho phép nhiều người làm việc tốt với nhau trong một dự án. Tôi không muốn phải biết tất cả các thông tin chi tiết về mã của đồng nghiệp. Tôi chỉ muốn biết làm thế nào để sử dụng nó, những gì nó làm và làm thế nào để phù hợp với công việc của tôi (giao diện).

• Cho phép những người không có kiến ​​thức cần thiết để thực hiện một nhiệm vụ phức tạp để thực hiện. Mẹ tôi có thể cập nhật facebook của mình và những người mà cô ấy biết trên toàn quốc có thể xem nó. Nếu không có sự trừu tượng của một hệ thống cực kỳ phức tạp đối với một giao diện web đơn giản, không có cách nào cô ấy có thể bắt đầu làm một cái gì đó tương tự (tôi cũng sẽ không làm điều đó).

Tuy nhiên, sự trừu tượng có thể có tác dụng ngược làm cho mọi thứ trở nên khó quản lý hơn nếu nó bị lạm dụng. Bằng cách chia nhỏ một vấn đề thành quá nhiều phần nhỏ, số lượng giao diện bạn phải nhớ tăng lên và khó hiểu hơn những gì đang thực sự xảy ra. Giống như hầu hết mọi thứ, một sự cân bằng phải được tìm thấy.

Một mức độ bổ sung.

Bạn không muốn quan tâm xem đối tượng bạn đang sử dụng là a Cathay a Dog, vì vậy bạn đi qua một bảng chức năng ảo để tìm đúng makeNoise()chức năng.

Tôi chắc chắn điều này cũng có thể được áp dụng cho các mức 'thấp hơn' và 'cao hơn' - nghĩ về một trình biên dịch tìm kiếm hướng dẫn phù hợp để sử dụng cho một bộ xử lý nhất định hoặc Monadtrừu tượng hóa của Haskell về các hiệu ứng tính toán bằng cách gọi mọi thứ returnvà >>=.

Đây là một cái gì đó tôi thực sự muốn viết blog trong một thời gian dài, nhưng tôi không bao giờ có được nó. May mắn thay, tôi là một zombie đại diện và thậm chí còn có một tiền thưởng. Bài viết của tôi hóa ra khá dài , nhưng đây là bản chất:

Trừu tượng hóa trong lập trình là về việc hiểu bản chất của một đối tượng trong một bối cảnh nhất định.

[...]

Trừu tượng hóa không chỉ bị nhầm lẫn với khái quát hóa, mà còn bị đóng gói, nhưng đây là hai phần trực giao của ẩn thông tin: Mô-đun dịch vụ quyết định những gì nó sẵn sàng hiển thị và mô-đun máy khách quyết định những gì nó sẵn sàng nhìn thấy. Đóng gói là phần đầu tiên và trừu tượng hóa phần sau. Chỉ có cả hai cùng nhau tạo thành thông tin đầy đủ ẩn.

Mong rằng sẽ giúp.

Ở đây, một câu trả lời không khoa học:

Bỏ đi trong lập trình là giả vờ bạn không quan tâm đến các chi tiết bây giờ, trong khi thực tế bạn làm và bạn nên quan tâm đến chúng mọi lúc. Về cơ bản là giả vờ.

Đối với tôi sự trừu tượng là thứ không tồn tại "theo nghĩa đen", nó giống như một ý tưởng. Nếu bạn diễn đạt nó bằng toán học, nó không còn trừu tượng nữa vì toán học là ngôn ngữ để diễn đạt những gì xảy ra trong não của bạn để não của người khác có thể hiểu được, vì vậy bạn không thể cấu trúc ý tưởng của mình, vì nếu bạn làm vậy, đó không phải là ý tưởng nữa: bạn sẽ cần hiểu làm thế nào một bộ não hoạt động để thể hiện một mô hình ý tưởng.

Trừu tượng là một cái gì đó cho phép bạn diễn giải thực tế thành một cái gì đó có thể độc lập với nó. Bạn có thể trừu tượng một bãi biển và một giấc mơ, nhưng bãi biển tồn tại nhưng giấc mơ thì không. Nhưng bạn có thể nói cả hai tồn tại, nhưng nó không đúng.

Điều khó nhất trong sự trừu tượng là tìm cách diễn đạt nó để người khác có thể hiểu nó để nó có thể biến thành hiện thực. Đó là công việc khó khăn nhất và nó thực sự không thể được thực hiện một mình: bạn phải phát minh ra một mô hình tương đối hoạt động theo ý tưởng của bạn và có thể được người khác hiểu.

Đối với tôi, sự trừu tượng trong ngôn ngữ máy tính nên được đặt tên là "toán học hóa" mô hình, đó là về việc tái sử dụng các ý tưởng có thể truyền đạt và đó là một hạn chế rất lớn so với những gì có thể đạt được một cách trừu tượng.

Nói một cách đơn giản, các nguyên tử nằm cạnh nhau, nhưng chúng không quan tâm. Một tập hợp lớn các phân tử được tổ chức thành một con người có thể hiểu rằng anh ta đang ở bên cạnh ai đó, nhưng không thể hiểu được, đó chỉ là cách các nguyên tử định vị bản thân thành một mô hình nào đó.

Một đối tượng được cai trị bởi một khái niệm, nói chung, không thể "hiểu" chính nó. Đó là lý do tại sao chúng ta cố gắng tin vào chúa và tại sao chúng ta khó hiểu về bộ não của mình.

Tôi có thể có huy chương của tôi bây giờ?

Câu hỏi thú vị. Tôi không biết về một định nghĩa trừu tượng duy nhất được coi là có thẩm quyền khi nói đến lập trình. Mặc dù những người khác đã cung cấp liên kết đến một số định nghĩa từ các nhánh khác nhau của lý thuyết hoặc toán học CS; Tôi thích nghĩ về nó theo cách tương tự như "giám sát", xem http://en.wikipedia.org/wiki/Supervenience

Khi chúng ta nói về sự trừu tượng trong lập trình, về cơ bản chúng ta đang so sánh hai mô tả của một hệ thống. Mã của bạn là một mô tả của một chương trình. Một bản tóm tắt mã của bạn cũng sẽ là một mô tả về chương trình đó nhưng ở mức "cao hơn". Tất nhiên, bạn có thể có mức độ trừu tượng cao hơn mức độ trừu tượng ban đầu của mình (ví dụ: mô tả chương trình trong kiến ​​trúc hệ thống cấp cao so với mô tả từ chương trình trong thiết kế chi tiết của nó).

Bây giờ những gì làm cho một mô tả "cấp cao hơn" so với mô tả khác. Chìa khóa là "nhiều khả năng thực hiện" - sự trừu tượng của bạn về chương trình có thể được nhận ra bằng nhiều cách bằng nhiều ngôn ngữ. Bây giờ bạn có thể nói rằng một người có thể tạo ra nhiều thiết kế cho một chương trình - cả hai người có thể tạo ra hai thiết kế cấp cao khác nhau, cả hai đều mô tả chính xác chương trình. Sự tương đương của các nhận thức làm cho sự khác biệt.

Khi so sánh các chương trình hoặc thiết kế, bạn phải làm như vậy theo cách cho phép bạn xác định các thuộc tính chính của mô tả ở cấp đó. Bạn có thể đi vào những cách phức tạp để nói một thiết kế tương đương với một thiết kế khác, nhưng cách dễ nhất để nghĩ về nó là - một chương trình nhị phân duy nhất có thể đáp ứng các ràng buộc của cả hai mô tả không?

Vậy điều gì làm cho một mức mô tả cao hơn mức khác? Giả sử chúng ta có một cấp độ mô tả A (ví dụ: tài liệu thiết kế) và một cấp độ mô tả B khác (ví dụ mã nguồn). A là mức cao hơn so với B vì nếu A1 và A2 là hai giới thiệu không tương đương ở mức A, sau đó ngộ của những người giới thiệu, B1 và B2 phải cũng là không tương đương ở mức B. Tuy nhiên, ngược lại không nhất thiết phải giữ đúng .

Vì vậy, nếu tôi không thể tạo ra một chương trình nhị phân duy nhất thỏa mãn hai tài liệu thiết kế riêng biệt (nghĩa là các ràng buộc của các thiết kế đó sẽ mâu thuẫn với nhau), thì mã nguồn thực hiện các thiết kế đó phải khác nhau. Nhưng mặt khác, nếu tôi lấy hai bộ mã nguồn không thể biên dịch thành cùng một chương trình nhị phân, thì vẫn có thể xảy ra trường hợp các nhị phân do biên dịch hai bộ mã nguồn đó đều thỏa mãn cùng một thiết kế tài liệu. Do đó, tài liệu thiết kế là một "sự trừu tượng" của mã nguồn.

Trừu tượng lập trình là trừu tượng được thực hiện bởi một người nào đó trên một yếu tố lập trình. Hãy nói rằng bạn biết cách tạo một Menu với các mục và công cụ. Sau đó, một người nào đó đã nhìn thấy đoạn mã và suy nghĩ đó, hey có thể hữu ích trong các loại cấu trúc giống như hireachy khác, và định nghĩa Mẫu thiết kế thành phần với sự trừu tượng của đoạn mã đầu tiên.

Các mẫu thiết kế hướng đối tượng là một ví dụ điển hình cho sự trừu tượng hóa và tôi không có nghĩa là triển khai thực sự mà là cách chúng ta nên tiếp cận một giải pháp.

Vì vậy, tóm lại, trừu tượng hóa lập trình là một cách tiếp cận cho phép chúng ta hiểu một vấn đề, nó là phương tiện để có được một cái gì đó nhưng nó không phải là thực tế