S U N C O D E . E D U . V N

Loading...

Bạn đã bao giờ tạo một chương trình Scratch, hỏi người dùng một câu, nhưng lại nhận được một câu trả lời kỳ quặc khiến chương trình “đơ” hoặc hoạt động sai chưa? Vấn đề nằm ở việc thiếu kiểm tra đầu vào (input validation). Bài viết này sẽ hướng dẫn bạn từng bước cách “dạy” chương trình Scratch của mình trở nên thông minh hơn, biết cách xử lý và phản hồi phù hợp với mọi câu trả lời từ người dùng, dù đó là “yupper”, “nah” hay thậm chí là “dưa chuột muối”.

Giao diện Scratch với khối lệnh "hỏi và chờ đợi" đang được kéo vào khu vực lập trình.

Tại Sao Cần Kiểm Tra Đầu Vào?

Trong thế giới lập trình, đầu vào từ người dùng luôn là một ẩn số. Họ có thể gõ đúng, gõ sai chính tả, dùng từ đồng nghĩa, hoặc thậm chí trả lời một câu hoàn toàn không liên quan. Nếu chương trình của bạn chỉ được lập trình để chấp nhận một câu trả lời chính xác duy nhất (ví dụ: “yes”), nó sẽ thất bại ngay lập tức khi gặp “yeah”, “có”, “chắc chắn rồi” hay “yupper”.

Kiểm tra đầu vào chính là quá trình lập trình để đảm bảo dữ liệu nhận được từ người dùng phù hợp với yêu cầu của chương trình trước khi xử lý. Nó giúp:
Tăng tính ổn định: Chương trình không bị lỗi hoặc dừng đột ngột.
Cải thiện trải nghiệm người dùng: Cung cấp phản hồi rõ ràng, hướng dẫn người dùng nhập đúng.
Tạo cảm giác chuyên nghiệp: Ứng dụng của bạn trở nên thông minh và linh hoạt hơn.

Hãy cùng bắt đầu với một ví dụ đơn giản nhất: câu hỏi Có/Không.

Bài Học 1: Kiểm Soát Câu Trả Lời Có/Không

Giả sử chúng ta muốn tạo một chương trình hỏi: “Bạn có thích bánh mì kẹp thịt không?”

Cách Làm Cơ Bản (Và Đầy Rủi Ro)

Khối lệnh "hỏi" với câu hỏi "Do you like cheeseburgers?" và cấu trúc "nếu-thì" kiểm tra câu trả lời.

Cách tiếp cận đơn giản là dùng khối hỏi và sau đó dùng nếu-thì để kiểm tra:
Nếu câu trả lời = "yes" → Nói “Great, me too!” (Tuyệt, tôi cũng thế!)
Ngược lại → Nói “Ah, too bad.” (Ôi, tiếc quá.)

Chương trình này chạy tốt nếu người dùng nhập chính xác “yes” hoặc “no”. Nhưng thử tưởng tượng:
– Người dùng nhập "yupper" (một cách nói vui của “yes”) → Chương trình trả lời “Ah, too bad.” Sai hoàn toàn!
– Người dùng nhập "YES" (viết hoa) → Scratch phân biệt chữ hoa chữ thường, nên đây vẫn bị coi là sai.

Rõ ràng, chúng ta cần một cơ chế “bắt” người dùng phải trả lời đúng định dạng.

Nâng Cấp Với Vòng Lặp “Lặp Lại Cho Đến Khi”

Giải pháp là sử dụng khối lặp lại cho đến khi. Tư tưởng là: Hỏi đi hỏi lại câu hỏi cho đến khi nhận được câu trả lời hợp lệ.

Cấu trúc lệnh với vòng lặp "lặp lại cho đến khi" bao quanh khối "hỏi", điều kiện là "câu trả lời = yes hoặc no".

Các bước thực hiện:
1. Hỏi câu hỏi: “Bạn có thích bánh mì kẹp thịt không?”
2. Lặp lại cho đến khi câu trả lời = "yes" hoặc câu trả lời = "no".
3. Bên trong vòng lặp: Nếu câu trả lời không phải “yes” hoặc “no”, hãy thông báo: “Sorry, that is not a valid answer. Please answer yes or no.” (Xin lỗi, đó không phải câu trả lời hợp lệ. Vui lòng trả lời có hoặc không.) sau đó hỏi lại.
4. Thoát vòng lặp: Khi có câu trả lời hợp lệ (“yes”/”no”), chương trình tiếp tục và đưa ra phản hồi phù hợp.

Chương trình chạy, người dùng nhập "yupper" và nhận được thông báo "Sorry, that is not a valid answer."

Bằng cách này, dù người dùng có nhập “yup”, “nah”, “có”, “không” hay bất cứ thứ gì, chương trình sẽ kiên nhẫn yêu cầu họ nhập lại cho đến khi nhận được đúng “yes” hoặc “no”. Đây chính là kiểm tra đầu vào trong hành động.

Bài Học 2: Xây Dựng Menu Tương Tác Thông Minh

Hãy thử thách bản thân với một tình huống phức tạp hơn: tạo một chương trình menu nhà hàng ảo. Người dùng sẽ đặt món, và chương trình cần kiểm tra xem món đó có trong thực đơn không.

