Ưu điểm và nhược điểm của cấu trúc tất cả mã thông qua các lớp và biên dịch thành các lớp (như Java)

Chỉnh sửa: ngôn ngữ của tôi cho phép nhiều kế thừa, không giống như Java.

Tôi đã bắt đầu thiết kế và phát triển ngôn ngữ lập trình của riêng mình cho các mục đích giáo dục, giải trí và có khả năng hữu ích.

Lúc đầu, tôi đã quyết định dựa trên Java.

Điều này ngụ ý rằng tất cả các mã sẽ được viết dưới dạng các lớp và mã đó biên dịch thành các lớp, được VM tải.

Tuy nhiên, tôi đã loại trừ các tính năng như giao diện và các lớp trừu tượng, vì tôi thấy không cần chúng. Họ dường như đang thực thi một mô hình, và tôi muốn ngôn ngữ của tôi không làm điều đó. Tôi muốn giữ các lớp làm đơn vị biên dịch, bởi vì nó có vẻ thuận tiện để thực hiện, quen thuộc và tôi chỉ thích ý tưởng này.

Sau đó, tôi nhận thấy rằng về cơ bản tôi còn lại với một hệ thống mô-đun, trong đó các lớp có thể được sử dụng làm "không gian tên", cung cấp các hằng và hàm bằng cách sử dụng lệnh statichoặc làm mẫu cho các đối tượng cần được khởi tạo (mục đích "thực tế" của các lớp trong các ngôn ngữ khác).

Bây giờ tôi đang tự hỏi: những mặt trái và mặt trái của việc có các lớp làm đơn vị biên dịch là gì?

Ngoài ra, bất kỳ bình luận chung về thiết kế của tôi sẽ được nhiều đánh giá cao. Một bài viết thông tin về ngôn ngữ của tôi có thể được tìm thấy ở đây: http://www.yannbane.com/2012/12/kava.html .

— jcora
nguồn

Nếu các lớp cũng bao gồm các không gian tên phân định tất cả các định danh trong lớp, thì bạn có một đơn vị biên dịch hoàn toàn khép kín. Lớp đó có thể được biên dịch thành công, với điều kiện tất cả các phụ thuộc cho các lớp khác có thể được thỏa mãn bằng cách biên dịch hoặc bằng cách tham chiếu đến một lớp được biên dịch trong một cụm. Nguyên tử như vậy nên có lợi thế rõ ràng.

— Robert Harvey

Lưu ý bên lề: Nếu bạn loại bỏ các lớp và giao diện trừu tượng, bạn buộc mọi người phải sử dụng tính kế thừa cho phân nhóm và đa hình. Đó là ràng buộc để sản xuất mã khủng khiếp. Ngoài ra, trừ khi bạn thêm nhiều kế thừa (và xử lý các vấn đề liên quan), nó sẽ bị hạn chế đáng kinh ngạc.

@delnan: Trên thực tế, bạn vẫn có thể sử dụng bố cục để xây dựng chức năng.

— Robert Harvey

@RobertHarvey Tôi giả sử bạn đang nói về những hạn chế do thiếu nhiều kế thừa. Vâng, người ta có thể mô phỏng nó với đủ thành phần, nhưng tôi khó có thể coi nó là chấp nhận được. Ví dụ, một đối tượng thường triển khai hai giao diện sẽ phải được triển khai hai lần, trong các lớp con của các lớp cơ sở riêng biệt (và trong khi cả hai triển khai có thể ủy quyền cho một lớp chung, đó vẫn là một đoạn mã bổ sung và bạn không thể dễ dàng chuyển một thể hiện của một thành một thể hiện của cái khác).

@delnan: Có gì sai khi sử dụng tính kế thừa cho phân nhóm và đa hình? Đó là sự kế thừa dành cho ...

— Mason Wheeler

Câu trả lời:

lợi ích của việc có các lớp là đơn vị biên dịch là gì?

Nó có thể làm giảm sự phức tạp của ngôn ngữ. Không cần các cấu trúc khác nhau, mọi thứ đều được đối xử như nhau. Trong một số thiết kế nhất định (mặc dù không phải của bạn), bạn được hưởng lợi từ việc không có thống kê và các vấn đề thiết kế mà họ có xu hướng gặp phải (vấn đề đặt hàng khởi tạo, hạn chế đồng thời, lúng túng với các loại chung / loại). Nó cũng cho phép một số lợi ích của khái niệm mô-đun như các trường hợp mô-đun bị cô lập để tạo hộp cát hoặc song song; và gõ mô-đun nơi phụ thuộc phù hợp với một số giao diện và toàn bộ giá trị thực hiện mô-đun có thể được khởi tạo và bỏ vào.

