(Sub) contract vs. library vs. struct vs. Interface

Question

First I googled and read through these questions:

Creating multiple contracts or Single contract with struct

Child contract vs struct

Why are so many examples using separated contracts (e.g. crowed sale contracts in zeppelin...)? IF I got all this right in most cases it would make sense to NOT use separated contracts. It would not even make sense to use libs and interfaces. Imho an interface makes sense if I do not have to pay gas for execution. But we are on a blockchain and want to keep contracts as "slim"/"light" as possible. Therefore I would even only copy the code functions I need out of a lib (only use the whole lib if I use all functions). Use the interface only for checking and debugging...

Answer 1

There are two separate reasons you would want to separate your logic into more than one contracts / libraries / etc.

1- Modularity, ease of use, ease of maintenance. If you forgo the usage of libraries or inheritance from other contracts your code go be a huge file with dozens of functions, which is hard to maintain, read, reuse, etc.

2- Implementing parent/child contracts has more to do with the logic of your code. For example, for a bidding app, you could have one contract that stores all the bids going on with their corresponding data (bidders, winning bid, etc) OR, you could create Bid contracts that each one holds the logic on their own, and then a parent contract that keeps a reference to every bid contract that gets created.

Each approach has it's own pros and cons and it really depends on what the requirements are for your application.