Closed phelps-sg closed 3 years ago
This class is just a POJO. BitcoinUtil contains methods to calculate hashes and there would be the right place. Hence, I suggest to add them to the class BitcoinUtil
This makes the class more lightweight for analytics in Big Data platform. For example, if you have one million blocks you want to avoid that they contain the function for calculating the hash 1 million times. It reduces the memory footprint significantly.
Java methods do not incur a per-instance memory overhead. See https://stackoverflow.com/questions/6909414/do-methods-in-class-instances-take-a-place-in-memory.
By most definitions, a POJO is allowed to have methods.
Unless you have a very good reason, it is better to follow good OO practice and follow standard encapsulation principles.
I propose for compatibility reasons we can start as I suggested - as this is already now the case for other methods calculating hashes. One can later see it if it is worth to do a breaking change and do it differently. Standard encapsulation principles are not violated by neither of the approaches.
Standard encapsulation principles are not violated by neither of the approaches.
This is simply not true. Encapsulation literally means bundling data with the operations that operate on that data. See the 'Bundling data and methods' section of https://www.infoworld.com/article/2075271/encapsulation-is-not-information-hiding.html.
Please do not work on any issues before it has been agreed and discussed. Otherwise we cannot accept pull requests.
The class
org.zuinnote.hadoop.bitcoin.format.common.Block
does not have methods to calculate the block hash. Calculating the block hash also requires calculation of the Merkle root, which is also not implemented. Without this functionality it is not possible to determine the height of a block.