Các lớp học giúp bạn quản lý các ứng dụng lớn như thế nào?

Question

Điều này xuất hiện trong một cuộc trò chuyện tôi đã trực tuyến, và điều đó xảy ra với tôi rằng tôi không biết nó hoạt động như thế nào: Khá nhiều lập trình viên dường như chỉ là một thực tế, rõ ràng là các lớp học tính năng ngôn ngữ cần thiết để quản lý các dự án phần mềm khổng lồ.

Điều này không rõ ràng đối với tôi cách họ thực hiện việc này.

Câu hỏi của tôi đối với bạn là, làm sao bạn biết? Những biện pháp khách quan nào cho thấy rằng các lớp học tăng năng suất, tái sử dụng mã và giảm sự phức tạp của việc sản xuất chương trình? Những khía cạnh nào của lớp học khiến họ lý tưởng cho các nhóm lớn cộng tác trên?

Và bây giờ, có một câu hỏi tôi muốn hỏi, điều đó hơi khó thể hiện. Tôi xin lỗi nếu tôi hiểu sai và kết thúc khó hiểu hoặc tức giận bất kỳ ai:

Khách quan, cách bạn biết rằng việc sử dụng các lớp học không phải là nguyên nhân của ứng dụng bắt đầu lớn? Tức là, có thể một chương trình có hàm tương đương có thể được viết, với ít mã hơn, đủ nhỏ để không cần bất kỳ biện pháp đặc biệt nào để "quản lý" nó, sử dụng một số chiến lược sử dụng lại mã khác? (có rất nhiều lựa chọn, chẳng hạn như các mô hình lập trình chức năng, hoặc lập trình hướng khía cạnh).

Điều cuối cùng đó là thứ mà Steve Yegge đã gợi ý trên blog của mình. Nhưng tôi có vẻ hoài nghi về cả hai mặt của cuộc tranh luận, vì thiếu một dữ liệu khó khăn từ bất kỳ ai, và không đủ kinh nghiệm để đi đến kết luận của riêng tôi.

Bạn nghĩ sao?

chỉnh sửa: Đặc biệt tôi quan tâm đến lý do tại sao nhiều người lập trình nghĩ rằng kiểu thừa kế kiểu nguyên mẫu không phải là nhiệm vụ khi nói đến các ứng dụng lớn. Tôi xin lỗi về câu hỏi này là mơ hồ- đó là một sản phẩm của sự thiếu hiểu biết của tôi về chủ đề này.

edit2: có vẻ như có sự nhầm lẫn nào đó về ý nghĩa của việc lập trình hàm. (Tôi không nghĩ rằng bất kỳ phiên bản của VB đã từng hoạt động, chắc chắn không phải phiên bản cũ hơn). Vui lòng tham khảo bài viết wikipedia. http://en.wikipedia.org/wiki/Functional_programming

edit3: và để tôi nhấn mạnh rằng tôi đang tìm các biện pháp khách quan. Không phải ý kiến ​​chủ quan.

Answer 1

Lý thuyết đóng gói cung cấp một lý do khách quan vì sao các lớp học tốt hơn không có lớp nào cả.

Tổ chức tiêu chuẩn hóa quốc tế định nghĩa đóng gói là 'Thuộc tính mà thông tin chứa trong một đối tượng chỉ có thể truy cập thông qua tương tác tại các giao diện được hỗ trợ bởi đối tượng.'

Do đó, vì một số thông tin có thể truy cập được thông qua các giao diện này, một số thông tin phải được ẩn và không thể truy cập trong đối tượng. Tài sản trưng bày thông tin như vậy được gọi là ẩn thông tin, mà Parnas xác định bằng cách lập luận rằng các mô-đun nên được thiết kế để che giấu cả các quyết định và quyết định khó khăn có khả năng thay đổi.

Lưu ý rằng từ: thay đổi. Thông tin ẩn liên quan đến các sự kiện tiềm năng, chẳng hạn như việc thay đổi các quyết định thiết kế khó khăn trong tương lai.

Xem xét một lớp với hai phương pháp: phương thức a() là thông tin ẩn trong lớp và phương thức b() công khai và do đó có thể truy cập trực tiếp bởi các lớp khác.

