Return to Answer

The point of bulkification is to perform an operation (such as a SOQL query) so that a set of records are returned together to help performance. This avoids running into governor limits which in turn are (often) a guard against repeating expensive operations. In the query example, returning 101 records in one request is: one request from the app server to the the database, one query plan generation, one query execution and one response from the database back to the app server. Making 101 separate queries would require all those steps to be repeated 101 times.

There is no need to arrange code executed locally in the app server using similar patterns. Generally simple code that is easily understood is best and Premature Optimization is the root of all evil. So the simpler pattern "snippet 1" is the way to go.

(By the way I'm saying "generally" here because in reality there are rarely "best practices" in the sense that a practice is universally "best". There are often several factors at play and what is best in one situation might not be best in another.)

PS

Before introducing design patterns into your code have a think about some of the pros and cons - see e.g. When should I use—and not use—design patterns?

The point of bulkification is to perform an operation (such as a SOQL query) so that a set of records are returned together to help performance. This avoids running into governor limits which in turn are (often) a guard against repeating expensive operations. In the query example, returning 101 records in one request is: one request from the app server to the the database, one query plan generation, one query execution and one response from the database back to the app server. Making 101 separate queries would require all those steps to be repeated 101 times.

There is no need to arrange code executed locally in the app server using similar patterns. Generally simple code that is easily understood is best and Premature Optimization is the root of all evil. So the simpler pattern "snippet 1" is the way to go.

(By the way I'm saying "generally" here because in reality there are rarely "best practices" in the sense that a practice is universally "best". There are often several factors at play and what is best in one situation might not be best in another.)

PS

Before introducing design patterns into your code have a think about some of the pros and cons - see e.g. When should I use—and not use—design patterns?

The point of bulkification is to perform an operation (such as a SOQL query) so that a set of records are returned together to help performance. This avoids running into governor limits which in turn are (often) a guard against repeating expensive operations. In the query example, returning 101 records in one request is one request from the app server to the the database, one query plan generation, one query execution and one response from the database back to the app server. Making 101 separate queries would require all those steps to be repeated 101 times.

There is no need to arrange general code executed locally in the app server using similar patterns. Generally simple code that is easily understood is best and Premature Optimization is the root of all evil. So the simpler pattern "snippet 1" is generally the way to go.

(By the way I'm saying "generally" here because in reality there are rarely "best practices" in the sense that a practice is universally "best". There are often several factors at play and what is best in one situation might not be best in another.)

PS

Before introducing design patterns into your code have a think about some of the pros and cons - see e.g. When should I use—and not use—design patterns?

The point of bulkification is to perform an operation (such as a SOQL query) so that a set of records are returned together to help performance. This avoids running into governor limits which in turn are (often) a guard against repeating expensive operations. In the query example, returning 101 records in one request is: one request from the app server to the the database, one query plan generation, one query execution and one response from the database back to the app server. Making 101 separate queries would require all those steps to be repeated 101 times.

There is no need to arrange code executed locally in the app server using similar patterns. Generally simple code that is easily understood is best and Premature Optimization is the root of all evil. So the simpler pattern "snippet 1" is the way to go.

(By the way I'm saying "generally" here because in reality there are rarely "best practices" in the sense that a practice is universally "best". There are often several factors at play and what is best in one situation might not be best in another.)

PS

Before introducing design patterns into your code have a think about some of the pros and cons - see e.g. When should I use—and not use—design patterns?

The point of bulkification is to perform an operation (such as a SOQL query) so that a set of records are returned together to help performance. This avoids running into governor limits which in turn are (often) a guard against repeating expensive operations. In the query example, returning 101 records in one request is one request from the app server to the the database, one query plan generation, one query execution and one response from the database back to the app server. Making 101 separate queries would require all those steps to be repeated 101 times.

There is no need to arrange general code executed locally in the app server using similar patterns. Generally simple code that is easily understood is best and Premature Optimization is the root of all evil. So the simpler pattern "snippet 1" is generally the way to go.

(By the way I'm saying "generally" here because in reality there are rarely "best practices" in the sense that a practice is universally "best". There are often several factors at play and what is best in one situation might not be best in another.)

The point of bulkification is to perform an operation (such as a SOQL query) so that a set of records are returned together to help performance. This avoids running into governor limits which in turn are (often) a guard against repeating expensive operations. In the query example, returning 101 records in one request is one request from the app server to the the database, one query plan generation, one query execution and one response from the database back to the app server. Making 101 separate queries would require all those steps to be repeated 101 times.

There is no need to arrange general code executed locally in the app server using similar patterns. Generally simple code that is easily understood is best and Premature Optimization is the root of all evil. So the simpler pattern "snippet 1" is generally the way to go.

(By the way I'm saying "generally" here because in reality there are rarely "best practices" in the sense that a practice is universally "best". There are often several factors at play and what is best in one situation might not be best in another.)

PS

Before introducing design patterns into your code have a think about some of the pros and cons - see e.g. When should I use—and not use—design patterns?