4 ms·
F# is a Functional/OOP language. In this case the original code had a class like: class DeliveryItem { public bool isTagged { get; set; }
by banashark 9y ago
F# is a Functional/OOP language.
In this case the original code had a class like:
class DeliveryItem {
public bool isTagged { get; set; }
public Deliverer previousDeliverer { get; set; }
public Deliverer nextDeliverer { get; set; }
public string itemName { get; set; }
public DateTime lastTransferTime { get; set; }
}
The code would take a single DeliveryItem and each time something used it, it would update the properties on it.
While not ideal, this worked fine if pipeline was an ordered sequence.
The pipeline had grown into a complex graph, with many different possible states, and new properties were incrementally added to shoehorn the new states and transfers between states into the single object.
The class grew large and it became difficult to determine from logs what path of the pipeline that an item had taken. It could have been scanned, weight analyzed, compaction determined, etc, etc. And these didn't always happen in the same order because of the business process.
Instead I created types like `NewDeliveryItem`, `PreProcessedDeliveryItem`, `ThirdPartyVerifiedDeliveryItem`, etc.
It allowed for explicit modeling of the pipeline, since functions could take a `PreProcessedDeliveryItem` instead of a `DeliveryItem` and would know that they wouldn't need to send it for processing.
The example has been translated a bit and isn't the best explanation, but gives a small amount of detail.
You can check out https://fsharpforfunandprofit.com/series/designing-with-types.html https://fsharpforfunandprofit.com/series/designing-with-type... and https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/ to get more information on how this can decomplect seemingly simple applications.