Nếu tôi đang tạo một lớp học với các chức năng nhỏ mà không làm được gì nhiều, có chấp nhận được để chỉ đưa tất cả chúng vào tệp tiêu đề không? Vì vậy, đối với một lớp học cụ thể, nó chỉ là .h không có .cpp để đi với nó.(C++) Toàn bộ lớp trong tệp .h?
Có, điều đó có thể chấp nhận được. Nó chắc chắn sẽ biên dịch. Nhưng cũng có thể, nếu nó làm cho tổ chức mã sạch hơn, thì điều đó có thể tốt. Hầu hết các định nghĩa mẫu đều giống như vậy, vì vậy bạn không làm bất cứ điều gì chưa từng nghe thấy. Tuy nhiên, có thể có một số nhược điểm của lớp đó dựa vào các lớp khác. Nếu bạn cuối cùng phải bao gồm toàn bộ định nghĩa trong các tệp khác sử dụng lớp, nó có thể phải chịu thêm thời gian biên dịch so với chỉ có khai báo lớp ngắn gọn.
Bạn có thể đo thời gian biên dịch của mình nếu điều này có vẻ là mối quan tâm thực sự.
Nếu bạn có thể lấy một bản sao, The c++ Programming Language (và nhiều sách khác) có phần chi tiết về tổ chức mã nguồn và lợi ích cụ thể của việc tách mã thành tệp .h và .cpp.
Có, chấp nhận được. Hơn nữa, nếu bạn làm mẫu và bạn không có trình biên dịch với hỗ trợ export thì bạn không có lựa chọn nào.
Tuy nhiên, lưu ý rằng nó có thể tăng phụ thuộc và do đó làm cho việc biên dịch chậm hơn.
Sẽ tốt nếu bạn sử dụng tệp tiêu đề đó trong các mã hoặc dự án trong tương lai của mình và nếu bạn muốn chia sẻ nó với những người khác.
Phụ thuộc vào cách bạn đang liên kết. Để tránh phải xem các thư như định nghĩa lại blah, định nghĩa trước đó trong tệp blah.h trên dòng 13 chỉ cần đặt mọi thứ nhưng khai báo trong tệp .cpp.
Điều đó tùy thuộc vào mục tiêu của bạn.
Đối với một dự án thú cưng, nó có thể chấp nhận được, nhưng sau đó mọi thứ đều thực sự.
Đối với một dự án thực tế, bạn cần phải tự hỏi mình một số câu hỏi:
Nếu câu trả lời thỏa mãn bạn, hãy tiếp tục.
Chủ yếu là vấn đề quản lý sự phụ thuộc. Bằng cách đặt định nghĩa phương thức trong tiêu đề, chúng có khả năng được trình biên dịch inlined, có nghĩa là mỗi khi chúng thay đổi, bạn sẽ phải biên dịch lại mọi thứ phụ thuộc vào lớp này.
Mẫu làm như vậy, tuy nhiên các mẫu thường có ít phụ thuộc (bao gồm khác) và bạn tương đối bắt buộc phải tiến hành như vậy (mặc dù bạn có thể mã hóa mã phụ thuộc không phụ thuộc để cắt giảm phụ thuộc).
Đối với các dự án lớn thực sự nơi quản lý phụ thuộc quan trọng nhất, thì tôi khuyên bạn nên chống lại. Trong các dự án đó, ABI ổn định và khả năng quảng bá các thay đổi tương thích nhị phân là các công cụ bảo vệ sự sống trong trường hợp phát hành và chúng cũng có giá trị bất tiện "nhỏ" đối với nhà phát triển.
Trong mọi trường hợp, vui lòng không xác định phương thức ở giữa lớp học. Thậm chí, bạn có thể định nghĩa chúng sau khi khai báo lớp. Điều này làm cho nó dễ dàng hơn cho những người đọc nó (bản thân bạn trong một vài tháng) để nắm bắt được giao diện một cách nhanh chóng.
IMO, nếu các phương pháp của bạn chủ yếu là một lớp lót, việc định nghĩa phương thức bên trong lớp không thực sự làm sao lãng nhiều và đôi khi có thể làm tăng khả năng hiểu mã; và trên thực tế, lý do duy nhất tại sao một người nào đó không muốn tạo một tệp .cpp riêng biệt là vì lớp nhỏ và các phương thức đều tầm thường. –
@ Ryan Ryan: Tôi đồng ý rằng một lớp lót (như 'empty' /' size') có thể được định nghĩa ở giữa lớp mà không làm phiền quá nhiều ... nhưng sau đó rất khó để xác định giới hạn giữa một lót, một lớp lót được bọc bởi vì nó không vừa với màn hình, hai lớp lót ngắn hơn lớp lót bọc, ... Sau đó, mọi người đều gọi. –
Nhưng bạn không cần phải xác định một giới hạn cứng, chỉ cần làm theo cảm xúc ruột của bạn. Cuối cùng, trình biên dịch sẽ vẫn tạo ra kết quả tương tự hoặc tương đương. Nhiều hướng dẫn stylem lập trình khuyến khích phong cách nhất quán chỉ vì tính nhất quán rất dễ định lượng, nếu một cái gì đó luôn luôn trông giống nhau thì nó nhất quán; tuy nhiên trong nhiều trường hợp, nỗi ám ảnh về sự nhất quán này là chi phí bỏ qua những lợi ích tiềm năng khó định lượng. Dễ đọc và dễ hiểu không dễ định lượng; và kết quả là, thường được xếp hàng bên trong các nguyên tắc về phong cách. –