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
The actor model in computer science is a mathematical model of concurrent computation that treats actor as the universal primitive of concurrent computation.
An actor is a computational entity that, in response to a message it receives, can concurrently:
- send a finite number of messages to other actors;
- create a finite number of new actors;
- designate the behavior to be used for the next message it receives.
Based on message passing technique.
The most popular implementations:
Java/Scala - Akka
.NET - Akka.NET
Actor model in wiki: https://en.wikipedia.org/wiki/Actor_model
The actor model in 10 minutes: https://www.brianstorti.com/the-actor-model/
An actor is a computational entity that, in response to a message it receives, can concurrently:
- send a finite number of messages to other actors;
- create a finite number of new actors;
- designate the behavior to be used for the next message it receives.
Based on message passing technique.
The most popular implementations:
Java/Scala - Akka
.NET - Akka.NET
Actor model in wiki: https://en.wikipedia.org/wiki/Actor_model
The actor model in 10 minutes: https://www.brianstorti.com/the-actor-model/
KISS principle
KISS, an acronym for "keep it simple, stupid" or "keep it stupid simple", is a design principle. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
A Detailed Explanation of The KISS Principle in Software: https://thevaluable.dev/kiss-principle-explained/
KISS, an acronym for "keep it simple, stupid" or "keep it stupid simple", is a design principle. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
A Detailed Explanation of The KISS Principle in Software: https://thevaluable.dev/kiss-principle-explained/
Circuit Breaker Pattern
Circuit Breaker pattern is used to detect failures and encapsulates the logic of preventing a failure from constantly recurring, during maintenance, temporary external system failure or unexpected system difficulties.
In simple words: allows us to save resources when we know a remote service failed. Useful when all parts of our application are highly decoupled from each other, and failure of one component doesn't mean the other parts will stop working.
Details and Spring example: https://dzone.com/articles/circuit-breaker-pattern
Martin Fowler's explanation: https://martinfowler.com/bliki/CircuitBreaker.html
Circuit Breaker pattern is used to detect failures and encapsulates the logic of preventing a failure from constantly recurring, during maintenance, temporary external system failure or unexpected system difficulties.
In simple words: allows us to save resources when we know a remote service failed. Useful when all parts of our application are highly decoupled from each other, and failure of one component doesn't mean the other parts will stop working.
Details and Spring example: https://dzone.com/articles/circuit-breaker-pattern
Martin Fowler's explanation: https://martinfowler.com/bliki/CircuitBreaker.html
The Open-Closed Principle at an Architectural Level
At a class level, the Open-Closed Principle (OCP) states that a class is opened for extension but closed to modification, meaning that you should be able to extend a class's behavior without modifying it. This is usually done by extending the class, either using inheritance or composition.
At an architectural level, we are not trying to modify the functionality of a piece of the system (a process, daemon, service, or microservice that best suits your architecture) but, instead, add new pieces leveraging the work you've already done.
Read more: https://dzone.com/articles/the-open-closed-principle-at-an-architectural-leve
At a class level, the Open-Closed Principle (OCP) states that a class is opened for extension but closed to modification, meaning that you should be able to extend a class's behavior without modifying it. This is usually done by extending the class, either using inheritance or composition.
At an architectural level, we are not trying to modify the functionality of a piece of the system (a process, daemon, service, or microservice that best suits your architecture) but, instead, add new pieces leveraging the work you've already done.
Read more: https://dzone.com/articles/the-open-closed-principle-at-an-architectural-leve
A flag argument is a kind of function argument that tells the function to carry out a different operation depending on its value.
Why it is bad and how to avoid it: https://8thlight.com/blog/dariusz-pasciak/2015/05/28/alternatives-to-boolean-parameters.html
Why it is bad and how to avoid it: https://8thlight.com/blog/dariusz-pasciak/2015/05/28/alternatives-to-boolean-parameters.html