ChainSafe / ChainSafe/gossamer
Refactor OfflinePruner to Use Local Interfaces for Database Access
- Dominant language
- Go
- Stars
- 454
- Forks
- 144
- PR merge metrics
- No merged PRs in 30d
Description
## Issue summary
In the OfflinePruner struct, the fields inputDB and filterDatabase are of type database.Database. The database.Database interface contains many methods, but OfflinePruner does not need all of them. Specifically, filterDatabase only needs Get() and Put(), while inputDB only needs Close().
```go
type OfflinePruner struct {
inputDB database.Database
storageState *InmemoryStorageState
blockState *BlockState
filterDatabase database.Database
bestBlockHash common.Hash
retainBlockNum uint32
inputDBPath string
}
```
It is better to define two local interfaces that contain only the methods needed. The benefits of this approach include:
1. [Following Best Practices](https://go.dev/doc/effective_go#interfaces): Adheres to guidelines from the [Go community](https://go.dev/wiki/CodeReviewComments#interfaces)
2. [Interface Segregation Principle](https://en.wikipedia.org/wiki/Interface_segregation_principle):Ensures that clients only depend on the methods they use, promoting a cleaner and more modular design.
3. [Principle of Least Privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege): Reduces access to only necessary methods, minimizing potential for misuse and improving security. Principle of Least Privilege.
4. Reduced External Dependency: Avoids coupling OfflinePruner to the entire database.Database interface, making it resilient to future changes in the database.Database interface.
5. Ensuring Focused Functionality: Prevents types or classes from being burdened with unnecessary functionality.
6. Reduces Complexity: Smaller, focused interfaces are easier to understand and maintain.
7. Enhances Security:Limiting access to only required methods reduces the risk of accidental misuse.
8. Improves Robustness: Fewer methods mean fewer opportunities for bugs or errors.
9. Facilitates Testing: Smaller interfaces are easier to mock and test because there are fewer methods to simulate.
## Related Issues:
#3975
Contributor guide
Research direction
Start at the OfflinePruner struct declaration and inspect its uses of inputDB and filterDatabase. Define local interfaces matching the stated needs—Close() for inputDB and Get()/Put() for filterDatabase; the refactor is done when OfflinePruner depends only on those methods.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- database
- Issue type
- Refactor
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100