CodeGym /Các khóa học /Frontend SELF VI /Mọi thứ đều là đối tượng

Mọi thứ đều là đối tượng

Frontend SELF VI
Mức độ , Bài học
Có sẵn

1.1 Đối tượng và lớp

Hôm nay bạn sẽ tìm hiểu về cách một chương trình điển hình trên JavaScript được cấu trúc. Và tin tốt lành: mỗi chương trình trên JavaScript đều bao gồm các lớp và đối tượng. JavaScript là một ngôn ngữ lập trình hướng đối tượng, và mọi thứ trong nó đều là đối tượng: số, chuỗi, hàm và thậm chí cả các lớp.

Vậy lớp là gì?

Bắt đầu với một ví dụ. Hãy tưởng tượng bạn muốn làm một chiếc tàu nhỏ. Đầu tiên cần làm bản vẽ, sau đó đưa nó cho nhà máy, nơi sẽ lắp ráp tàu theo bản vẽ đó. Hoặc hàng tá. Thực tế là bao nhiêu tàu cũng được. Một bản vẽ có thể tạo ra hàng chục chiếc tàu giống hệt nhau, đó là điều quan trọng.

Trong lập trình JavaScript cũng tương tự như vậy.

Bản vẽ

Lập trình viên cũng giống như một nhà thiết kế. Chỉ có điều nhà thiết kế vẽ bản vẽ, còn lập trình viên JavaScript viết các lớp. Sau đó, dựa trên các bản vẽ, tạo ra các bộ phận, và dựa trên lớp tạo ra đối tượng.

Bản vẽ

Đầu tiên chúng ta viết các lớp (làm bản vẽ), và sau đó, trong quá trình thực thi chương trình, JavaScript tạo ra đối tượng dựa trên những lớp này. Tương tự như việc tạo ra tàu dựa trên bản vẽ.

Một bản vẽ, nhưng có thể có nhiều tàu. Các tàu khác nhau, có tên khác nhau, chở các loại hàng khác nhau. Nhưng chúng rất giống nhau: tất cả đều là tàu với cấu trúc giống hệt nhau và có thể thực hiện các nhiệm vụ tương tự.

Hoặc một ví dụ khác...

Đàn kiến

Đàn kiến là một ví dụ tốt về sự tương tác giữa các đối tượng. Trong một tổ kiến đơn giản nhất có ba lớp kiến: kiến chúa, kiến chiến binh và kiến thợ.

Số lượng kiến của mỗi lớp khác nhau. Kiến chúa có một con trong cả tổ kiến, kiến chiến binh có hàng chục con, và kiến thợ có hàng trăm con. Ba lớp và hàng trăm đối tượng. Kiến tương tác với nhau, với những kiến cùng lớp và kiến của các lớp khác theo quy tắc được xác định rõ ràng.

Đây là một ví dụ hoàn hảo. Trong một chương trình điển hình mọi thứ cũng tương tự như vậy. Có một đối tượng chính tạo ra các đối tượng của tất cả các lớp còn lại. Các đối tượng bắt đầu tương tác với nhau và với "thế giới bên ngoài" của chương trình. Bên trong các đối tượng này, hành vi của chúng được lập trình cứng nhắc.

Hai lời giải thích này là hai mặt của cùng một đồng xu. Sự thật nằm ở giữa. Ví dụ đầu tiên (về bản vẽ và tàu) cho thấy mối quan hệ giữa lớp và các đối tượng của lớp đó. Ví dụ tương tự rất mạnh. Ví dụ thứ hai (về đàn kiến) cho thấy mối quan hệ giữa các đối tượng tồn tại khi chương trình chạy và các lớp đã được viết.

Đầu tiên bạn cần viết các lớp cho tất cả các đối tượng tồn tại trong chương trình, sau đó cần mô tả sự tương tác của chúng. Nghe có vẻ phức tạp, nhưng thực tế dễ hơn bạn nghĩ.

Trong JavaScript, tất cả các thực thể khi chương trình chạy đều là đối tượng, và việc viết chương trình được rút gọn thành việc mô tả các cách khác nhau của sự tương tác giữa các đối tượng. Các đối tượng chỉ gọi phương thức của nhau và truyền vào chúng các dữ liệu cần thiết.

Tài liệu

Làm sao để biết nên truyền dữ liệu nào vào các phương thức? Điều này đã được nghĩ ra trước đây rồi.

Thông thường, mỗi lớp đều có mô tả, trong đó nêu rõ nó được tạo ra để làm gì. Tương tự, mỗi phương thức công khai cũng có mô tả: nó làm gì và cần truyền dữ liệu nào vào.

