C# coding style, functional approach

Question

I have thought of this for a while and I want to know what you think about this. This is more of a way to structure the code that might not be 100% object oriented and that is not the purpose. I would like to divide the code into Data, UseCases and HelperMethods

Data should be more clean (or "anemic", if you will) objects
UseCases (or business flow) would map to a specific use case
HelperMethods is for pure function that helps the UseCase look cleaner, but is not generic, the logic is mostly used in the usecase. This could have been private static in the UseCase-code, but then you cant use it fluent syntax and you cant unit test them

Example

Data

Customer
{
   public string Name{get;set;}
   ...
}

UseCase

GiveCustomerDiscount
{
    // Read data from db with repo, about customer, previous orders, "isFridayBlack", and so on
    // Process data for customer with help from helper methods that takes data as input and 
    //    what kind of discount as output
    // Update Customer with repo
}

HelperMethod

  // Takes a customer and data and calculates a discount
  //  "Exposes" Extension methods and public static methods

So question: Is this good coding style? Will it bite me, as code base increases? Can I get some more information about this approach or similar?

score 2 · Answer 1 · answered Oct 26 '22 at 12:51

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.

score 0 · Answer 2 · answered Oct 26 '22 at 08:23

First, I would like to clear up terminologies involved.

What you are proposing is called procedural programming. I.e. there are data structures which are essentially global, usually any part of the application can get their hands on any data, and there are procedures (use-cases and helpers) that act on that data in whatever way they want.

This is in contrast to object-orientation, which co-locates data and any logic that acts upon it. Data is not available at all outside of objects, and what "you can do" is severely limited, close to actual valid business cases. It also enables abstraction, since you now do not deal with raw data in every procedure.

Functional programming is even further away than object-orientation to what you propose. FP limits what you can do even further. Not only does it also co-locate data and function, it also forbids you from causing side-effects and forces you to use the type-system even more rigorously to restrict what "you can do" even further. FP people often say: if it compiles it works.

Will it bite me, as code base increases?

Yes, almost certainly. You forgo any chances that things that change together will be together, you make using abstractions really hard and failure prone, and you allow any part of the application to do basically anything it wants.

C# coding style, functional approach

2 Answers2