Cách tổ chức file C và C++ (phần 1)

Giới thiệu:

Trong khi nhiều chương trình đơn giản chỉ gói gọn trong 1 file C hoặc CPP duy nhất, thì nhiều đề án lớn cần phải chia nhỏ thành nhiều file nguồn để tiện quản lý. Tuy nhiên, nhiều lập trình viên mới không nhận thấy tầm quan trọng của điều này – ngay cả khi họ cố gắng và chạy chương trình với quá nhiều vấn đề bên trong mà họ cho rằng nó không đáng để nỗ lực. Bài viết này sẽ giải thích tại sao ta cần phải làm như vậy, và làm sao để thực hiện đúng. Khi cần thiết, tôi sẽ đưa ra các giải thích cách làm việc của trình biên dịch và các mối liên kết để bạn hiểu rõ tại sao chúng ta phải làm theo cách đó.

Thuật ngữ:

Trong bài này, tôi sẽ gọi những file C và C++ tiêu chuẩn (thường có tên mở rộng C và CPP) là “file nguồn”. Điều này sẽ phân biệt chúng với những “file header” (thường có tên mở rộng là .H hay .HPP). Những thuật ngữ này cũng được sử dụng trong Visual C++ và hầu hết các sách. Chú ý rằng sự khác biệt hoàn toàn thuộc về quan niệm – chúng chỉ là những file văn bản với mã bên trong. Tuy nhiên, như những vấn đề sẽ được trình bày, sự khác biệt trong việc xử lý file nguồn và file header là rất quan trọng.

Tại sao phải chia nhỏ mã nguồn thành nhiều file?

Câu hỏi đầu tiên mà nhiều lập trình viên mới vào nghề thắc mắc khi họ nhìn thấy 1 thư mục chứa đầy những tập tin là “tại sao không nhét tất cả vào 1 file duy nhất?”. Đối với họ, họ không thấy được tầm quan trọng của việc phân tán mã nguồn.

Việc phân chia đề án đạt được một số thuận lợi, và những điều quan trọng nhất là:

  • Tăng tốc độ biên dịch: hầu hết các trình biên dịch làm việc trên 1 file trong 1 lúc. Do đó nếu bạn có 10000 dòng lệnh trong 1 file, vá bạn thay đổi 1 dòng, bạn phải biên dịch lại 10000 dòng lệnh. Mặt khác, nếu 10000 dòng lệnh của bạn được chia ra thành 10 file, thì sự thanh đổi 1 dòng chỉ yêu cầu 1000 dòng lệnh được biên dịch lại. 9000 dòng lệnh trong 9 file còn lại không cần phải biên dịch lại (Thời gian liên kết không bị ảnh hưởng).
  • Tăng cường sự tổ chức: phân chia code của bạn một cách hợp lý sẽ làm bạn (và bất kì lập trình viên khác trong đề án) dễ dàng hơn để tìm kiếm những hàm, biến, định nghĩa các cấu trúc/lớp, v.v… Thấy chí với khả năng nhảy trực tiếp để đưa ra những định nghĩa được cung cấp trong nhiều môi trường soạn thảo và lập trình (như Microsoft Visual C++), điều này vẫn có ích khi bạn cần xem 1 đoạn mã để tìm kiếm cái gì đó. Không những phân chia mã sẽ làm giảm số lượng mã cần phải biên dịch lại, mà còn giảm số lượng mã bạn cần phải đọc để tìm ra những gì bạn cần. Tưởng tượng rằng bạn cần tìm và sửa 1 lỗi mã âm thanh mà bạn đã làm nhiều tuần trước đây. Nếu bạn có 1 file lớn là GAME.C, thì cần phải tìm kiếm rất nhiều. Nếu bạn có vài file nhỏ GRAPHICS.C, MAINLOOP.C, SOUND.C, và INPUT.C, bạn biết nơi bạn cần tìm, giảm 3/4 số thời gian làm việc.
  • Giảm bớt sự viết lại: Nếu mã của bạn được phân chia cẩn thận thành những đoạn độc lập với nhau, bạn có thể sử dụng chúng trong đề án khác, tiết kiệm thời gian phải viết lại lần sau. Có nhiều thuận lợi khi viết mã có thể dùng lại được hơn là chỉ dùng 1 cách tổ chức file chặt chẽ, nhưng nếu không có sự tổ chức, thì sẽ rất khó khăn để biết được những đoạn mã nào liên quan đến nhau hay không. Do đó, đặt những thành phần chính và các lớp vào 1 file duy nhất hoặc mô tả cẩn thận tập hợp các file sẽ giúp bạn về sau nếu bạn sử dụng lại những mã đó trong đề án khác.
  • Chia sẽ mã giữa các đề án: nguyên tắc này giống như việc giảm bớt sự viết lại. Chia nhỏ 1 cách cẩn thận trong những file chính xác, bạn tạo khả năng cho nhiều đề án cùng sử dụng chung 1 file mà nguồn mà không cần nhân chúng lên. Lợi ích của việc chia sẽ file giữa các đề án so với sử dụng cắt-và-dán là bất cứ lỗi nào được sửa trong 1 hay nhiều file trong 1 đề án sẽ có tác dụng với những đề án khác, và tất cả đề án có thể chắc chắn được cập nhật bản mới nhất.
  • Phân chia trách nhiệm giữa các lập trình viên: trong những đề án lớn thật sự, đây có lẽ là lý do chính để phân chia mã trong nhiều file. Sẽ không thực tế khi nhiều hơn 1 lập trình viên cùng thay đổi 1 file duy nhất bất cứ lúc nào anh ta muốn. Do đó, bạn sẽ phải dùng nhiều file để mỗi lập trình viên có thể làm việc trên từng phần riêng biệt mà không ảnh hưởng đến file mà lập trình viên khác đang chỉnh sửa. Dĩ nhiên, vẫn cần có những sự kiểm tra để 2 lập trình viên không thay đổi trên cùng 1 file; hệ thống quản lý cấu hình và hệ thống điều khiển phiên bản như là CVS hoặc MS SourceSafe sẽ giúp bạn làm điều này.

Tất cả những gì ở trên cho ta thấy hình dáng của modularity, một thành phần quan trọng của cả lập tình cấu trúc và hướng đối tượng.
(còn tiếp)

Nguồn: http://www.gamedev.net/reference/programming/features/orgfiles/default.asp

————
Cảm ơn thầy Đ.B.Tiến đã cung cấp 1 tài liệu hữu ích 🙂

Advertisements

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Đăng xuất / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Đăng xuất / Thay đổi )

Connecting to %s