Có một xác suất nhất định rằng thay đổi trong tương lai đối với phương thức a() sẽ yêu cầu thay đổi phương thức trong các lớp khác. Cũng có một xác suất nhất định rằng một sự thay đổi trong tương lai đối với phương thức b() sẽ đòi hỏi những thay đổi trong các phương thức trong các lớp khác. Xác suất thay đổi gợn như vậy sẽ xảy ra với phương thức a(), tuy nhiên, thường sẽ thấp hơn phương thức b() đơn giản vì phương thức b() có thể phụ thuộc vào nhiều lớp hơn.

Khả năng giảm tác động gợn sóng này là một lợi ích chính của việc đóng gói.

Xem xét số phụ thuộc tiềm năng tối đa của mã nguồn phụ thuộc (MPE - từ viết tắt là từ lý thuyết đồ thị) trong bất kỳ chương trình nào. Ngoại suy từ các định nghĩa trên, chúng tôi có thể nói rằng, với hai chương trình cung cấp chức năng giống hệt nhau cho người dùng, chương trình có MPE thấp nhất được đóng gói tốt hơn và chương trình được gói gọn hơn sẽ rẻ hơn để duy trì và phát triển, bởi vì chi phí sự thay đổi tiềm năng tối đa của nó sẽ thấp hơn sự thay đổi tiềm năng tối đa đối với systém ít được đóng gói tốt.

Hãy xem xét, hơn nữa, một ngôn ngữ chỉ có phương pháp và không có lớp học và do đó không có phương tiện ẩn thông tin phương pháp từ một khác. Giả sử chương trình của chúng tôi có 1000 phương pháp. MPE của chương trình này là gì?

Lý thuyết đóng gói cho chúng ta biết rằng, với hệ thống n nút công khai, MPE của hệ thống này là n (n-1). Do đó, MPE của 1000 phương pháp công khai của chúng tôi là 999.000.

Bây giờ, hãy chia tách systém thành hai lớp, mỗi lớp có 500 phương thức. Bây giờ chúng ta có các lớp, chúng ta có thể chọn để có một số phương thức công khai và một số phương thức riêng. Đây sẽ là trường hợp trừ khi mọi phương pháp thực sự phụ thuộc vào mọi phương thức khác (điều này không chắc chắn). Hãy nói rằng 50 phương pháp trong mỗi lớp là công khai. MPE của systém sẽ là gì?

Lý thuyết đóng gói cho chúng ta biết: n ((n/r) -1 + (r-1) p) trong đó r là số lớp, và p là số phương thức công khai cho mỗi lớp. Điều này sẽ cung cấp cho hai lớp của chúng tôi systém một MPE của 499.000. Do đó, chi phí tiềm năng tối đa của một sự thay đổi trong systém hai lớp này đã thấp hơn đáng kể so với systém không bị đóng gói.

Giả sử bạn phá vỡ tâm trạng của mình thành 3 lớp, mỗi lớp có 333 lớp (tốt, một lớp sẽ có 334), và một lần nữa với 50 phương thức công khai. MPE là gì? Sử dụng phương trình trên một lần nữa, MPE sẽ là khoảng 482.000.

Nếu systém được chia thành 4 lớp với 250 phương thức, MPE sẽ là 449.000.

Nếu có vẻ như việc tăng số lượng lớp học trong tâm trạng của chúng tôi sẽ luôn giảm MPE, nhưng điều này không phải như vậy. Lý thuyết đóng gói cho thấy số lượng các lớp mà trong đó systém nên được phân tách để giảm thiểu MPE là: r = sqrt (n/p), cho systém của chúng ta thực sự là 4. Một systém với 6 lớp, ví dụ, sẽ có một MPE trong số 465.666.

Answer 2

Tôi không có ý nghĩa gì đối với bất kỳ mô hình lập trình nào, nhưng tôi đã hoạt động trong một thời trang OO một thời gian.

