C# coding style, functional approach was closed for being opinion-based.
But consider what was really being asked here. We were presented a development plan and asked if any problems are already apparent.
Answering that requires an experienced eye looking at the plan. It doesn't require an entire book.
For what it's worth here's how I would have answered:
Will it bite me as code base increases?
Things that may bite you:
Customer
{
public string Name{get;set;}
...
}
Public setter indicates shared mutable state. Could be problematic for readability, debugging, or in a concurrent environment. Prefer immutable where possible.
HelperMethods is a poor name for a class or package. I need names that tell me what does and doesn't belong inside. Resist the temptation to leave your pure functions languishing under meaningless names. Good names organize code. As your functions grow in number step back and look at them together and think about better ways to organize them.
A fluent syntax doesn't require static. Neither do pure functions. Static means static. You can choose to use static for this but static isn't giving you purity or fluency. You have to do that yourself.
Consider this example: =
Nutrition secretFormula(Nutrition nutrition) {
return nutrition
.Builder(240, 8)
.calories(100)
.sodium(35)
.carbohydrate(27)
.build()
;
}
Because this code takes a reference to Nutrition rather than reach out to it statically it doesn't actually know what implementation of Nutrition it's talking to. That means this code doesn't need to be touched if you need to change how Nutrition works. Sure the new version of Nutrition has to be backwards compatible with this code, but it's engine is free to do with this whatever it likes.
Opinion based? No more than a code review. I see a potential problem, I say something about it. And it's not a whole book. Just a response to a development plan. Can we really not handle questions like this?