Để sử dụng lớp, bạn cần biết đại khái nó làm gì. Và cũng cần biết chính xác từng phương thức của nó làm gì. Nhưng không cần thiết phải biết cách nó thực hiện điều đó. Kiểu như một cây đũa thần vậy.

Hãy cùng nhìn vào mã - sao chép tập tin:

JavaScript
    
      const fs = require('fs');

      // Mở tập tin
      const src = fs.createReadStream('source.txt');
      const dst = fs.createWriteStream('destination.txt');

      // Sao chép nội dung từ source.txt sang destination.txt
      src.pipe(dst);

      // Đóng tập tin sau khi sao chép hoàn tất
      src.on('end', () => {
        src.close();
        dst.close();
      });
    
  

Nếu đọc mã này từng dòng một, bạn có thể đoán được nó làm gì tổng quát. Mặc dù cần kinh nghiệm và thực hành. Sau một thời gian mã này sẽ trở nên quen thuộc và dễ hiểu với bạn.

1.2. Thiết kế chương trình

Thiết kế chương trình là một nghệ thuật. Nó vừa dễ vừa khó cùng một lúc. Dễ vì không có quy luật cứng nhắc nào cả: tất cả những gì không bị cấm đều được phép. Và khó cũng vì lý do này: có rất nhiều cách để làm, và khó để tìm ra cách tốt nhất.

Thiết kế chương trình giống như viết một cuốn sách. Một mặt, bạn chỉ cần viết các chữ cái, từ, câu. Mặt khác, cốt truyện, tính cách nhân vật, mâu thuẫn nội tâm, xung đột, phong cách kể chuyện, sự hấp dẫn, v.v. rất quan trọng.

Điều quan trọng nhất là hiểu mình đang viết mã cho ai. Bạn viết mã cho những lập trình viên khác.

Phát triển bất kỳ sản phẩm nào cũng là việc thực hiện những thay đổi: thêm vào đây, xóa ở đó, sửa lại ở kia. Và cứ thế qua các vòng lặp nhỏ, các dự án lớn, khổng lồ và cực kỳ lớn được tạo ra.

Yêu cầu chính đối với mã là nó cần được hiểu dễ dàng bởi lập trình viên khác. Mã sai nhưng dễ hiểu thì có thể sửa. Mã đúng mà khó hiểu thì không thể nâng cấp. Chỉ còn cách vứt bỏ.

Vậy làm sao để viết mã tốt và dễ hiểu?

Để làm được điều đó, bạn cần làm ba điều:

  • Viết mã tốt và dễ hiểu trong các phương thức — điều đơn giản nhất
  • Quyết định các thực thể nào cần có trong chương trình
  • Chia nhỏ chương trình thành các phần logic đúng cách

Vậy điều gì là cốt lõi đằng sau những khái niệm này?

Viết mã tốt trong các phương thức

Nếu bạn có ít nhất trình độ tiếng Anh cơ bản, có thể bạn đã nhận ra đôi khi mã rất dễ đọc — như câu tiếng Anh:

  • class Cat extends Pet — lớp Cat mở rộng từ lớp Pet
  • while (stream) — trong khi stream không rỗng ...
  • a < b ? a : b — nếu a nhỏ hơn b, trả về a, ngược lại trả về b

Điều này được thực hiện có ý đồ. JavaScript là một trong số ít các ngôn ngữ mà bạn có thể dễ dàng viết mã tự tài liệu: mã rõ ràng mà không cần chú thích. Trong mã tốt, nhiều phương thức trong JavaScript được đọc giống như câu tiếng Anh.

Nhiệm vụ của bạn khi viết mã là làm cho nó càng đơn giản và ngắn gọn càng tốt. Chỉ cần nghĩ mã của bạn có dễ đọc không, và bạn sẽ bắt đầu đi đúng hướng.

Trong JavaScript, người ta thường viết mã dễ đọc. Lý tưởng là mỗi phương thức nằm gọn trên màn hình (độ dài phương thức — 20-30 dòng). Đây là chuẩn cho toàn bộ cộng đồng JavaScript. Nếu có thể cải thiện mã, cần phải cải thiện nó.

Cách tốt nhất để học viết mã tốt là thực hành liên tục. Hãy viết nhiều mã, học mã của người khác, nhờ đồng nghiệp có kinh nghiệm hơn đánh giá mã của mình. Và nhớ rằng, khi bạn tự nói "vậy cũng được", sự phát triển của bạn đã dừng lại.

Quyết định các thực thể nào cần có trong chương trình

Bạn cần viết mã dễ hiểu cho những lập trình viên khác. Nếu 9 trong số 10 lập trình viên khi thiết kế chương trình tạo ra trong đó các lớp A, B và C, thì bạn cũng cần tạo ra trong chương trình của mình các lớp A, B và C. Bạn phải viết mã dễ hiểu cho người khác.