Cá nhân, tôi đã có rất nhiều 'a-HA!' những khoảnh khắc mà các lớp học đã trực tiếp giúp tôi hiểu miền tôi đang làm việc tốt hơn. Đáng chú ý nhất, trong trường hợp có sự nhầm lẫn về lý do tại sao hệ thống bị trục trặc hoặc hệ thống phải làm gì, các lớp học thường buộc tôi phải suy nghĩ về những gì mà toàn bộ phần rời rạc này nên làm, và nhiều hơn nữa thường không dẫn đến tái cấu trúc các lớp/phương pháp trong tầm tay.

Tóm lại, đóng gói thực sự làm cho tôi trở thành một người hạnh phúc hơn. ;)

Hy vọng điều đó sẽ hữu ích.

Answer 3

Tôi thích các lớp học để tôi có thể phân chia một vấn đề lớn thành các phần có thể quản lý được có thể kiểm chứng dưới dạng đơn vị riêng lẻ. IMHO, sử dụng lại mã được đánh giá cao - Tôi hầu như không thấy nó xảy ra ở nơi tôi làm việc. Với tôi, những gì tôi nhận được nhiều nhất từ ​​OO tốt là khả năng kiểm tra tốt.

Điểm cực đoan khác là sử dụng một loạt các biến toàn cục và mứt tất cả logic của bạn trong public static void main (hoặc Page_Load trong ASP.NET) và gọi các phương thức tĩnh gọi các phương thức tĩnh khác và ... (Tôi thấy chóng mặt kết thúc câu cuối cùng.)

Điều duy nhất có thể phá vỡ suy nghĩ OO của tôi là nếu tôi đang làm việc với một ngôn ngữ chức năng thuần túy, đó là điều mà tôi chưa từng nghĩ đến từ đại học.

Answer 4

Đây là một câu hỏi rất hay. Tổ chức mã thành các lớp là một cách để một nhóm phát triển tạo ra các mô-đun nhỏ, có thể tái sử dụng. Ngoài ra, các mô-đun này có giao diện biểu cảm và giới hạn chỉ thể hiện những gì mà lớp đó có khả năng và không phải là nó hoạt động như thế nào. Mỗi lớp là trực giao với những người khác và do đó rất có thể kiểm tra và mô-đun trong trường hợp lỗi.

Bây giờ những gì tôi vừa mô tả là một cảnh lạ từ một thế giới hoàn hảo. Nhưng bất kỳ nhà phát triển giỏi nào làm công việc OOP đều phải phấn đấu cho một thứ như thế này.

OOP là sự thừa nhận rằng chúng tôi, các nhà phát triển, đơn giản là con người và không thể hiểu toàn bộ hệ thống cùng một lúc. Vì vậy, chúng tôi chia hệ thống thành các phần nhỏ có thể tái sử dụng và tập trung vào những phần đó.

Lấy số điện thoại mười chữ số ở Hoa Kỳ làm ví dụ. Thật khó để nhớ một số có mười chữ số trong đầu bạn vì vậy chúng tôi làm những gì các nhà tâm lý học gọi là "chunking". Điều này có nghĩa là chúng ta phá vỡ những con số thành những phần mà chúng ta có thể nhớ rõ hơn.

Vì vậy, 1234567890 trở thành 123-456-7890. May mắn thay cho chúng tôi, các công ty điện thoại cũng phá vỡ những con số này xuống theo cùng một cách và gán ý nghĩa của khối. 123 là mã vùng, 456 là tiền tố và 7890 là số dòng. Mỗi khối này giống như một lớp, tất cả chúng đều có trách nhiệm cá nhân, định dạng và ý nghĩa.

Vì vậy, trong kết luận điều tốt nhất tôi có thể nói là OOP cho phép chúng tôi xây dựng các hệ thống lớn, có khả năng mở rộng có chức năng tập trung và đóng gói. Nó cho phép chúng ta không phải nhìn thấy bức tranh lớn mọi lúc và có thể tập trung vào làm một việc và làm tốt nó.

Answer 5

Hai thứ.

