How would this be programmed in non-OO? [closed]

What I'm specifically asking is how would this example be modelled/programmed in a FP language (Actual code, not theoretically)?

In "a" FP language? If any suffices, then I pick Emacs lisp. It does have the concept of types (kind of, sort of), but only built-in ones. So your example reduces to "how do you multiply each item in a list by something and return a new list".

(mapcar (lambda (x) (* x 2)) '(1 2 3)) 

There you go. Other languages will be similar, with the difference that you get th benefit of explicit types with the usual functional "matching" semantics. Check out Haskell:

incPrice :: (Num) -> [Num] -> [Num] incPrice _ [] = [] incPrice percentage (x:xs) = x*percentage : incPrice percentage xs 

(Or something like that, it has been ages...)

I want to be open to the author's arguments,

Why? I tried to read the article; I had to give up after a page and just quickly scanned the rest.

The problem of the article is not that it's against OOP. Neither am I blindly "pro OOP". I have programmed with logic, functional and OOP paradigms, quite often in the same language when possible, and frequently without any of the three, purely imperative or even on the assembler level. I would never say that any of those paradigms is vastly superiour to the other in every aspect. Would I argue that I like language X better then Y? Of course I would! But that is not what that article is about.

The problem of the article is that he uses an abundance of rhetoric tools (fallacies) from the first to the last sentence. It is completely futile to even begin to describe all the errors it contains. The author makes it abundantly clear that he has zero interest in discussion, he is on a crusade. So why bother?

At the end of the day all those things are just tools to get a job done. There may be jobs where OOP is better, and there may be other jobs where FP is better, or where both are overkill. The important thing is to pick the right tool for the job, and get it done.

The author made a very good point then chose a lackluster example to attempt to back it up. The complaint isn't with the implementation of the class, it's with the idea that the data hierarchy is inextricably coupled with the function hierarchy.

It follows then, that to understand the author's point, it wouldn't help to only see how he would implement this single class in a functional style. You would have to see how he would design the entire context of data and functions around this class in a functional style.

Think about the potential data types involved in products and pricing. To brainstorm a few: name, upc code, category, shipping weight, price, currency, discount code, discount rule.

This is the easy part of object-oriented design. We just make a class for all of the above "objects" and we're good, right? Make a Product class to combine a few of them together?

But wait, you can have collections and aggregates of some of those types: Set[category], (discount code -> price), (quantity -> discount amount), and so forth. Where do those fit in? Do we create a separate CategoryManager to keep track of all the different kinds of categories, or does that responsibility belong to the Category class we already created?

Now what about functions that give you a price discount if you have a certain quantity of items from two different categories? Does that go in the Product class, the Category class, the DiscountRule class, the CategoryManager class, or do we need something new? This is how we end up with things like DiscountRuleProductCategoryFactoryBuilder.

In functional code, your data hierarchy is completely orthogonal to your functions. You can sort your functions in whatever manner makes semantic sense. For example, you might group all the functions that change the prices of products together, in which case it would make sense to factor out common functionality like the mapPrices in the following Scala example:

def mapPrices(f: Int => Int)(products: Traversable[Product]): Traversable[Product] = products map {x => x.copy(price = f(x.price))} def increasePrice(percentage: Int)(price: Int): Int = price * (percentage + 100) / 100 mapPrices(increasePrice(25))(products) 

I could probably add other price-related functions here like decreasePrice, applyBulkDiscount, etc.

Because we also use a collection of Products, the OOP version needs to include methods to manage that collection, but you didn't want this module to be about product selection, you wanted it to be about prices. The function-data coupling forced you to throw collection management boilerplate in there too.

You can try to solve this by putting the products member in a separate class, but then you end up with very tightly-coupled classes. OO programmers think of function-data coupling as very natural and even beneficial, but there is a high cost associated with it in loss of flexibility. Anytime you create a function, you must assign it to one and only one class. Anytime you want to use a function, you must find a way to get its coupled data to the point of use. Those restrictions are huge.

Simply separating the data and function as the author was alluding to could look like this in F# ("a FP language").

module Product = type Product = { Price : decimal ... // other properties not mentioned } let increasePrice ( percentage : int ) ( product : Product ) : Product = let newPrice = ... // calculate { product with Price = newPrice } 

You can perform a price increase on a list of products this way.

let percentage = 10 let products : Product list = ... // load? products |> List.map (Product.increasePrice percentage) 

Note: If you are not familiar with FP, every function returns a value. Coming from a C-like language, you can treat the last statement in a function as though it had a return in front of it.

I included some type annotations, but they should be unnecessary. getter/setter are unnecessary here since the module doesn't own the data. It owns the structure of the data and the available operations. This can be seen with List as well, which exposes map to run a function on every element in the list, and returns the result in a new list.

Notice that the Product module doesn't have to know anything about looping, as that responsibility stays with the List module (who created the need for looping).

Let me preface this with the fact that I'm not an expert on functional programming. I'm more of an OOP person. So while I'm pretty sure the below is how you would accomplish the same sort of functionality with FP, I could be wrong.

This is In Typescript (hence all the type annotations). Typescript (like javascript) is a multi-domain language.

export class Product extends Object { name: string; price: number; category: string; } products: Product[] = [ new Product( { name: "Tablet", "price": 20.99, category: 'Electronics' } ), new Product( { name: "Phone", "price": 500.00, category: 'Electronics' } ), new Product( { name: "Car", "price": 13500.00, category: 'Auto' } ) ]; // find all electronics and double their price let newProducts = products .filter( ( product: Product ) => product.category === 'Electronics' ) .map( ( product: Product ) => { product.price *= 2; return product; } ); console.log( newProducts ); 

In detail (and again, not an FP expert), the thing to understand is that there isn't a lot of pre-defined behavior. There isn't an "increase price" method that applies a price increase across the whole list, because of course this isn't OOP: there is no class in which to define such behavior. Instead of creating an object that stores a list of products, you just create an array of products. You can then use standard FP procedures to manipulate this array in whatever way you desire: filter to select particular items, map to adjust internals, etc... You end with more detailed control over your list of products without having to be limited by the API that the SimpleProductManager gives you. This may be considered an advantage by some. It is also true that you don't have to worry about any baggage associated with the ProductManager class. Finally, there is no worry about "SetProducts" or "GetProducts", because there is no object that is hiding your products: instead, you just have the list of products that you are working with. Again, this may be an advantage or disadvantage depending on the circumstances/person you are talking to. Also, there is obviously no class hierarchy (which is what he was complaining about) because there are no classes in the first place.

I didn't take the time to read his entire rant. I do use FP practices when it is convenient, but I am definitely more of an OOP kind of guy. So I figured since I answered your question, I would also make some brief comments about his opinions. I think this is a very contrived example that highlights the "downsides" of OOP. In this particular case, for the functionality shown, OOP probably is over-kill, and FP would probably be a better fit. Then again, if this were for something like a shopping cart, protecting your products list and limiting access to it is (I think) a very important goal of the program, and FP has no way to enforce such things. Again, it may just be that I'm not an FP expert, but having implemented shopping carts for e-commerce systems, I would much rather use OOP than FP. The encapsulation principles in OOP give you much more control to make sure that things are modified properly, that you always move from one valid state to another, and that your shopping cart is always properly up-to-date.

Personally I have a hard time taking anyone seriously that makes such a strong argument for "X is just terrible. Always use Y". Programming has a variety of tools and paradigms because there are a wide variety of problems to solve. FP has its place, OOP has its place, and no one is going to be a great programmer if they can't understand the drawbacks and advantages of all our tools and when to use them.

**note: Obviously there is one class in my example: the Product class. In this case though it is simply a dumb data container: I don't think my use of it violates the principles of FP. It is more of a helper for type checking.

**note: I don't remember off the top of my head and didn't check if the way I used the map function would modify the products in-place, i.e. did I inadvertently double the price of the products in the original products array. That obviously is the sort of side effect that FP tries to avoid, and with a bit more code I could certainly make sure it doesn't happen.

It does not seem to me the SimpleProductManager is child (extends or inherits) of something.

Its just implementation of the ProductManager interface which is basically a contract defining what actions (behaviors) the object have to do.

If it would be a child (or better said, iherited class or class extending another class functionality) it would be written as:

class SimpleProductManager extends ProductManager { ... } 

So basically, the author says:

Whe have some object which behavior is: setProducts, increasePrice, getProducts. And we don't care if the object has another behavior too or how the behavior is implemented.

The SimpleProductManager class implements it. Basically, it executes actions.

It can be also called PercentagePriceIncreaser as its main behavior is to increase the price by some percentage value.

But we can also implement another class: ValuePriceIncreaser which behavor will be:

public void increasePrice(int number) { if (products != null) { for (Product product : products) { double newPrice = product.getPrice() + number; product.setPrice(newPrice); } } } 

From external point of view, nothing has changed, the interface is the same, still have same three methods but the behavior is different.

As there is no such thing as interfaces in FP it would be hard to implement. In C, for example, we can hold pointers to functions and call appropriate one based on our needs. In the end, in OOP it works in very very similar way, but its "automated" by the compiler.