Mã tuyệt vời, hoạt động tốt, chạy nhanh, không theo chuẩn là mã xấu.

Bạn cần nghiên cứu các dự án của người khác: đây là cách tốt nhất, nhanh nhất và dễ dàng nhất để tiếp thu tất cả sự khôn ngoan đã được tích lũy trong ngành CNTT trong nhiều thập kỷ.

Và còn có một dự án tuyệt vời, phổ biến, được tài liệu tốt sẵn có cho bạn — React. Bắt đầu từ nó.

Nghiên cứu các lớp và cấu trúc của chúng. Suy nghĩ lý do tại sao một số phương thức là tĩnh, còn các phương thức khác thì không. Tại sao các phương thức có các tham số như vậy, mà không phải khác. Tại sao lại chính là các phương thức này, tại sao các lớp có tên như vậy và nằm trong các gói như vậy.

Khi bạn bắt đầu hiểu được các câu trả lời cho những câu hỏi này, bạn sẽ có thể viết mã dễ hiểu cho người khác.

Tuy nhiên, tôi muốn cảnh báo bạn về việc phân tích mã trong các phương thức của D3.js. Mã của nhiều phương thức đã được viết lại nhằm tối ưu hóa tốc độ — khả năng đọc của nó là câu hỏi lớn.

Chia nhỏ chương trình thành các phần logic đúng cách

Thông thường, một chương trình được chia thành các phần hoặc module. Mỗi phần chịu trách nhiệm cho một khía cạnh của chương trình.

Máy tính có hộp hệ thống, màn hình, bàn phím, tất cả là các phần riêng biệt, ít phụ thuộc. Hơn nữa, sự tương tác của chúng được tiêu chuẩn hóa: USB, HDMI, v.v. Nhưng nếu bạn đổ cà phê lên bàn phím, bạn có thể chỉ cần rửa nó dưới vòi nước, phơi khô và sử dụng tiếp tục.

Còn với laptop — đây là ví dụ về kiến trúc nguyên khối: các phần logic dường như có, nhưng tích hợp mạnh mẽ hơn nhiều. Với Macbook Pro, để làm sạch bàn phím, bạn cần tháo nửa máy. Đổ cà phê lên laptop là lý do để đặt hàng một cái mới. Nhưng không phải cà phê.

1.3 Tạo các lớp của riêng bạn

Bạn chỉ mới học lập trình, vì vậy bạn cần bắt đầu từ những điều nhỏ - học cách tạo ra các lớp riêng.

Chắc hẳn bạn đã tạo ra chúng rồi, nhưng bạn cần học cách hiểu những lớp nào nên có trong chương trình, chúng nên đặt tên như thế nào, có những phương thức gì. Và chúng nên tương tác với nhau như thế nào.

Danh sách thực thể

Nếu không biết bắt đầu từ đâu, hãy bắt đầu từ đầu.

Ngay từ đầu khi thiết kế chương trình, bạn có thể chỉ cần viết lên giấy danh sách các thực thể (đối tượng) cần có trong chương trình. Sau đó lập trình chúng theo nguyên tắc: mỗi thực thể là một lớp riêng.

Ví dụ

Giả sử bạn muốn viết một trò chơi cờ vua. Bạn cần có các thực thể như: bàn cờ và 6 loại quân cờ. Các quân cờ di chuyển khác nhau, có giá trị khác nhau — hợp lý là đó là các lớp riêng. Thực tế, ngay từ ban đầu, càng nhiều lớp càng tốt.

Hiếm khi gặp một lập trình viên mới làm việc tạo ra mười lớp thay vì hai lớp. Thay vào đó là viết hai hoặc thậm chí một lớp — đó là điều mà người mới thường làm. Vậy nên các lập trình viên, hãy tạo ra càng nhiều lớp càng tốt. Và mã của bạn sẽ rõ hơn cho tất cả mọi người, ngoại trừ có thể bạn 😛

Cờ vua

Giả sử chúng ta quyết định viết các lớp cho cờ vua: các lớp này sẽ trông như thế nào?

Bàn cờ - đó có phải chỉ là một mảng 8x8? Tốt nhất là tạo cho nó một lớp riêng, trong đó chứa tham chiếu đến mảng. Sau đó bạn có thể thêm nhiều phương thức tiện ích vào lớp "bàn cờ", chẳng hạn như kiểm tra ô có trống hay không.

Nhìn chung, ban đầu bạn luôn có thể tuân theo nguyên tắc: Chương trình có các Thực thể khác nhau, và Thực thể có kiểu. Kiểu này chính là lớp.

Bình luận
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION