CAP theorem means if there is network partition and if you want your system to keep functioning you can provide either Availability or Consistency and not both.
Understanding the CAP theorem: https://dzone.com/articles/understanding-the-cap-theorem
Understanding the CAP theorem: https://dzone.com/articles/understanding-the-cap-theorem
Design Patterns Used in JDK
https://ageekview.wordpress.com/2011/05/08/a-dive-into-design-patterns-used-in-jdk-i/
https://ageekview.wordpress.com/2011/05/08/a-dive-into-design-patterns-used-in-jdk-i/
Write-ahead logging
In a system using WAL (write-ahead logging), all modifications are written to a log before they are applied. Usually both redo and undo information is stored in the log.
Example. Imagine a program that is in the middle of performing some operation when the machine it is running on loses power. Upon restart, that program might need to know whether the operation it was performing succeeded, succeeded partially, or failed. If a write-ahead log is used, the program can check this log and compare what it was supposed to be doing when it unexpectedly lost power to what was actually done. On the basis of this comparison, the program could decide to undo what it had started, complete what it had started, or keep things as they are.
WAL in Spark Streaming: https://bit.ly/2Otr22i
WAL in MySQL: https://bit.ly/2B8EN3E
In a system using WAL (write-ahead logging), all modifications are written to a log before they are applied. Usually both redo and undo information is stored in the log.
Example. Imagine a program that is in the middle of performing some operation when the machine it is running on loses power. Upon restart, that program might need to know whether the operation it was performing succeeded, succeeded partially, or failed. If a write-ahead log is used, the program can check this log and compare what it was supposed to be doing when it unexpectedly lost power to what was actually done. On the basis of this comparison, the program could decide to undo what it had started, complete what it had started, or keep things as they are.
WAL in Spark Streaming: https://bit.ly/2Otr22i
WAL in MySQL: https://bit.ly/2B8EN3E
Open/Closed Principle and Strategy Pattern
The Open Closed Principle: Software entities should be open to extension but closed to modification.
Strategy Pattern: behavioural software design pattern that enables selecting an algorithm at runtime.
About Open/Closed Principle and how to achieve it with Strategy Pattern: https://dzone.com/articles/the-openclosed-principle
The Open Closed Principle: Software entities should be open to extension but closed to modification.
Strategy Pattern: behavioural software design pattern that enables selecting an algorithm at runtime.
About Open/Closed Principle and how to achieve it with Strategy Pattern: https://dzone.com/articles/the-openclosed-principle
Java Records
Records - classes that act as transparent carriers for immutable data. Records can be thought of as nominal tuples. Similar structures in Kotlin: data classes, in Scala: case classes.
Records were proposed in mid 2019 and delivered in JDK 14 in early 2020 as a preview feature. This JEP 384 proposes to re-preview the feature in JDK 15 (will be released in August).
A closer look at Records: https://dzone.com/articles/java-records-a-closer-look
Records - classes that act as transparent carriers for immutable data. Records can be thought of as nominal tuples. Similar structures in Kotlin: data classes, in Scala: case classes.
Records were proposed in mid 2019 and delivered in JDK 14 in early 2020 as a preview feature. This JEP 384 proposes to re-preview the feature in JDK 15 (will be released in August).
A closer look at Records: https://dzone.com/articles/java-records-a-closer-look
Very often people think that function (method) should be extracted only to move duplicated code into one place. But it's only one reason.
#CleanCode Function Rules
- Small (function should be as small as possible)
- Do one thing (single responsibility principle for function)
- Use descriptive names (function name should describe what function does)
- Prefer fewer arguments
- Have no side effects (function should not change variables outside its scope)
- Don't use flag arguments (split method into several independent methods that can be called from the client without the flag)
Details and example: https://dzone.com/articles/clean-code-functions
#CleanCode Function Rules
- Small (function should be as small as possible)
- Do one thing (single responsibility principle for function)
- Use descriptive names (function name should describe what function does)
- Prefer fewer arguments
- Have no side effects (function should not change variables outside its scope)
- Don't use flag arguments (split method into several independent methods that can be called from the client without the flag)
Details and example: https://dzone.com/articles/clean-code-functions