Objective-C so với C # như thế nào? [đóng cửa]

Gần đây tôi đã mua một máy Mac và sử dụng nó chủ yếu để phát triển C # trong VMWare Fusion. Với tất cả các ứng dụng Mac tuyệt vời xung quanh, tôi bắt đầu nghĩ về Xcode ẩn nấp chỉ bằng một cú nhấp chuột cài đặt và tìm hiểu Objective-C.

Cú pháp giữa hai ngôn ngữ trông rất khác nhau, có lẽ vì Objective-C có nguồn gốc từ C và C # có nguồn gốc từ Java / C ++. Nhưng các cú pháp khác nhau có thể được học để điều đó ổn.

Mối quan tâm chính của tôi là làm việc với ngôn ngữ và liệu nó có giúp tạo ra mã có cấu trúc tốt, dễ đọc và trang nhã hay không. Tôi thực sự thích các tính năng như LINQ và var trong C # và tự hỏi liệu có các tính năng tương đương hoặc tốt hơn / khác trong Objective-C hay không.

Tôi sẽ bỏ lỡ những tính năng ngôn ngữ nào khi phát triển với Objective-C? Tôi sẽ đạt được những tính năng nào?

Chỉnh sửa: Các so sánh khung là hữu ích và thú vị nhưng so sánh ngôn ngữ là những gì câu hỏi này thực sự đặt ra (một phần lỗi của tôi khi gắn thẻ ban đầu .net). Có lẽ cả Cocoa và .NET đều là những framework rất phong phú theo đúng nghĩa của chúng và cả hai đều có mục đích của chúng, một nhắm mục tiêu Mac OS X và Windows còn lại.

Cảm ơn bạn đã suy nghĩ kỹ lưỡng và quan điểm cân bằng hợp lý cho đến nay!

Không có ngôn ngữ nào là hoàn hảo cho tất cả các nhiệm vụ và Objective-C cũng không ngoại lệ, nhưng có một số tính năng rất cụ thể. Giống như việc sử dụng LINQvà var(mà tôi không biết về sự thay thế trực tiếp), một số trong số này hoàn toàn liên quan đến ngôn ngữ và một số khác liên quan đến khuôn khổ.