Đầu tiên là ý tưởng rằng một lớp là một thực thể tên miền opaque. Khi thực hiện chính xác, các chương trình hướng đối tượng giới thiệu một lớp trừu tượng: ở lớp cao nhất tiếp theo, bạn sắp xếp các đối tượng để làm những gì bạn muốn, thay vì xử lý các chi tiết. Bạn không cần phải biết làm thế nào các đối tượng và các lớp học làm việc: chỉ những gì họ làm. Đây là một loại thông tin ẩn, và nó làm giảm sự phức tạp mà một đội phải giữ trong đầu của họ khi họ làm việc. Thứ hai là lập trình OO cho phép sử dụng lại một loại: bạn có thể định nghĩa các lớp ghi đè các hành vi nhất định trong các lớp khác (thừa kế), hoặc các lớp có các cá thể bao gồm các lớp khác, sử dụng chúng để đạt được mục đích của chúng. đóng gói và thành phần).

Chính xác sử dụng kỹ thuật OO có thể giảm số lượng mã bạn cần quản lý và giảm số lượng bạn cần lưu ý khi bạn làm việc hoặc duy trì hệ thống. Trong thực tế, cách tiếp cận này không phải lúc nào cũng hiệu quả.

Answer 6

Tôi nghĩ rằng các lớp học có thể giúp, bởi vì chúng tương ứng với khái niệm nhận thức rất chung của categorization, và do đó có thể giúp mô tả các ứng dụng lớn một cách tự nhiên.

Answer 7

Khách quan, làm thế nào để bạn biết rằng việc sử dụng các lớp học không phải là nguyên nhân của ứng dụng quá lớn để bắt đầu?

Thực hiện bất kỳ chương trình/ứng dụng lớn nào không được viết bằng ngôn ngữ OO (ví dụ: C, COBOL, SQL thuần túy) và bạn sẽ có thể chứng kiến ​​kích thước mã đó không trực tiếp quy cho mô hình ngôn ngữ. Đối với mỗi số các thành phần C# hoặc Java có thể tái sử dụng, được tinh chỉnh cao, có thể tái sử dụng, cũng có một số lượng bằng nhau các DLL C được tái thiết kế, được tinh chỉnh cao, có thể tái sử dụng. Ngược lại, có số lượng bằng nhau của mã khủng khiếp, cồng kềnh.

Vấn đề là, các lập trình viên giỏi có thể tinh chỉnh thiết kế hệ thống của họ bất kể ngôn ngữ/nền tảng.

Liên quan đến OOP, ít nhất là đối với tôi, nó mang lại cho bảng một "tiềm năng" - một cái nhìn của thế giới lập trình abit gần hơn cho thế giới thực của chúng ta. Chúng ta đều biết thế giới của chúng ta và vũ trụ vật chất này có đầy đủ các vật thể gồm các vật thể nhỏ hơn. Tiếp tục phóng to từ hệ thống sao galatical xuống phân tử, nguyên tử, và các hạt phụ nguyên tử, thật sự ngạc nhiên khi vật chất khác nhau được tạo ra từ các hạt nhỏ xíu được kết hợp trong các mẫu khác nhau như thế nào. Hãy nhìn vào sinh học của chính chúng ta, đôi khi đôi khi nghĩ đến 60% cơ thể của chúng ta thực sự là nước khi bị phá vỡ tốt nhất. Tuy nhiên, hãy nhìn vào tất cả các hệ thống và cơ quan khác nhau tại chỗ đốt bằng hóa học để giữ cho chúng ta chạy và sống.

Khi chúng ta học cách hiểu sự đơn giản (oh thực sự ... ha ha) của các khối xây dựng tạo thành hệ thống thực tế mà chúng ta thấy trong bản chất hàng ngày, chúng ta sẽ có thể hiểu rằng thiết kế và xây dựng các hệ thống cực kỳ phức tạp hoặc phức tạp nên bắt đầu với các thành phần nhỏ làm rất ít. Và bằng cách từ từ kết hợp và chia lưới chúng lại thành các thành phần lớn hơn, chúng ta có thể thu được nhiều chức năng và khả năng hơn. Cho đến khi chúng tôi đạt được hệ thống mong muốn chúng tôi hình dung.

