函数式编程?别费力气了,它就是个愚蠢的玩具

本文批判了函数式编程,认为其无法满足复杂的企业需求,不具有未来可行性,且易导致生产力下降。作者强调面向对象编程在抽象、企业级需求和未来扩展性方面的优势,并指出函数式编程的简化重构和声明性代码可能导致资源浪费。文章以讽刺手法阐述,主张开发者应专注于面向对象编程以提高生产力。
摘要由CSDN通过智能技术生成

Functional Programming? Don’t Even Bother, It’s a Silly Toy

函数式编程?别费力气了,它就是个愚蠢的玩具


提示:本博文可能不再更新
请移步我的公众号:跃寒或个人主页

Jul 29

原文

It will make your productivity plummet
它会使得你的生产力直线下降


Perhaps you’ve heard of so-called “functional” programming. Maybe you’ve even been wondering whether you should try it next.

也许你已经听说过所谓的函数式编程。可能你已经想接下来你是否应该尝试一下

The short answer is hell no!

简短的回答是不

Functional programming is full of flaws, is not suitable for real-world projects, and will make your productivity plummet. Why? Keep reading to find out!

函数式编程充满了缺陷,它不适合真实环境中的项目,也会使得你的生产力直线下降。why? 继续读下去,你会找到答案的


Functional Programming is Unable to Fulfill Complex Enterprise Requirements

函数式编程不能满足复杂的企业需求

Real-world enterprise software demands a complex set of rigorous and compulsory requirements pertaining to the expected amount of embedded abstractions within the software solution.
真实环境的企业软件需要一套复杂的严格和强制的要求,这与软件解决方案中的预期嵌入式抽象数量有关
In other words, object-oriented programming enables the programmer to utilize multiple mechanisms of abstraction that fully satisfy the complex requirements demanded by the enterprise.
换句话说,面向对象编程能够使得程序员利用多种抽象方案来完全满足企业所要求的复杂需求

That was a mouthful, but bear with me! Things will become crystal-clear in a moment.

这有些拗口,请容忍我!事情马上会清明如水。

So-called “functional” programming has no proper mechanism of abstraction since it is based on mathematics (which obviously is inferior and has no applications in the real world apart from academia). Unlike OOP, functional programming makes no attempt to fulfill the numerous rigorous and complex requirements demanded by the enterprise.

所谓的函数式编程没有合适的抽象机制,因为它基于数学(显然是低级的,除了学术之外没有任何现实中的应用)。与面向对象编程不同,函数式编程不会尝试满足企业所要求的大量的严格且复杂的需求。

This code snippet to demonstrates the issues prevalent with functional programming:

这个代码片段说明了函数式编程中普遍存在的问题:

  import { filter, first, get } from 'lodash/fp';
    ​
    const filterByType = type =>
      filter( x => x.type === type );
    ​
    const fruits = [
      { type: 'apple', price: 1.99 },
      { type: 'orange', price: 2.99 },
      { type: 'grape', price: 44.95 }  
    ];
    ​
    const getFruitPrice = type => fruits =>
      fruits
      |> filterByType(type)
      |> first
      |> get('price');
    ​
    const getApplePrice = getFruitPrice('apple');
    ​
    console.log('apple price', getApplePrice(fruits));
    If this makes you angry, you’are not alone!

如果它让你很烦,你并不是唯一有此感觉的人

Functional programming makes no attempt to properly abstract and encapsulate the functionality, as typically is demanded by any serious enterprise.
函数式编程不会企图合适地抽象和封装函数,这通常是任何严肃的企业所要求的。

No self-respecting software engineer would ever write anything like this! If they do, then immediately they should be fired by any seriously large enterprise to prevent further damage. In the next section, we’ll take a look at a properly abstracted OOP program.

任何有自尊心的软件工程师都不会如此写代码!否则,他们会立即被任何大公司解雇以避免更深层次的灾难。下个小节,我们将看到合适的抽象面向对象编程


Functional Software Solutions Aren’t Future-Proof

函数式软件解决方案不会不过时

It’s no secret that the foremost duty of any professional and self-respecting software engineer is to write future-proof code that satisfies complex business requirements.
众所周知,任何专业且有自尊的软件工程师的首要义务是写不会过时的满足复杂业务需求的代码

In contrast with the disastrous functional code snippet above, let’s take a quick look at a properly abstracted OOP program. It does the same thing, but in an abstract and a future-proof way:
与上面的灾难性的函数式代码片段相比,让我们快速浏览一个合适地抽象的面向对象编程程序,它做了相同的事,但用来一种抽象且不过时的方式:

class Fruit {
  constructor(type, price) {
    this.type = type;
    this.price = price;
  }
}
​
class AbstractFruitFactory {
  make(type, price) {
    return new Fruit(type, price);
  }
}
​
class AppleFactory extends AbstractFruitFactory {
  make(price) {
    return super.make("apple", price);
  }
}
​
class OrangeFactory extends AbstractFruitFactory {
  make(price) {
    return super.make("orange", price);
  }
}
​
class GrapeFactory extends AbstractFruitFactory {
  make(price) {
    return super.make("grape", price);
  }
}
​
class FruitRepository {
  constructor() {
    this.fruitList = [];
  }
​
  locate(strategy) {
    return strategy.locate(this.fruitList);
  }
​
  put(fruit) {
    this.fruitList.push(fruit);
  }
}
​
class FruitLocationStrategy {
  constructor(fruitType) {
    this.fruitType = fruitType;
  }
​
  locate(list) {
    return list.find(x => x.type === this.fruitType);
  }
}
​
class FruitPriceLocator {
  constructor(fruitRepository, locationStrategy) {
    this.fruitRepository = fruitRepository;
    this.locationStrategy = locationStrategy;
  }
​
  locatePrice() {
    return this.fruitRepository.locate(this.locationStrategy).price;
  }
}
​
const appleFactory = new AppleFactory();
const orangeFactory = new OrangeFactory();
const grapeFactory = new GrapeFactory();
​
const fruitRepository = new FruitRepository();
fruitRepository.put(appleFactory.make(1.99));
fruitRepository.put(orangeFactory.make(2.99));
fruitRepository.put(grapeFactory.make(44.95));
​
const appleLocationStrategy = new FruitLocationStrategy("apple");
​
const applePriceLocator = new FruitPriceLocator(
  fruitRepository,
  appleLocationStrategy
);
​
const applePrice = applePriceLocator.locatePrice();
​
console.log("apple", applePrice);
As you can see, this has all of the core functionality properly abstracted. This code is solid.

如你所见,它把所有的核心函数合适抽象,这种代码是可靠的

Don’t let the simplicity fool you! It completely fulfills all of the complex business requirements that would typically be demanded by any seriously large enterprise.
不要让简单性欺骗你!它完全满足任何大企业通常需要的复杂业务需求。

This robust solution is completely future-proof, and properly makes use of enterprise-grade dependency injection.
这种健壮的解决方案完全不会过时,并且合适的利用了企业级依赖注入


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值