When to break a single Solidity Contract into Multiple Solidity Contract?

Question

What are the advantages and dis-advantages of using single and multiple solidity contract?

Answer 1

Ok, by chatting to you in the comments I came to the conclusion that the question basically is: How to know when to break a Smart Contract up into two or more and what is the advantages and disadvantages thereof.

Firstly

You will usually want to break a Smart Contract up when the code inside the contract starts deviating regarding their use case.

for example: say you have a smart contract where you want to pay users' salaries, but to do that you also need to make some calculations. You will then have code that handles the payments but also code that handles the maths and calculations. These 2 sections have different use cases and can then be split...even if not neccesary.

Secondly

Smart Contracts are aslo split up for consistency as well as version control. Fore example SafeMath.

Lastly

Smart Contracts are also split up to make the management of the contract easier. Just imagine if the salary example above has a major calculation section as well as a major payout section and the calculation needs to be changed the next year. It will be easier to just find the calculation contract and make the change there.

I guess in conclusion there is not a hard rule about this, but I hope this helps.

Answer 2

Breaking contract into multiple contracts yields no advantage on it's own. In fact, the size of the contracts would increase by a bit and that would cost the deployment to have a higher price.

But there is a better value in deconstructing a big contract into different libraries, as that would offload some of the utilitarian functions to another file (usually) and giving a better code readability and maintenance. It also will decrease the deployed size of your contract bytecode as there is a hard limit of 24kb.

If not libraries, your code logic can use multiple contracts approach, if you want to switch some of your contract logic after deploying it. if you have a contract A that depends on a method of ContractB, you can store the address of contractB in A and whenever you want to change the logic of that method you can deploy another contractB and change the address stored in A to the new contract thus changing logic on the fly.