Phương Pháp Truyền Thống: “Nếu-Thì” Chồng Chéo

Cách đầu tiên có thể nghĩ đến là dùng nhiều khối nếu-thì lồng nhau:

  1. Hỏi: “Bạn muốn dùng món gì?”
  2. Kiểm tra:
    • Nếu câu trả lời = "burger" → “Great! Burger coming right up!”
    • Nếu câu trả lời = "pizza" → “Great! Pizza coming right up!”
    • Nếu câu trả trả lời = "hot dog" → “Great! Hot dog coming right up!”
    • Ngược lại → “Sorry, we don’t have that here.”

Hàng loạt khối "nếu-thì" được xếp chồng lên nhau để kiểm tra từng món ăn.

Cách này hoạt động, nhưng có nhược điểm lớn:
Cồng kềnh: Mỗi món mới cần thêm một khối nếu-thì. Với 100 món, bạn sẽ có 100 khối!
Khó bảo trì: Nếu muốn thay đổi thông báo chung, bạn phải sửa từng khối một.

Cách Tối Ưu: Sử Dụng Sức Mạnh Của Danh Sách (List)

Scratch có một công cụ tuyệt vời: Danh sách (List). Chúng ta có thể lưu trữ toàn bộ thực đơn vào một danh sách tên là Món_Ăn.

Danh sách "food options" được tạo ra và thêm các mục "burger", "pizza", "hot dog".

Sau đó, thay vì kiểm tra từng món một, chúng ta chỉ cần một điều kiện duy nhất:
Nếu Món_Ăn có chứa câu trả lời → “Great! [câu trả lời] coming right up!”
Ngược lại → “Sorry, we don’t have that here.”

Cấu trúc lệnh gọn gàng sử dụng khối "danh sách... có chứa...?" để thay thế cho nhiều khối "nếu-thì".

Ưu điểm vượt trội:
Gọn gàng: Chỉ cần vài khối lệnh.
Dễ mở rộng: Để thêm món mới, bạn chỉ việc bổ sung vào Danh sách Món_Ăn, không cần chạm vào logic chính.
Linh hoạt: Người dùng có thể nhập “pizza”, “Pizza” hay “pIzZa” (nếu bạn kết hợp với khối chuyển đổi chữ thường).

Tích Hợp Vòng Lặp: Đảm Bảo Khách Hàng Luôn Được Phục Vụ

Chúng ta có thể kết hợp bài học từ phần 1: sử dụng vòng lặp lặp lại cho đến khi để đảm bảo khách hàng luôn chọn được thứ gì đó từ thực đơn.

Cấu trúc hoàn chỉnh: vòng lặp "lặp lại cho đến khi" kết hợp với danh sách để kiểm tra đầu vào liên tục.

Logic sẽ là:
1. Hỏi khách hàng muốn gì.
2. Lặp lại cho đến khi Món_Ăn có chứa câu trả lời.
3. Bên trong vòng lặp (tức là món không có):
– Thông báo: “Sorry, we do not sell that here.”
Hỏi lại câu hỏi “Bạn muốn dùng món gì?”.
4. Khi thoát vòng lặp (đã chọn món hợp lệ): Thông báo “Great! [món ăn] coming right up!”.

Minh họa chương trình chạy: người dùng lần lượt nhập "cake", "pickles", "french fries" đều bị từ chối, cho đến khi nhập "burger" thì được chấp nhận.

Bây giờ, chương trình của bạn đã trở thành một “nhân viên phục vụ” kiên nhẫn và không biết mệt mỏi, sẵn sàng hỏi đi hỏi lại cho đến khi khách hàng gọi đúng món!

Kết Luận: Biến Ý Tưởng Thành Ứng Dụng Thực Tế

Kiểm tra đầu vào không phải là một kỹ thuật cao siêu, mà là tư duy lập trình cơ bản và thiết yếu để tạo ra sản phẩm chất lượng. Từ ví dụ đơn giản về câu hỏi Có/Không đến việc xây dựng một hệ thống menu tương tác, nguyên lý vẫn là: đừng bao giờ tin tưởng tuyệt đối vào đầu vào từ người dùng, hãy lập trình để kiểm tra và xử lý nó.

Hãy thử áp dụng những kỹ thuật này vào dự án Scratch tiếp theo của bạn:
Bài trắc nghiệm: Đảm bảo người chơi chỉ nhập A, B, C, D.
Game tính điểm: Kiểm tra xem điểm nhập vào có phải là số không.
Ứng dụng đặt lịch: Xác nhận ngày tháng nhập vào có hợp lệ không.

Tổng kết cuối video với các khối lệnh chính được hiển thị rõ ràng.

Bằng cách làm chủ vòng lặp lặp lại cho đến khiDanh sách, bạn đã có trong tay công cụ để biến những chương trình Scratch đơn giản thành những ứng dụng mạnh mẽ, thân thiện và chuyên nghiệp. Hãy bắt đầu kiểm tra đầu vào ngay hôm nay, và xem sự khác biệt mà nó tạo ra cho dự án của bạn!

Leave A Comment