Very good example.
What goes through the sale function pipe is not the store and its size, it really does not matter for the meaning of sale were the sale happened. What matter for the sale is the cart. The cart might be more or less sofisticated because the size of the store, but is still a cart.
So the sale function is a pipe that eats a cart and spits out a receipt.
Or if you want to put it in another way, a sale is something that might happen to a cart over time. Functions are the clock on the system. In a functional system, times does not pass until a function is executed (does it sounds like lazy evaluation?)
In functional programming, we avoid duplication of code by appliying functions to the data so it spits what the next function needs. If you have a function sale that can eat a simple cart, but now you have a complex cart, one solution is to create a function that converts the complex cart into the simple one that the sale function needs; another way is to make the complex cart having the same data as the simpler cart. What you choose to do is proportional to how different the meaning of cart is, or maybe the cart remains the same. In general terms, this type of thinking tend to produce less lines of code needed per similar acomplishment.
So in OOP your are using objects to put together the store, while in FP your are descriving what happens in the store by connecting pipes betweem the different data. It is not about what can happen to the data, but what makes the data travel. It is not about what steps makes it work, but the fluidity of the data life span.
What goes through the sale function pipe is not the store and its size, it really does not matter for the meaning of sale were the sale happened. What matter for the sale is the cart. The cart might be more or less sofisticated because the size of the store, but is still a cart.
So the sale function is a pipe that eats a cart and spits out a receipt.
Or if you want to put it in another way, a sale is something that might happen to a cart over time. Functions are the clock on the system. In a functional system, times does not pass until a function is executed (does it sounds like lazy evaluation?)
In functional programming, we avoid duplication of code by appliying functions to the data so it spits what the next function needs. If you have a function sale that can eat a simple cart, but now you have a complex cart, one solution is to create a function that converts the complex cart into the simple one that the sale function needs; another way is to make the complex cart having the same data as the simpler cart. What you choose to do is proportional to how different the meaning of cart is, or maybe the cart remains the same. In general terms, this type of thinking tend to produce less lines of code needed per similar acomplishment.
So in OOP your are using objects to put together the store, while in FP your are descriving what happens in the store by connecting pipes betweem the different data. It is not about what can happen to the data, but what makes the data travel. It is not about what steps makes it work, but the fluidity of the data life span.