What is the problem with Object Oriented Programming?

OOP is bad:

OO idioms and practices encourage coupling. For example, in Java, if you want behavior you are forced to create a class. In OO instruction classes are often introduced as containers of state. So it’s no surprise that in OO systems you typically find data and behavior mashed together. For example:

class Person {
private String firstName, lastName;
private int age;

public boolean isAboveDrinkingAge() {
return age > DRINKING_AGE;
}
}
This type of design is par for the course for many software systems (with very smart people behind them!). Why is this atrocious? The behavior — isAboveDrinkingAge — is not mobile. As soon as I get the creative idea of asking if my Cat is of drinking age, I can’t reuse this behavior. (Call that idea insane, but a good software system will be poised to entertain all of your crazy ideas.)

It is bad partly because it is imperative instead of declarative:

A more imperative-oriented version of this program might look like this:

public class Program {

public doMain(String[] args) {
List tokens = parse(args[0]);
List people = Lists.newArrayList();
for (Token token : tokens) {
Xml xml = toXml(token);
Person person = new Person();
person.copyDetailsFrom(xml);
people.add(person.encrypt());
}
OutputStream cloud = cloudEndpoint();
for (Person person : people) {
cloud.write(person);
}
}

}
This is behaviorally identical to the declarative program but it is obsessed with process; it’s imperative. You can see the bullying hand of OO here — the obsession with Objects and comingling of behaviors and data. Programs like this are very hard to change, maintain, and understand.

Functional programming is better:

How easily can you move parts of your code around? How easily can you modify or share your code’s behaviors? This is the crux of good code. If you can’t isolate and decouple behavior in your system, over time that system will grow in size and complexity. These kinds of systems are ones that couple data and behavior and couple behaviors to each other.

Business demands that software systems frequently reconfigure their behaviors — to make room for new behaviors or simply to change how the overall system works — and to delete behaviors that are no longer needed. This is all reasonably done in a system where behaviors are distinct and separate but very difficult in systems with high coupling.