How to deal with too many arguments to a constructor?

Question

I'm a beginner in programming and I'm learning the C++ programming language using the book : Programming principles and practice using C++. Today I'm here because I need help with solving a technical problem. In chapter 9 I have to write this program that implements a Book class such as we can imagine it as a part of a library software. Our book class will have 4 members : an ISBN (represented with the form nnnx where n is an integer and x is a letter or digit), the name of the author, the name of the book, the copyright date.

I just started using classes so I'm still learning what kind of consideration a programmer should do while writing the code, for this class I don't think we can provide any default constructor because there is no default value to give to a book. So, deciding to have 4 arguments for the Book constructor we would have somenthing like this :

class Book {
public: 
Book(string, string, string, Date); 
private: 
string isbn; 
string author; 
string title; 
Date copyright_date; // I defined the Date class in a previous exercise
};

After writing this brief skecth of the Book class I think now that the constructor for the book class can be a problem, this is because it takes 4 arguments that can make the initialization list really long :

Book b1{ "1,2,3,h", "Stroustrup", "Programming principles and practice using C++", {2015,Month::jan, 1} }; 

Do you think this initialization of a Book is too long ? what if I would like to create a vector of Books ? how would you solve this problem ? Please remember that I am not an expert so I still can't understand everything about classes and their design, this is just a question to try to improve my skills and to get a better idea about classes.

Answer 1

Since you are a learner, I am going to give you some advice you did not specifically asked.

First. Never do using namespace std; . There is a reason why namespace std was put in place and this is not to make you type those magic words in the beginning of every file. It is to avoid conflicts in names. With this habit you will soon encounter a very puzzling compilation errors, when there will be a name in std namespace and your own namespace or other namespace you've use d the same way. Long story short, do not do this :).

Second. Give your arguments names in the function prototypes. Book(string, string, string, Date); should be Book(std::string isbn, std::string author...; . This will help you (or other code maintainer) to see what the function expects without looking for it's implementations.

Third. string arguments. Pass by value or by reference? There is a LOT to be said about it, just last week I was really scorned for saying somethig I do believe in. I suggest you take a dive into the matter later, it is important and defines your programming habits. For now you just need to understand what really happens when you pass strings by value, like you do.

Fourth. No, it is not long :) (your argument list). To enhanace readability, split it over several lines. The way to split is purely subjective to one's aesthetics, I personally prefer this form:

Book b1{ "1,2,3,h", "Stroustrup",
         "Programming principles and practice using C++",
         {2015,Month::jan, 1}
       }; 

Answer 2

Actually you are putting multiple responsibility in your class which is voilating Single Responsibility principle. Sounds un-familiar, RIGHT?

It should be. As a beginner, it's nice that you are learning some basics of OOP. You are also concerned about maintainability of your code. I would suggest first learn all feature of OOP and learn to implement them on code. When you think you are good to go, study the following topics :

1. Code Refactoring
2. Code Smell
3. Separation of Concern
4. SOLID principle

Take your time, no hurry. When you think you have sound knowledge and can code for the above topics, then start learning Design Pattern.

This topics are not something that can be grasped with a single shot. It requires many practice, failure, trial and error method.