( LƯU Ý: Cũng như C # được kết hợp chặt chẽ với .NET, Objective-C được kết hợp chặt chẽ với Cocoa. Do đó, một số điểm của tôi có vẻ không liên quan đến Objective-C, nhưng Objective-C không có Cocoa cũng giống như C # không có .NET / WPF / LINQ, chạy dưới Mono, v.v. Đó không phải là cách mọi thứ thường được thực hiện.)

Tôi sẽ không giả vờ giải thích đầy đủ về sự khác biệt, ưu và nhược điểm, nhưng đây là một số điều đáng chú ý.

• Một trong những phần tốt nhất của Objective-C là bản chất động - thay vì gọi các phương thức, bạn gửi tin nhắn, mà thời gian chạy định tuyến động. Được kết hợp (một cách thận trọng) với tính năng nhập động, điều này có thể làm cho rất nhiều mẫu mạnh mẽ đơn giản hơn hoặc thậm chí là tầm thường để triển khai.

• Là một tập hợp siêu nghiêm ngặt của C, Objective-C tin tưởng rằng bạn biết mình đang làm gì. Không giống như cách tiếp cận được quản lý và / hoặc an toàn kiểu của các ngôn ngữ như C # và Java, Objective-C cho phép bạn làm những gì bạn muốn và trải qua những hậu quả. Rõ ràng là điều này đôi khi có thể nguy hiểm, nhưng thực tế là ngôn ngữ không chủ động ngăn cản bạn làm hầu hết mọi thứ là khá mạnh mẽ. ( CHỈNH SỬA: Tôi nên làm rõ rằng C # cũng có các tính năng và chức năng "không an toàn", nhưng hành vi mặc định của chúng là mã được quản lý, bạn phải chọn không tham gia một cách rõ ràng. Để so sánh, Java chỉ cho phép mã an toàn kiểu chữ và không bao giờ để lộ các con trỏ thô trong theo cách mà C và những người khác làm.)

• Danh mục (thêm / sửa đổi các phương thức trên một lớp mà không cần phân lớp hoặc có quyền truy cập vào nguồn) là một con dao hai lưỡi tuyệt vời. Nó có thể đơn giản hóa rất nhiều hệ thống phân cấp kế thừa và loại bỏ mã, nhưng nếu bạn làm điều gì đó kỳ lạ, đôi khi kết quả có thể gây khó hiểu.

• Cocoa làm cho việc tạo các ứng dụng GUI đơn giản hơn nhiều theo nhiều cách, nhưng bạn phải xoay sở với mô hình. Thiết kế MVC phổ biến trong Cocoa và các mẫu như đại biểu, thông báo và ứng dụng GUI đa luồng rất phù hợp với Objective-C.

• Các ràng buộc ca cao và quan sát giá trị khóa có thể loại bỏ hàng tấn mã keo và các khuôn khổ ca cao tận dụng điều này một cách rộng rãi. Điều phối động của Objective-C hoạt động song song với điều này, vì vậy loại đối tượng không quan trọng miễn là nó tuân thủ khóa-giá trị.

• Bạn có thể sẽ bỏ lỡ các khái niệm chung và không gian tên, và chúng có những lợi ích của chúng, nhưng trong tư duy và mô hình Objective-C, chúng sẽ là những thứ tốt đẹp hơn là cần thiết. (Chung chung là tất cả về an toàn kiểu và tránh truyền, nhưng nhập động trong Objective-C làm cho điều này về cơ bản không phải là vấn đề. Không gian tên sẽ tốt nếu được thực hiện tốt, nhưng nó đủ đơn giản để tránh xung đột mà chi phí được cho là lớn hơn lợi ích, đặc biệt cho mã kế thừa.)

• Đối với đồng thời, Blocks (một tính năng ngôn ngữ mới trong Snow Leopard và được triển khai trong điểm số của API cacao) cực kỳ hữu ích. Một vài dòng (thường được kết hợp với Grand Central Dispatch, là một phần của libsystem trên 10.6) có thể loại bỏ phần soạn sẵn quan trọng của các hàm gọi lại, ngữ cảnh, v.v. (Các khối cũng có thể được sử dụng trong C và C ++ và chắc chắn có thể được thêm vào C #, Điều đó sẽ thật tuyệt vời.) NSOperationQueue cũng là một cách rất tiện lợi để thêm đồng thời vào mã của riêng bạn, bằng cách gửi các lớp con NSOperation tùy chỉnh hoặc các khối ẩn danh mà GCD tự động thực thi trên một hoặc nhiều luồng khác nhau cho bạn.

Tôi đã lập trình bằng C, C ++ và C # được hơn 20 năm, lần đầu tiên bắt đầu vào năm 1990. Tôi vừa quyết định xem xét sự phát triển của iPhone và Xcode và Objective-C. Ôi trời ơi ... tất cả những lời phàn nàn về Microsoft mà tôi nhận lại, giờ tôi mới nhận ra rằng những thứ code tồi tệ đến mức nào. Objective-C quá phức tạp so với những gì C # làm. Tôi đã bị hỏng với C # và bây giờ tôi đánh giá cao tất cả công sức mà Microsoft đã bỏ ra. Chỉ đọc Objective-C với phương thức gọi là rất khó đọc. C # là thanh lịch trong điều này. Đó chỉ là ý kiến ​​của tôi, tôi hy vọng rằng ngôn ngữ phát triển của Apple cũng tốt như các sản phẩm của Apple, nhưng tôi yêu quý, chúng có rất nhiều điều để học hỏi từ Microsoft. Không có câu hỏi ứng dụng C # .NET Tôi có thể tải ứng dụng lên và chạy nhanh hơn nhiều lần so với XCode Objective-C. Apple chắc chắn nên lấy một phần trong cuốn sách của Microsoft ở đây và sau đó chúng tôi sẽ có một môi trường hoàn hảo. :-)

Không có đánh giá kỹ thuật nào ở đây, nhưng tôi chỉ thấy Objective-C kém dễ đọc hơn nhiều. Với ví dụ mà Cinder6 cung cấp cho bạn:

C #

List<string> strings = new List<string>();
strings.Add("xyzzy");                  // takes only strings
strings.Add(15);                       // compiler error
string x = strings[0];                 // guaranteed to be a string
strings.RemoveAt(0);                   // or non-existant (yielding an exception)

Objective-C

NSMutableArray *strings = [NSMutableArray array];
[strings addObject:@"xyzzy"];
[strings addObject:@15];
NSString *x = strings[0];
[strings removeObjectAtIndex:0];

Nó trông thật kinh khủng. Tôi thậm chí đã thử đọc 2 cuốn sách trên đó, họ đã đánh mất tôi từ rất sớm, và thông thường tôi không hiểu được điều đó với sách / ngôn ngữ lập trình.

Tôi rất vui vì chúng tôi có Mono cho Mac OS, vì nếu tôi phải dựa vào Apple để tạo cho tôi một môi trường phát triển tốt ...

Quản lý bộ nhớ thủ công là thứ mà những người mới bắt đầu làm quen với Objective-C dường như gặp nhiều vấn đề nhất, chủ yếu là vì họ nghĩ rằng nó phức tạp hơn thực tế.

Mục tiêu-C và Ca cao theo phần mở rộng dựa trên các công ước về thực thi; biết và tuân theo một bộ quy tắc rất nhỏ và đổi lại bạn nhận được rất nhiều miễn phí nhờ thời gian chạy năng động.

Quy tắc không đúng 100%, nhưng đủ tốt cho hàng ngày là:

• Mọi lệnh gọi đến allocphải được khớp với một releaseở cuối phạm vi hiện tại.
• Nếu giá trị trả về cho phương thức của bạn đã được lấy trước allocthì nó phải được trả về return [value autorelease];thay vì được so khớp bởi a release.
• Sử dụng thuộc tính, và không có quy tắc ba.

Sau đây là lời giải thích dài hơn.

Quản lý bộ nhớ dựa trên quyền sở hữu; chỉ chủ sở hữu của một cá thể đối tượng mới được giải phóng đối tượng, những người khác luôn không làm gì cả. Điều này có nghĩa là trong 95% tất cả các mã bạn xử lý Objective-C như thể nó được thu gom.

Vậy 5% còn lại thì sao? Bạn có ba phương thức để tìm, bất kỳ cá thể đối tượng nào nhận được từ phương thức này đều thuộc sở hữu của phạm vi phương thức hiện tại :

• alloc
• Bất kỳ phương thức nào bắt đầu bằng từ mới , chẳng hạn như newhoặc newService.
• Bất kỳ phương thức nào có chứa bản sao từ, chẳng hạn như copyvà mutableCopy.

Phương thức có ba tùy chọn khả thi về việc phải làm gì với các cá thể đối tượng thuộc sở hữu của nó trước khi thoát:

• Giải phóng nó bằng cách sử dụng releasenếu nó không còn cần thiết.
• Cấp quyền sở hữu cho một trường (biến phiên bản) hoặc một biến toàn cục bằng cách chỉ định nó.
• Từ bỏ quyền sở hữu nhưng cho người khác cơ hội nắm quyền sở hữu trước khi phiên bản biến mất bằng cách gọi autorelease.

Vậy khi nào bạn nên chủ động giành quyền sở hữu bằng cách gọi điện retain? Hai trường hợp:

• Khi gán các trường trong trình khởi tạo của bạn.
• Khi thực hiện thủ công phương pháp setter.

Chắc chắn, nếu mọi thứ bạn thấy trong cuộc sống của mình là Objective C, thì cú pháp của nó giống như duy nhất có thể. Chúng tôi có thể gọi bạn là "trinh nữ lập trình".

Nhưng vì rất nhiều mã được viết bằng C, C ++, Java, JavaScript, Pascal và các ngôn ngữ khác, bạn sẽ thấy ObjectiveC khác với tất cả chúng, nhưng không phải theo cách tốt. Họ có lý do cho điều này? Hãy xem các ngôn ngữ phổ biến khác:

C ++ đã thêm rất nhiều tính năng bổ sung vào C, nhưng nó chỉ thay đổi cú pháp ban đầu khi cần thiết.

C # đã thêm rất nhiều tính năng bổ sung so với C ++ nhưng nó chỉ thay đổi những thứ xấu xí trong C ++ (như loại bỏ "::" khỏi giao diện).

Java đã thay đổi rất nhiều thứ, nhưng nó vẫn giữ nguyên cú pháp quen thuộc ngoại trừ những phần cần thay đổi.

JavaScript là một ngôn ngữ hoàn toàn động có thể làm được nhiều điều mà ObjectiveC không thể. Tuy nhiên, những người tạo ra nó đã không phát minh ra một cách mới để gọi các phương thức và truyền các tham số chỉ để khác biệt với phần còn lại của thế giới.

Visual Basic có thể truyền các tham số không theo thứ tự, giống như ObjectiveC. Bạn có thể đặt tên cho các tham số, nhưng bạn cũng có thể chuyển chúng theo cách thông thường. Bất cứ điều gì bạn sử dụng, đó là cách phân cách bằng dấu phẩy bình thường mà mọi người đều hiểu. Dấu phẩy là dấu phân cách thông thường, không chỉ trong ngôn ngữ lập trình mà còn trong sách, báo và ngôn ngữ viết nói chung.

Object Pascal có cú pháp khác với C, nhưng cú pháp của nó thực sự DỄ DÀNG hơn để người lập trình đọc (có thể không phải đối với máy tính, nhưng ai quan tâm máy tính nghĩ gì). Vì vậy, có thể họ lạc đề, nhưng ít nhất kết quả của họ tốt hơn.

Python có một cú pháp khác, thậm chí còn dễ đọc hơn (đối với con người) so với Pascal. Vì vậy, khi họ thay đổi nó, làm cho nó khác đi, ít nhất họ đã làm cho nó tốt hơn cho các lập trình viên chúng tôi.

Và sau đó chúng ta có ObjectiveC. Thêm một số cải tiến cho C, nhưng phát minh ra cú pháp giao diện riêng, gọi phương thức, truyền tham số và những gì không. Tôi tự hỏi tại sao họ không hoán đổi + và - để cộng trừ hai số. Nó sẽ còn mát hơn.

Steve Jobs đã gặp khó khăn khi hỗ trợ ObjectiveC. Tất nhiên anh ta không thể hỗ trợ C #, tốt hơn, nhưng thuộc về đối thủ cạnh tranh tồi tệ nhất của anh ta. Vì vậy, đây là một quyết định chính trị, không phải là một quyết định thực tế. Công nghệ luôn bị ảnh hưởng khi các quyết định công nghệ được đưa ra vì lý do chính trị. Anh ta nên lãnh đạo công ty mà anh ta làm tốt, và để các vấn đề về lập trình cho các chuyên gia thực sự.

Tôi chắc rằng sẽ có nhiều ứng dụng hơn nữa cho iPhone nếu anh ấy quyết định viết iOS và hỗ trợ các thư viện bằng bất kỳ ngôn ngữ nào khác ngoài ObjectiveC. Đối với tất cả mọi người, ngoại trừ những người hâm mộ khó tính, những lập trình viên còn trinh và Steve Jobs, ObjectiveC trông thật lố bịch, xấu xí và ghê tởm.

Một điều tôi thích ở aim-c là hệ thống đối tượng dựa trên các thông điệp, nó cho phép bạn làm những điều thực sự tốt đẹp mà bạn không thể làm trong C # (ít nhất là không cho đến khi chúng hỗ trợ từ khóa động!).

Một điều tuyệt vời khác khi viết ứng dụng ca cao là Trình tạo giao diện, nó đẹp hơn rất nhiều so với trình thiết kế biểu mẫu trong Visual Studio.

Những điều về obj-c làm tôi khó chịu (với tư cách là nhà phát triển C #) là thực tế là bạn phải quản lý bộ nhớ của riêng mình (có bộ sưu tập rác, nhưng điều đó không hoạt động trên iPhone) và nó có thể rất dài dòng vì cú pháp bộ chọn và tất cả [].

Là một lập trình viên mới bắt đầu với Objective-C cho iPhone, đến từ C # 4.0, tôi thiếu các biểu thức lambda và đặc biệt là Linq-to-XML. Các biểu thức lambda là C # -specific, trong khi Linq-to-XML thực sự tương phản .NET so với Cocoa nhiều hơn. Trong một ứng dụng mẫu mà tôi đang viết, tôi có một số XML trong một chuỗi. Tôi muốn phân tích cú pháp các phần tử của XML đó thành một tập hợp các đối tượng.

Để thực hiện điều này trong Objective-C / Cocoa, tôi phải sử dụng lớp NSXmlParser . Lớp này dựa vào một đối tượng khác thực hiện giao thức NSXMLParserDelegate với các phương thức được gọi (đọc: thông báo được gửi) khi một thẻ mở phần tử được đọc, khi một số dữ liệu được đọc (thường là bên trong phần tử) và khi một số thẻ kết thúc phần tử được đọc . Bạn phải theo dõi trạng thái và trạng thái phân tích cú pháp. Và tôi thành thật không biết điều gì sẽ xảy ra nếu XML không hợp lệ. Thật tuyệt khi đi sâu vào chi tiết và tối ưu hóa hiệu suất, nhưng ôi trời, đó là rất nhiều mã.

Ngược lại, đây là mã trong C #:

using System.Linq.Xml;
XDocument doc = XDocument.Load(xmlString);
IEnumerable<MyCustomObject> objects = doc.Descendants().Select(
         d => new MyCustomObject{ Name = d.Value});

Vậy là xong, bạn đã có một bộ sưu tập các đối tượng tùy chỉnh được rút ra từ XML. Nếu bạn muốn lọc các phần tử đó theo giá trị hoặc chỉ lọc những phần tử chứa một thuộc tính cụ thể hoặc nếu bạn chỉ muốn 5 phần tử đầu tiên hoặc bỏ qua phần 1 đầu tiên và lấy phần 3 tiếp theo hoặc chỉ cần tìm xem có phần tử nào được trả về không ... BAM, tất cả đều ở đó trong cùng một dòng mã.

Có rất nhiều lớp mã nguồn mở giúp cho việc xử lý này dễ dàng hơn rất nhiều trong Objective-C, do đó sẽ giải quyết được nhiều việc nặng nhọc. Nó không phải là điều này được tích hợp sẵn.

* LƯU Ý: Tôi không thực sự biên dịch đoạn mã ở trên, nó chỉ có nghĩa là một ví dụ để minh họa sự thiếu chi tiết tương đối theo yêu cầu của C #.

Có lẽ sự khác biệt quan trọng nhất là quản lý bộ nhớ. Với C #, bạn nhận được bộ sưu tập rác, do nó là một ngôn ngữ dựa trên CLR. Với Objective-C, bạn cần tự quản lý bộ nhớ.

Nếu bạn đến từ nền tảng C # (hoặc bất kỳ ngôn ngữ hiện đại nào cho vấn đề đó), việc chuyển sang ngôn ngữ không có quản lý bộ nhớ tự động sẽ thực sự khó khăn, vì bạn sẽ dành nhiều thời gian viết mã để quản lý bộ nhớ đúng cách (và gỡ lỗi như tốt).

Đây là một bài viết khá hay so sánh hai ngôn ngữ: http://www.coderetard.com/2008/03/16/c-vs-objective-c/

Ngoài sự khác biệt về mô hình giữa hai ngôn ngữ, không có nhiều sự khác biệt. Tôi không muốn nói nhiều, bạn có thể làm những việc tương tự (có lẽ không dễ dàng như vậy) với .NET và C # như bạn có thể làm với Objective-C và Cocoa. Kể từ Leopard, Objective-C 2.0 có tính năng thu gom rác, vì vậy bạn không có tự quản lý bộ nhớ trừ khi muốn (khả năng tương thích mã với các ứng dụng iPhone và Mac cũ hơn là 2 lý do để bạn muốn).

Liên quan đến mã có cấu trúc, có thể đọc được, phần lớn gánh nặng ở đó thuộc về lập trình viên, cũng như với bất kỳ ngôn ngữ nào khác. Tuy nhiên, tôi thấy rằng thông báo truyền mô hình tự cho thấy mã có thể đọc được với điều kiện bạn đặt tên cho các hàm / phương thức của mình một cách thích hợp (một lần nữa, giống như bất kỳ ngôn ngữ nào khác).

Tôi sẽ là người đầu tiên thừa nhận rằng tôi không rành về C # hoặc .NET. Nhưng những lý do Quinn liệt kê ở trên là khá nhiều lý do mà tôi không quan tâm đến việc trở nên như vậy.

Các lệnh gọi phương thức được sử dụng trong obj-c làm cho mã dễ đọc, theo ý kiến ​​của tôi thanh lịch hơn nhiều so với c # và obj-c được xây dựng trên đầu c nên tất cả mã c sẽ hoạt động tốt trong obj-c. Người bán hàng lớn đối với tôi là obj-c là một tiêu chuẩn mở để bạn có thể tìm thấy các trình biên dịch cho bất kỳ hệ thống nào.