Điều đó nói rằng, khái niệm có xu hướng có nhiều vấn đề hơn không. Trên thực tế, bạn không thể đối xử với mọi thứ như nhau, vì các lớp 'cấp cao nhất' cần các quy tắc đặc biệt như có một hàm tạo mặc định (nếu không bạn gặp phải các vấn đề kỳ lạ khi xoay chúng). Tính mô đun của các đơn vị biên dịch cũng có xu hướng trở nên thực sự khó xử. Làm thế nào để một lớp thậm chí tham chiếu người khác khi họ chỉ là các lớp? Làm thế nào là những phụ thuộc được xử lý, và làm thế nào để bạn xác định thứ tự chính xác để quay vòng các lớp? Làm thế nào để bạn chắc chắn rằng các tham chiếu lớp trùng lặp được sử dụng lại bởi các phần khác nhau của ứng dụng (hoặc làm thế nào để bạn xử lý các trường hợp trùng lặp nếu đó là ngữ nghĩa bạn muốn)?

Nhìn vào nó, tôi gặp rất nhiều vấn đề với sự phụ thuộc, sắp xếp mọi thứ đúng cách và các mối quan tâm khởi tạo. Cuối cùng, bạn gặp phải các vấn đề khiến 'các lớp cấp cao' trở nên đặc biệt và nhiều hạn chế để khiến chúng hoạt động và cuối cùng định hình chúng thành các không gian tên đơn giản.

— Telastyn
nguồn

Tôi có kế hoạch duy nhất để có một lớp cấp cao nhất duy nhất, Object. Tôi nhận ra rằng có lẽ tôi sẽ cần một số hành vi đặc biệt cho nó, nhưng miễn là trường hợp cá biệt, tôi ổn với điều đó. Tôi không tin rằng tôi sẽ có bất kỳ vấn đề phụ thuộc mặc dù. Có một tập hợp các lớp được tải khi VM khởi động, một số trong số chúng được triển khai nguyên bản (lớp Hệ thống), nhưng tất cả chúng đều kế thừa từ Object. Khi mọi thứ đã được tải, KVM sẽ tải lớp mà nó được hướng dẫn để tải và xử lý các phụ thuộc. Tuy nhiên, tôi quan tâm, những vấn đề nào làm thống kê giới thiệu?

— jcora

@yannbane - Ý tôi không phải object, ý tôi là các lớp đang hành xử giống như các mô-đun chứ không phải là các lớp bên trong không nhất thiết phải công khai bên ngoài đơn vị biên dịch của chúng. 'Làm việc ra các phần phụ thuộc' biến thành một tổ ong khổng lồ trong các chi tiết nếu bạn muốn bất kỳ loại hành vi kiểu DLL nào; ymmv. Đối với tĩnh .

— Telastyn

Hành vi giống như mô-đun đó sẽ đạt được thông qua việc sử dụng các phương thức / biến tĩnh, phải không? Có phải là xấu, thay vì tạo một lớp có thể được khởi tạo, tạo một lớp chỉ có các thành viên và phương thức tĩnh? Tôi đã thấy bài viết đó, tuy nhiên, tôi không nghĩ nó áp dụng cho các thành viên tĩnh không đổi , cũng như các phương thức tĩnh. Ví dụ, tôi thấy không có gì sai khi tạo một Mathlớp, đây thực sự là một mô-đun với các phương thức tĩnh và một thành viên kép tĩnh không đổi được gọi Pi.

— jcora

@yannbane - Không, không hẳn. Các mô-đun là mô-đun vì chúng có thể khởi động được. Nếu không, bạn chỉ có không gian tên kiểu C ++. Khi bạn giới hạn các lớp cấp cao nhất của mình là các không gian tên kiểu C ++, chúng không thực sự là các lớp nữa.

— Telastyn

Hừm, tôi vẫn ổn và không thực sự thấy vấn đề với việc tạo các mô-đun với các lớp. Và vâng, các mô-đun hoạt động như các không gian tên, đặc biệt là các mô-đun Python.

— jcora

Thay vì trả lời câu hỏi này, tôi sẽ lên một cấp và đề nghị nghiên cứu MIT OpenC thuyếtWare , đặc biệt là 6.035 (Kỹ thuật ngôn ngữ máy tính). Điều này sẽ giải thích toàn bộ vấn đề, để bạn không bị cám dỗ đặt câu hỏi như thế này một lần nữa.

Kỹ thuật ngôn ngữ máy tính

Điều kiện tiên quyết duy nhất là Java.

http://ocw.mit.edu/cifts/electrical-engineering-and-computer-science/6-035-computer-lingu-engineering-spring-2010/lecture-notes/

Mô tả khóa học

Khóa học này phân tích các vấn đề liên quan đến việc thực hiện các ngôn ngữ lập trình cấp cao hơn. Các chủ đề bao gồm: các khái niệm cơ bản, chức năng và cấu trúc của trình biên dịch, sự tương tác của lý thuyết và thực hành và sử dụng các công cụ trong việc xây dựng phần mềm. Khóa học bao gồm một dự án nhiều người về thiết kế và thực hiện trình biên dịch.

— gặm
nguồn