Feature/schema function independent #102
Draft
+369
−416
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As part of this pull request,
DBSchema
has been made an optional constructor parameter ofDBFunction
. Additionally, the logic for deriving thefunctionName
has been updated.Separating the concerns of function name derivation between
DBSchema
andDBFunction
is beneficial for a few reasons:Decoupling: By separating these concerns,
DBFunction
doesn't need to know the details of how the schema name is derived. It just needs to know that it can get a schema name fromDBSchema
. This decoupling makes the code more modular and easier to change. It also means that changes to how the schema name is derived won't affect theDBFunction
class, and vice versa.Consistency: By centralizing the logic for function name derivation in
DBFunction
, you ensure that the same logic is used consistently across all instances ofDBFunction
. This can help prevent bugs and inconsistencies that might arise if different parts of the codebase were deriving function names in different ways.Flexibility: The
DBFunction
class can be used with or without aDBSchema
. By separating the concerns of function name derivation, you allow for greater flexibility in howDBFunction
instances are created.Code Reusability: The logic for deriving the function name is encapsulated in
DBFunction
. This means that the same logic can be reused for allDBFunction
instances, regardless of whether they have aDBSchema
or not.Ease of Testing: With separated concerns, it's easier to write unit tests for each class. You can test the schema name derivation logic in
DBSchema
independently of the function name derivation logic inDBFunction
.Separating the concerns of function name derivation between
DBSchema
andDBFunction
leads to more modular, consistent, flexible, and testable code.