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
Think you understand the Single Responsibility Principle?
According to Wikipedia SRP means that a class should only have one responsibility, which is further defined by Robert Martin as ‘one reason to change’.
However in this article Robert Martin goes into what he is thinking in rather more depth than usual. In this he gives ‘another wording for the SRP’:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
Read more: https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137
Robert Martin's explanation: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
According to Wikipedia SRP means that a class should only have one responsibility, which is further defined by Robert Martin as ‘one reason to change’.
However in this article Robert Martin goes into what he is thinking in rather more depth than usual. In this he gives ‘another wording for the SRP’:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
Read more: https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137
Robert Martin's explanation: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
API Gateway Pattern
In non-technical terms, "a gateway or a gate is a point of entry to space which is enclosed by walls." Similarly, a gateway in software terminology acts as an entry point to your servers sitting inside a firewall or intranet. In the microservices world, a gateway sits in front of your APIs that are facing clients and acts as a reverse proxy.
API gateways have become one of the key components in the microservices architecture pattern.
Read more: https://dzone.com/articles/gateway-pattern
Spring Cloud implementation: https://www.baeldung.com/spring-cloud-gateway
In non-technical terms, "a gateway or a gate is a point of entry to space which is enclosed by walls." Similarly, a gateway in software terminology acts as an entry point to your servers sitting inside a firewall or intranet. In the microservices world, a gateway sits in front of your APIs that are facing clients and acts as a reverse proxy.
API gateways have become one of the key components in the microservices architecture pattern.
Read more: https://dzone.com/articles/gateway-pattern
Spring Cloud implementation: https://www.baeldung.com/spring-cloud-gateway
Side Effect Methods. Good, Bad and Ugly
Good : Not changing the state of the parameters passed, returning a value from the method.
Bad : Changing the state of the parameters passed, however method does not return a value.
The Ugly: Changing the state of the parameters passed and also returning a value from the method.
https://telegra.ph/Side-Effect-Methods-Good-Bad-and-Ugly-08-13
Good : Not changing the state of the parameters passed, returning a value from the method.
Bad : Changing the state of the parameters passed, however method does not return a value.
The Ugly: Changing the state of the parameters passed and also returning a value from the method.
https://telegra.ph/Side-Effect-Methods-Good-Bad-and-Ugly-08-13
Telegraph
Side Effect Methods. Good, Bad and Ugly
Java methods are blocks of code that can be invoked to execute particular action/logic at a high level. A method can take parameters to be used for the logic in the method. Different invocations can pass different arguments to the method leading to different…
Chain of Responsibility as a design pattern consisting of a source of command objects and a series of processing objects.
Each processing object in the chain is responsible for a certain type of command, and the processing is done, it forwards the command to the next processor in the chain.
The Chain of Responsibility pattern is handy for:
- Decoupling a sender and receiver of a command (loose coupling)
- Picking a processing strategy at processing-time
Details and Java example: https://bit.ly/31ZxGUr
.NET example: https://bit.ly/31Y3RDN
Scala example: https://bit.ly/2DRDXd3
Each processing object in the chain is responsible for a certain type of command, and the processing is done, it forwards the command to the next processor in the chain.
The Chain of Responsibility pattern is handy for:
- Decoupling a sender and receiver of a command (loose coupling)
- Picking a processing strategy at processing-time
Details and Java example: https://bit.ly/31ZxGUr
.NET example: https://bit.ly/31Y3RDN
Scala example: https://bit.ly/2DRDXd3
Martin Fowler describes the Extract Method refactoring pattern like this:
You have a code fragment that can be grouped together.
Turn the fragment into a method whose name explains the purpose of the method.
Details and example: https://refactoring.guru/extract-method
You have a code fragment that can be grouped together.
Turn the fragment into a method whose name explains the purpose of the method.
Details and example: https://refactoring.guru/extract-method
refactoring.guru
Extract Method
Problem: You have a code fragment that can be grouped together.
Solution: Move this code to a separate new method (or function) and replace the old code with a call to the method.
Solution: Move this code to a separate new method (or function) and replace the old code with a call to the method.
Layered Pattern
The layered pattern is probably one of the most well-known software architecture patterns. Many developers use it, without really knowing its name. The idea is to split up your code into “layers”, where each layer has a certain responsibility and provides a service to a higher layer.
Read more: https://towardsdatascience.com/software-architecture-patterns-98043af8028
The layered pattern is probably one of the most well-known software architecture patterns. Many developers use it, without really knowing its name. The idea is to split up your code into “layers”, where each layer has a certain responsibility and provides a service to a higher layer.
Read more: https://towardsdatascience.com/software-architecture-patterns-98043af8028
Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. A system that has achieved eventual consistency is often said to have converged, or achieved replica convergence. Eventual consistency is a weak guarantee – most stronger models, like linearizability are trivially eventually consistent, but a system that is merely eventually consistent does not usually fulfill these stronger constraints.
Eventually-consistent services are often classified as providing BASE (Basically Available, Soft state, Eventual consistency) semantics, in contrast to traditional ACID (Atomicity, Consistency, Isolation, Durability) guarantees.
Wikipedia: https://en.wikipedia.org/wiki/Eventual_consistency
Eventual Consistency in Cassandra: https://blog.imaginea.com/consistency-tuning-in-cassandra/
Eventually-consistent services are often classified as providing BASE (Basically Available, Soft state, Eventual consistency) semantics, in contrast to traditional ACID (Atomicity, Consistency, Isolation, Durability) guarantees.
Wikipedia: https://en.wikipedia.org/wiki/Eventual_consistency
Eventual Consistency in Cassandra: https://blog.imaginea.com/consistency-tuning-in-cassandra/
#refactoring Decompose Conditional
Problem: You have a complex conditional (if-then/else or switch).
Solution: Decompose the complicated parts of the conditional into separate methods: the condition, then and else.
Problem: You have a complex conditional (if-then/else or switch).
Solution: Decompose the complicated parts of the conditional into separate methods: the condition, then and else.
Covariance and contravariance
Understanding of covariance and contravariance is a key to understanding how generics work in different programming languages.
Variance refers to how subtyping between more complex types relates to subtyping between their components. For example, how should a list of Cats relate to a list of Animals? Or how should a function that returns Cat relate to a function that returns Animal?
Covariance means that the subtyping relation of the simple types is preserved for the complex types.
Contravariance means that the subtyping relation of the simple types is reversed for the complex types.
Java explanation: https://dzone.com/articles/covariance-and-contravariance
Why Is Contravariance in Scala so Hard: https://dzone.com/articles/why-is-contravariance-in-scala-so-hard
Variance, Immutability, and Strictness in Kotlin: https://kotlinlang.org/docs/reference/generics.html
Wikipedia: https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
Understanding of covariance and contravariance is a key to understanding how generics work in different programming languages.
Variance refers to how subtyping between more complex types relates to subtyping between their components. For example, how should a list of Cats relate to a list of Animals? Or how should a function that returns Cat relate to a function that returns Animal?
Covariance means that the subtyping relation of the simple types is preserved for the complex types.
Contravariance means that the subtyping relation of the simple types is reversed for the complex types.
Java explanation: https://dzone.com/articles/covariance-and-contravariance
Why Is Contravariance in Scala so Hard: https://dzone.com/articles/why-is-contravariance-in-scala-so-hard
Variance, Immutability, and Strictness in Kotlin: https://kotlinlang.org/docs/reference/generics.html
Wikipedia: https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
Liskov Substitution Principle is the third of Robert C. Martin's SOLID design principles. It extends the Open/Closed principle and enables you to replace objects of a parent class with objects of a subclass without breaking the application. This requires all subclasses to behave in the same way as the parent class.
To achieve that, your subclasses need to follow these rules:
- Don't implement any stricter validation rules on input parameters than implemented by the parent class.
- Apply at the least the same rules to all output parameters as applied by the parent class.
Details and Java examples: https://dzone.com/articles/solid-design-principles-explained-the-liskov-subst
.NET explanation (and ducks example): https://blog.ndepend.com/solid-design-the-liskov-substitution-principle/
To achieve that, your subclasses need to follow these rules:
- Don't implement any stricter validation rules on input parameters than implemented by the parent class.
- Apply at the least the same rules to all output parameters as applied by the parent class.
Details and Java examples: https://dzone.com/articles/solid-design-principles-explained-the-liskov-subst
.NET explanation (and ducks example): https://blog.ndepend.com/solid-design-the-liskov-substitution-principle/
Event Bus Pattern
Imagine having a large scale application containing a lot of components interacting with each other, and you want a way to make your components communicate while maintaining loose coupling and separation of concerns principles, the Event Bus pattern can be a good solution for your problem.
The idea of an Event bus: you have some kind of pipeline and computers connected to it, and whenever one of them sends a message, it’s dispatched to all of the others. Then, they decide if they want to consume the given message or just discard it.
Read more: https://dzone.com/articles/design-patterns-event-bus
Imagine having a large scale application containing a lot of components interacting with each other, and you want a way to make your components communicate while maintaining loose coupling and separation of concerns principles, the Event Bus pattern can be a good solution for your problem.
The idea of an Event bus: you have some kind of pipeline and computers connected to it, and whenever one of them sends a message, it’s dispatched to all of the others. Then, they decide if they want to consume the given message or just discard it.
Read more: https://dzone.com/articles/design-patterns-event-bus
Сommand pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time. This information includes the method name, the object that owns the method and values for the method parameters.
Four terms always associated with the command pattern are command, receiver, invoker and client.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the class of the method or the method parameters.
Java example: https://bit.ly/3mc3I9h
Scala example: https://bit.ly/2FdcrXz
Wikipedia: https://en.wikipedia.org/wiki/Command_pattern
Four terms always associated with the command pattern are command, receiver, invoker and client.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the class of the method or the method parameters.
Java example: https://bit.ly/3mc3I9h
Scala example: https://bit.ly/2FdcrXz
Wikipedia: https://en.wikipedia.org/wiki/Command_pattern
Domain-Driven Design (DDD) is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns. Since then a community of practitioners have further developed the ideas, spawning various other books and training courses. The approach is particularly suited to complex domains, where a lot of often-messy logic needs to be organized.
DDD by Martin Fowler: https://martinfowler.com/bliki/DomainDrivenDesign.html
Getting started with DDD: https://dzone.com/refcardz/getting-started-domain-driven
DDD by Martin Fowler: https://martinfowler.com/bliki/DomainDrivenDesign.html
Getting started with DDD: https://dzone.com/refcardz/getting-started-domain-driven
Daily Pattern (Software Architecture and Design, Refactoring)
Liskov Substitution Principle is the third of Robert C. Martin's SOLID design principles. It extends the Open/Closed principle and enables you to replace objects of a parent class with objects of a subclass without breaking the application. This requires all…
Liskov Substitution Principle in Microservices Architecture
An example where the entities are microservices, and the interface they provide is a REST API. Microservice A will reference B through an API Gateway, and we'll try to comply with LSP: https://dzone.com/articles/the-liskov-substitution-principle-at-an-architectu
An example where the entities are microservices, and the interface they provide is a REST API. Microservice A will reference B through an API Gateway, and we'll try to comply with LSP: https://dzone.com/articles/the-liskov-substitution-principle-at-an-architectu
Replace Type Code with Subclasses #refactoring
Problem:
You have a coded type that directly affects program behavior (values of this field trigger various code in conditionals).
Solution:
Create subclasses for each value of the coded type. Then extract the relevant behaviors from the original class to these subclasses. Replace the control flow code with polymorphism.
https://sapanparikh18.github.io/Refactoring-Part-2/
Problem:
You have a coded type that directly affects program behavior (values of this field trigger various code in conditionals).
Solution:
Create subclasses for each value of the coded type. Then extract the relevant behaviors from the original class to these subclasses. Replace the control flow code with polymorphism.
https://sapanparikh18.github.io/Refactoring-Part-2/
High availability (HA) is a characteristic of a system which aims to ensure an agreed level of operational performance, usually uptime.
Availability refers to the ability of the user to obtain a service, access the system, whether to submit new work, update or alter existing work, or collect the results of previous work.
If a user cannot access the system, it is unavailable. The term downtime is used to refer to periods when a system is unavailable.
What is High Availability: https://do.co/2RHh4fD
Wikipedia: https://en.wikipedia.org/wiki/High_availability
Availability refers to the ability of the user to obtain a service, access the system, whether to submit new work, update or alter existing work, or collect the results of previous work.
If a user cannot access the system, it is unavailable. The term downtime is used to refer to periods when a system is unavailable.
What is High Availability: https://do.co/2RHh4fD
Wikipedia: https://en.wikipedia.org/wiki/High_availability
Daily Pattern (Software Architecture and Design, Refactoring)
Сommand pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time. This information includes the method name, the object that owns the method and values…
Command Pattern vs Strategy Pattern
Command pattern is used to make an object out of what needs to be done — to take an operation and its arguments and wrap them up in an object to be logged, held for undo, sent to a remote site, etc.
Strategy pattern, on the other hand, is used to specify how something should be done, and plugs into a larger object or method to provide a specific algorithm.
Details: https://miafish.wordpress.com/2015/01/16/command-pattern-vs-strategy-pattern/
Command pattern is used to make an object out of what needs to be done — to take an operation and its arguments and wrap them up in an object to be logged, held for undo, sent to a remote site, etc.
Strategy pattern, on the other hand, is used to specify how something should be done, and plugs into a larger object or method to provide a specific algorithm.
Details: https://miafish.wordpress.com/2015/01/16/command-pattern-vs-strategy-pattern/
Split Temporary Variable #refactoring
Problem
You have a local variable that’s used to store various intermediate values inside a method (except for cycle variables).
Solution
Use different variables for different values. Each variable should be responsible for only one particular thing.
Why Refactor
If you’re reusing variables inside a function for various unrelated purposes, you’re sure to encounter problems as soon as you need to make changes to the code containing the variables. You will have to recheck each case of variable use to make sure that the correct values are used.
Benefits
- Each component of the program code should be responsible for one and one thing only.
- Code becomes more readable.
- This refactoring technique is useful if you anticipate using Extract Method later.
P. S. In Scala and Kotlin it's best practice to use val (final in Java) instead of var as much and possible so you will never have this problem.
Problem
You have a local variable that’s used to store various intermediate values inside a method (except for cycle variables).
Solution
Use different variables for different values. Each variable should be responsible for only one particular thing.
Why Refactor
If you’re reusing variables inside a function for various unrelated purposes, you’re sure to encounter problems as soon as you need to make changes to the code containing the variables. You will have to recheck each case of variable use to make sure that the correct values are used.
Benefits
- Each component of the program code should be responsible for one and one thing only.
- Code becomes more readable.
- This refactoring technique is useful if you anticipate using Extract Method later.
P. S. In Scala and Kotlin it's best practice to use val (final in Java) instead of var as much and possible so you will never have this problem.
CQRS Architectural Pattern
CQRS is an acronym for Command and Query Responsibility Segregation. The central concept of this pattern is that an application has read operations and write operations that must be totally separated. This also means that the model used for write operations (commands) will differ from the read models (queries). Furthermore, the data will be stored in different locations. In a relational database, this means there will be tables for the command model and tables for the read model. Some implementations even store the different models in totally different databases, e.g. SQL Server for the command model and MongoDB for the read model.
Martin Fowler explanation: https://martinfowler.com/bliki/CQRS.html
Understanding From First Principles: https://blog.ndepend.com/cqrs-understanding-first-principles/
CQRS: What? Why? How? https://medium.com/@sderosiaux/cqrs-what-why-how-945543482313
CQRS is an acronym for Command and Query Responsibility Segregation. The central concept of this pattern is that an application has read operations and write operations that must be totally separated. This also means that the model used for write operations (commands) will differ from the read models (queries). Furthermore, the data will be stored in different locations. In a relational database, this means there will be tables for the command model and tables for the read model. Some implementations even store the different models in totally different databases, e.g. SQL Server for the command model and MongoDB for the read model.
Martin Fowler explanation: https://martinfowler.com/bliki/CQRS.html
Understanding From First Principles: https://blog.ndepend.com/cqrs-understanding-first-principles/
CQRS: What? Why? How? https://medium.com/@sderosiaux/cqrs-what-why-how-945543482313