Việc sử dụng các lớp học (đúng) là để phá vỡ hệ thống thành tốt nhất. Có thể. Vì vậy, bạn có thể nhìn vào một cái gì đó tại một thời điểm và một mức độ trừu tượng cụ thể và không bị choáng ngợp bởi các mục đích và logic mà không phải là đối phó với khu vực hiện tại của bạn quan tâm. Bất cứ khi nào bạn thiết kế một hệ thống, hãy suy nghĩ về giải phẫu của riêng bạn; hãy suy nghĩ cách bạn sẽ thiết kế cơ thể con người. Bất cứ khi nào bạn thiết kế một hệ thống, hãy suy nghĩ về việc bắt đầu một công ty mới; các bộ phận chính, các phòng ban bạn cần để điều hành doanh nghiệp là gì. Ai là loại nhân viên cần thiết để điều hành các phòng ban đó. Các thiết bị khác nhau mà họ cần phải sử dụng và tương tác với để thực hiện công việc của họ. Làm thế nào để bạn phá vỡ các hoạt động kinh doanh thành tốt nhất của nó để cho phép bản thân nó hiểu nó tốt hơn?

Khi bạn hiểu nguyên tắc cơ bản là một số đối tượng chỉ đơn giản là tạo thành các đối tượng nhỏ hơn, bạn sẽ được trên con đường của bạn để tạo ra các tế bào hoặc phân tử có thể tái sử dụng cao.

Answer 8

Các lớp học hữu ích nhất đối với tôi theo khía cạnh mà tôi có thể làm việc trên một khía cạnh nhỏ của một dự án phức tạp cùng một lúc. Việc có thể tách rời một khía cạnh của mã từ dự án lớn là rất hữu ích để bạn không bị quá tải. Cuối cùng, sự gắn kết giữa các lớp đó có thể cung cấp cho bạn một cái nhìn tổng quát về cách một chương trình hoạt động mà không phải đối phó với các bộ phận bên trong. Theo quan điểm của tôi, có thể dễ dàng hơn khi xem xét sơ đồ lớp UML và tìm ra cách mọi thứ được đặt ra ngoài việc xem xét danh sách các hàm, theo ý kiến ​​của tôi.

Answer 9

Tôi nghĩ rằng bằng cách nói các lớp, bạn nên có nghĩa là các đối tượng. Các lớp học không là gì ngoài nơi bạn có thể đặt vào các vật thể của mình. Mô hình OOP rất thành công vì một lý do. Một khi bạn đã có 'aha!' thời điểm khi bạn nghĩ rằng cuối cùng bạn đã hiểu khái niệm về OOP, bạn có thể bắt đầu lập trình theo cách được tổ chức nhiều hơn. Tôi đã lập trình trong Visual Basic 3 trong một thời gian dài, vì vậy tôi đã có rất nhiều kinh nghiệm với lập trình hàm, sau đó đến VB5 và khám phá các đối tượng là một cứu trợ to lớn bởi vì tôi có thể liên kết các thực thể thế giới vào mã của tôi và nó đã giúp ích rất nhiều.

Đó là toàn bộ điểm của nó, tạo lại các thực thể trong thế giới thực trong mã của bạn. Nó làm cho việc đọc và làm việc dễ dàng hơn khiến bạn có thể nhặt một thứ gì đó và làm việc với nó, hoặc làm những thứ với nó.

Answer 10

Có thể quá kỹ sư một vấn đề đơn giản bằng cách làm cho nó không cần thiết phức tạp (OO tất cả các con đường xuống). Tuy nhiên, đối với bất kỳ vấn đề đủ lớn nào, tôi không nghĩ rằng mô hình OO có thể xảy ra là nguyên nhân khiến nó trở nên lớn ngay từ đầu. Lấy một hệ điều hành chẳng hạn, thật khó để tưởng tượng nó dễ bảo trì (mã khôn ngoan) nếu nó không được viết theo cách hướng đối tượng.

Answer 11

Nếu bạn có một loạt chức năng "trần" trong một ứng dụng lớn, thật khó để thực hiện các thay đổi đối với các chức năng đó.

• khó nhìn thấy ai đang sử dụng các chức năng ("nếu tôi thay đổi điều này, người nào nó ảnh hưởng?")
• khó để thay đổi các chức năng mà không phá vỡ mã của người khác.

Nếu bạn bao bọc các chức năng trong lớp, bạn sẽ giúp cô lập phạm vi của mã. Nó không phải là một viên đạn ma thuật, nhưng nó giúp.