Can I think of a smart contract as being analogous to a Class in an object-oriented programming language (e.g., Java)?
Each transaction that uses the contract essentially instantiates an object of the contract (or class), and then that object (i.e., transaction) maintains its own properties like private and public variables, as well as inherits properties from other locations.
Is this analogy correct?
I think people are probably going to say yes, but I would argue strongly that it is not.
In a C++ class, for example, the data that comprises the class is per-instantiation. In other words classInstance1 and classInstance2 each have their own state.
In Solidity there is only one contract in the program. In this sense the state of the contract is a singleton -- all the state is program-wide level. It's as if the entire class were global. Another way of saying this is that all the data fields of the contract are like C++ static members.
This is exactly why the DAO got hacked. The single DAO contract's state was global, and upon re-entry the same data was being accessed in both the caller and the called into function.
As far as every transaction instantiating an object, that's not quite right. The contract is instantiated on creation and the state persists across transactions.
Yes, a Solidity contract is perfectly analogous to a Java class.
In the same way that a class may be instantiated e.g. 5 times, with each instance’s state residing in volatile computer memory, a contract may be instantiated (deployed) 5 times, with each instance’s state residing in persistent blockchain storage.
Fine, if you instantiate 5 instances of a Java class within the same OS process, the JVM bytecode will be loaded once into volatile computer memory and all 5 instances will share that loaded bytecode, whereas if you instantiate 5 instances of a Solidity contract, the EVM bytecode will be copied to 5 locations in permanent blockchain storage. But this difference doesn’t break the analogy; it just means that instantiating a Solidity contract 5 times is analogous to instantiating a Java class 5 times from a different process each time.
I’ll go one step further: The global RAM address at which a Java class instance’s state resides is analogous (not identical) to the EVM storage address at which a contract resides.
Although Ethereum does treat a contract like an object oriented class, the instance of the class do not reside in the transactions. The instance lives on the blockchain where transactions can make calls to it.
There are different frameworks out there for Ethereum that you can quickly download and get a sense of this with their demo contracts complete w front end code that issues transactions to them. I like both Truffle and Embark: https://github.com/embark-framework/embark
I realized the difference with regards to constructors. In OOP, you can compile your classes, no problem. Then, when you want to instantiate a class, you use the new keyword which calls the class constructor.
In contract-oriented programing (COP), the constructor performs a similar function. Per solidity docs: When a contract is created, its constructor (a function declared with the constructor keyword) is executed once. This is where you can run contract initialization code.
So I believe the constructor function is run on deployment, e.g., when you run truffle migrate. Thus, you need to supply contract arguments. I designed my contracts in an OOP mindset, and so my constructor had args that were to be provided by user input. So having args for contract deployment didn't make sense.
This made me realize that a contract has quite a few nuances from an OOP class.
