Có nhiều người hỏi mình có nên sử dụng try/catch để xử lý exception khi lập trình trên iOS không? Theo kinh nghiệm mình làm trên Objective-C được 5 năm, thì mình xin trả lời là có thể có hoặc không có cũng được, miễn sao bạn bắt được hết những trường hợp exception đó bằng câu lệnh if, để có thể không xảy ra tình trạng crash ứng dụng và chạy theo đúng yêu cầu của khách hàng là được.
Mình yêu thích ngôn ngữ Objective-C, Swift, Javascript và chia sẻ kiến thức lập trình trên iOS và Node.js, AWS, GCP. Các bạn thấy hay hãy nhấn +1 ủng hộ mình nhé (^.-).
Showing posts with label Objective C. Show all posts
Showing posts with label Objective C. Show all posts
Wednesday, April 20, 2016
Tuesday, April 12, 2016
Phân biệt biến kiểu Property, Public, Protected, Private trong ngôn ngữ Objective C
- Theo kinh nghiệm làm việc của mình với các bạn trong nhóm khi lập trình Objective-C và cũng đọc qua code của những project cũ. Ít khi nào mọi người để ý và khai báo đúng với ý đồ của từng đối tượng, và vi phạm quy tắc tính đóng gói, tính bảo mật thông tin của đối tượng trong lập trình hướng đối tượng (Tham khảo lý thuyết Lập trình hướng đối tượng tại trang Wiki).
- Theo ngôn ngữ lập trình Java, người ta khuyến khích mỗi khi dùng biến kiểu public thì nên đặt 1 biến private và hỗ trợ những hàm getter/setter để truy suất biến private đó.
+ Nguyên nhân họ nói là đảm bảo tính đóng gói, và nếu sau này có thay đổi gì trên biến đó bạn có thể sửa được dễ dàng, chi tiết về vấn đề này ở đây.
+ Nói tóm tại thì nguyên nhân chính là có thể kiểm soát được truy xuất đến giá trị của 1 đối tượng từ bên ngoài, có thể dễ dàng mở rộng code bằng cách override lại những hàm getter/setter.
- Các bạn có thể áp dụng nguyên tắc đó từ bên Java qua ngôn ngữ lập trình Objective-C cũng được. Nhưng nên nhớ khi khai báo biến kiểu property system ObjC tự động sinh những hàm getter/setter và quản lý dùm bạn. Nếu bạn cần thêm những việc xử lý nào khác thì override lại phương thức getter/setter của property đó.
- Nếu cái gì public đều dùng property hay phương thức getter/setter hết thì những ngôn ngữ lập trình hướng đối tượng nên bỏ từ khoá public luôn đi cho rồi.
- Hiện tại mình vẫn chưa tìm ra tài liệu chính thống từ Apple nói nên dùng hay không nên dùng biến property cho biến public hay không. Vì thế chúng ta sẽ không bàn về vấn đề đó đúng hay sai. Tuỳ theo trường hợp mình áp dụng là được, hiện tại mình có những trường hợp như sau:
+ Các bạn mới học lập trình thì mình khuyên nên dùng property để khai báo biến public, để tránh những rủi ro mà bạn không lường trước được.
+ Dùng property để khai báo biến public để có 1 coding standard cho team và đảm bảo tính đóng gói trong lập trình hướng đối tượng.
+ Khi bạn cần tối ưu hoá code thì nên lưu ý vấn đề truy suất trực tiếp thông qua @public này, có thể giúp bạn được phần nào tốc độ xử lý.
- Vì thế mình viết bài này để phân tích khi nào thì cần dùng biến theo Property hay iVar (Public, Protected, Private) để các bạn tham khảo khi viết trên ngôn ngữ Objective-C (Swift mình sẽ nghiên cứu và phân tích sâu về nó sau). Các bạn có kiến thức tốt lập trình hướng đối tượng khi viết bằng các ngôn ngữ khác như Java, PHP,... có thể chuyển code đó qua Objective-C uyển chuyển và ngắn gọn. Thực chất ra cách khai báo những biến như vậy cũng rất giống những ngôn ngữ lập trình khác nhưng ít khi nào dân lập trình trên iOS bằng Objective-C dùng.
- Nếu bạn có 1 khách hàng khó và họ định nghĩa sẵn hệ thống của họ theo từng sơ đồ như class diagram đàng hoàng. Họ bắt bạn phải viết code theo đúng như thiết kế của họ thì chắc chắn bạn phải làm theo. Hiện tại mình thấy đa số dân lập trình toàn viết code làm sao chạy được, còn tính đúng đắn hay thiết kế như thế nào cho hợp lý thì thường bỏ qua. Thành ra code dư thừa rất nhiều và khó bảo trì sau này.
- Giả sử mình có 1 lớp tên là PCObject được định nghĩa như sau:
- Theo ngôn ngữ lập trình Java, người ta khuyến khích mỗi khi dùng biến kiểu public thì nên đặt 1 biến private và hỗ trợ những hàm getter/setter để truy suất biến private đó.
+ Nguyên nhân họ nói là đảm bảo tính đóng gói, và nếu sau này có thay đổi gì trên biến đó bạn có thể sửa được dễ dàng, chi tiết về vấn đề này ở đây.
+ Nói tóm tại thì nguyên nhân chính là có thể kiểm soát được truy xuất đến giá trị của 1 đối tượng từ bên ngoài, có thể dễ dàng mở rộng code bằng cách override lại những hàm getter/setter.
- Các bạn có thể áp dụng nguyên tắc đó từ bên Java qua ngôn ngữ lập trình Objective-C cũng được. Nhưng nên nhớ khi khai báo biến kiểu property system ObjC tự động sinh những hàm getter/setter và quản lý dùm bạn. Nếu bạn cần thêm những việc xử lý nào khác thì override lại phương thức getter/setter của property đó.
- Nếu cái gì public đều dùng property hay phương thức getter/setter hết thì những ngôn ngữ lập trình hướng đối tượng nên bỏ từ khoá public luôn đi cho rồi.
- Hiện tại mình vẫn chưa tìm ra tài liệu chính thống từ Apple nói nên dùng hay không nên dùng biến property cho biến public hay không. Vì thế chúng ta sẽ không bàn về vấn đề đó đúng hay sai. Tuỳ theo trường hợp mình áp dụng là được, hiện tại mình có những trường hợp như sau:
+ Các bạn mới học lập trình thì mình khuyên nên dùng property để khai báo biến public, để tránh những rủi ro mà bạn không lường trước được.
+ Dùng property để khai báo biến public để có 1 coding standard cho team và đảm bảo tính đóng gói trong lập trình hướng đối tượng.
+ Khi bạn cần tối ưu hoá code thì nên lưu ý vấn đề truy suất trực tiếp thông qua @public này, có thể giúp bạn được phần nào tốc độ xử lý.
- Vì thế mình viết bài này để phân tích khi nào thì cần dùng biến theo Property hay iVar (Public, Protected, Private) để các bạn tham khảo khi viết trên ngôn ngữ Objective-C (Swift mình sẽ nghiên cứu và phân tích sâu về nó sau). Các bạn có kiến thức tốt lập trình hướng đối tượng khi viết bằng các ngôn ngữ khác như Java, PHP,... có thể chuyển code đó qua Objective-C uyển chuyển và ngắn gọn. Thực chất ra cách khai báo những biến như vậy cũng rất giống những ngôn ngữ lập trình khác nhưng ít khi nào dân lập trình trên iOS bằng Objective-C dùng.
- Nếu bạn có 1 khách hàng khó và họ định nghĩa sẵn hệ thống của họ theo từng sơ đồ như class diagram đàng hoàng. Họ bắt bạn phải viết code theo đúng như thiết kế của họ thì chắc chắn bạn phải làm theo. Hiện tại mình thấy đa số dân lập trình toàn viết code làm sao chạy được, còn tính đúng đắn hay thiết kế như thế nào cho hợp lý thì thường bỏ qua. Thành ra code dư thừa rất nhiều và khó bảo trì sau này.
- Giả sử mình có 1 lớp tên là PCObject được định nghĩa như sau:
Thursday, May 7, 2015
Phân biệt những kiểu khai báo file #include, #import và @import trong Objective C (Có hình ảnh minh hoạ)
Trong ngôn ngữ lập trình Objective C, khi khởi tạo 1 đối tượng hệ thống sẽ thường sinh ra 2 file có đuôi khác nhau là file ".h" và file ".m". Vậy câu hỏi được đặt ra là khi ta khai báo file nên khái báo trong file .h hay file .m ? Chúng có sự khác biệt nào không? Hãy cùng mình phân tích sự khác biệt khi khai báo trong từng loại file.
Ví dụ: Mình tạo 3 đối tượng có tên như: ObjectA, ObjectB, ObjectC. Trong ObjectA mình có dùng ObjectB, trong ObjectB mình có dùng ObjectC và trong ObjectC mình có dùng ObjectA. Những đối tượng này đều có thuộc tính là "name".
- Trường hợp 1: Giả sử mình khai báo bằng #include trong những file .h. Như hình sau:
Ví dụ: Mình tạo 3 đối tượng có tên như: ObjectA, ObjectB, ObjectC. Trong ObjectA mình có dùng ObjectB, trong ObjectB mình có dùng ObjectC và trong ObjectC mình có dùng ObjectA. Những đối tượng này đều có thuộc tính là "name".
- Trường hợp 1: Giả sử mình khai báo bằng #include trong những file .h. Như hình sau:
Wednesday, August 20, 2014
(Kinh nghiệm) Viết code ARC hay Non-ARC trên iOS
- Ai đã từng lập trình trên iOS trước iOS 5.0 đều phải tự quản lý bộ nhớ, đó là kiến trúc Non-ARC. Nếu bạn quản lý bộ nhớ không tốt thì có
thể crash app khi ứng dụng sử dụng nhiều memory quá và không bị huỷ đi.
Subscribe to:
Posts (Atom)



