前端框架中的设计模式 | 青训营

前端框架中的设计模式

前端框架是一种软件设计模式的实际应用,它们旨在帮助开发人员快速、高效、优雅地构建网页应用程序。前端框架可以提供一些常用的功能和组件,如路由、状态管理、数据绑定、组件化等,以及一些优化和增强的机制,如虚拟DOM、响应式系统、模块化打包等。前端框架可以让开发人员专注于业务逻辑和用户体验,而不用过多地关注底层的细节和兼容性问题。

前端开发中存在着许多挑战和目标,如性能、兼容性、可维护性、可扩展性、可测试性等。为了解决这些问题,前端框架通常采用了一些设计模式,来规范和简化代码的结构和逻辑。设计模式是对软件设计中反复出现的某类问题的通用解决方案,它们可以提高代码的可读性、可重用性和可修改性。不同的设计模式有不同的特点和适用场景,选择合适的设计模式可以提高开发效率和代码质量。

在本文中,我们将介绍前端框架中常见的四种设计模式:MVC(Model-View-Controller)、MVVM(Model-View-ViewModel)、观察者模式和装饰者模式,并对它们进行比较分析。

1. MVC(Model-View-Controller)

MVC 是一种经典的设计模式,用于将应用程序分为三个核心部分:模型(Model)、视图(View)和控制器(Controller)。模型负责管理数据和业务逻辑,视图负责展示数据,控制器负责处理用户输入并更新模型和视图。

优点:

  • 分离关注点:MVC 将应用程序的不同部分分离,使代码更具可维护性和可重用性。
  • 降低耦合度:模型、视图和控制器之间的松耦合性使得修改其中一个部分不会影响其他部分。
  • 支持多人协作:开发人员可以根据各自的专长同时工作,而不会相互干扰。

缺点:

  • 学习曲线:初学者可能需要一些时间来理解模式的概念和如何正确地实现它。
  • 代码结构复杂:较小的项目中引入 MVC 可能会导致代码过于复杂,不利于快速开发。

使用案例: 一个经典的使用案例是使用 Angular 框架。在 Angular 中,组件负责视图和控制器的角色,而服务则负责模型的角色。这种分层结构使得开发人员可以更好地组织和管理代码。

代码示例:

// 模型:定义了一个用户类
export class User {
  constructor(
    public id: number,
    public name: string,
    public email: string
  ) {}
}

// 视图:使用模板语法绑定了用户数据
@Component({
  selector: 'app-user',
  template: `
    <div>
      <h1>User Profile</h1>
      <p>ID: {{user.id}}</p>
      <p>Name: {{user.name}}</p>
      <p>Email: {{user.email}}</p>
    </div>
  `
})
export class UserComponent {
  // 视图模型:从服务中获取用户数据
  user: User;

  constructor(private userService: UserService) {}

  ngOnInit() {
    this.user = this.userService.getUser();
  }
}

// 控制器:定义了一个服务类,用于获取用户数据
@Injectable({
  providedIn: 'root'
})
export class UserService {
  // 模拟从后端获取用户数据
  getUser(): User {
    return new User(1, 'Alice', 'alice@example.com');
  }
}

2. MVVM(Model-View-ViewModel)

MVVM 是一种模式,用于在用户界面和业务逻辑之间建立分离。它包括模型(Model)、视图(View)和视图模型(ViewModel)。视图模型充当了控制器的角色,处理用户输入并更新模型和视图。

优点:

  • 双向数据绑定:MVVM 框架允许视图和模型之间的自动双向数据同步,减少了手动操作。
  • 分工明确:开发人员可以专注于视图和视图模型,提高了开发效率和代码质量。
  • 测试简便:由于业务逻辑位于视图模型中,因此可以更轻松地编写单元测试。

缺点:

  • 学习成本:学习 MVVM 框架和概念可能需要一些时间,特别是对于初学者来说。
  • 过度抽象:过度使用数据绑定可能导致代码变得复杂,难以理解。

使用案例: Vue.js 是一个典型的MVVM框架。在Vue中,开发人员使用模板编写视图,通过数据绑定将视图与视图模型关联起来,使得数据的变化自动更新视图。

代码示例:

<!-- 视图:使用模板语法绑定了用户数据 -->
<div id="app">
  <h1>User Profile</h1>
  <p>ID: {{user.id}}</p>
  <p>Name: <input v-model="user.name"></p>
  <p>Email: <input v-model="user.email"></p>
</div>
// 模型:定义了一个用户对象
const user = {
  id: 1,
  name: 'Alice',
  email: 'alice@example.com'
};

// 视图模型:创建了一个Vue实例,用于管理视图和模型之间的数据绑定
const vm = new Vue({
  el: '#app',
  data: {
    user: user
  }
});

3. 观察者模式

观察者模式是一种行为型模式,它定义了一种一对多的关系,当一个对象状态发生改变时,其依赖对象都会收到通知并自动更新。

优点:

  • 解耦合:观察者模式将观察者和被观察者解耦,使得它们可以独立地进行修改和扩展。
  • 可扩展性:可以随时添加新的观察者,不会影响现有的代码。

缺点:

  • 内存泄漏:如果观察者没有正确被取消注册,可能会导致内存泄漏问题。
  • 多次更新:当被观察者状态频繁变化时,观察者可能会收到多次更新通知,可能造成性能问题。

使用案例: React 中的事件处理机制可以看作是观察者模式的应用。组件可以监听其他组件的事件或状态变化,当状态发生变化时,组件会自动重新渲染。

4. 装饰者模式

装饰者模式是一种结构型模式,它允许动态地将新功能添加到对象中,而不改变其结构。

优点:

  • 动态扩展:可以在运行时动态地为对象添加功能,而无需修改其现有代码。
  • 单一职责原则:通过将功能划分为单独的装饰器类,可以保持类的单一职责。

缺点:

  • 复杂性增加:如果不恰当地使用装饰者模式,可能会导致类的数量增加,从而增加代码复杂性。
  • 装饰器顺序:多个装饰器嵌套时,装饰器的执行顺序可能会影响最终结果。

使用案例: 在 Angular 中,使用装饰器可以为类添加元数据和功能。例如,@Component 装饰器用于将类标记为组件,@Input 装饰器用于声明输入属性。

总结

不同的设计模式在前端框架中都有各自的应用场景和优缺点。选择适合项目需求的模式可以提高代码的可维护性、可扩展性和可重用性。MVC 和 MVVM 适用于大型应用,提供了分离关注点的能力;观察者模式用于事件驱动的开发,实现组件间的松耦合;装饰者模式用于动态地扩展对象的功能。

在实际开发中,根据项目规模、团队经验和需求特点,选择合适的设计模式进行开发是至关重要的。同时,不同设计模式也可以结合使用,以达到更好的代码结构和可维护性。

全部评论

相关推荐

不知道怎么取名字_:愚人节收到的吧,刚看到有人也是愚人节说收到offer的
腾讯求职进展汇总
点赞 评论 收藏
分享
上周组里招人,我面了六个候选人,回来跟同事吃饭的时候聊起一个让我挺感慨的现象。前三个候选人,算法题写得都不错。第一道二分查找,五分钟之内给出解法,边界条件也处理得干净。第二道动态规划,状态转移方程写对了,空间复杂度也优化了一版。我翻他们的简历,力扣刷题量都在300以上。后三个呢,就有点参差不齐了。有的边界条件没处理好,有的直接说这道题没刷过能不能换个思路讲讲。其中有一个女生,我印象特别深——她拿到题之后没有马上写,而是先问我:“面试官,我能先跟你确认一下我对题目的理解吗?”然后她把自己的思路讲了一遍,虽然最后代码写得不是最优解,但整个沟通过程非常顺畅。这个女生的代码不是最优的,但当我问她“如果这里是线上环境,你会怎么设计’的时候,她给我讲了一套完整的方案——异常怎么处理、日志怎么打、怎么平滑发布。她对这是之前在实习的时候踩过的坑。”我在想LeetCode到底在筛选什么?我自己的经历可能有点代表性。我当年校招的时候,也是刷了三百多道题才敢去面试。那时候大家都刷,你不刷就过不了笔试关。后来工作了,前三年基本没再打开过力扣。真正干活的时候,没人让你写反转链表,也没人让你手撕红黑树。更多的是:这个接口为什么慢了、那个服务为什么OOM了、线上数据对不上了得排查一下。所以后来我当面试官,慢慢调整了自己的评判标准。算法题我还会出,但目的变了。我出算法题,不是想看你能不能背出最优解。而是想看你拿到一个陌生问题的时候,是怎么思考的。你会先理清题意吗?你会主动问边界条件吗?你想不出来的时候会怎么办?你写出来的代码,变量命名乱不乱、结构清不清楚?这些才是工作中真正用得到的能力。LeetCode是一个工具,不是目的。它帮你熟悉数据结构和常见算法思路,这没问题。但如果你刷了三百道题,却说不清楚自己的项目解决了什么问题、遇到了什么困难、你是怎么解决的,那这三百道题可能真的白刷了。所以还要不要刷LeetCode?要刷,但别只刷题。刷题的时候,多问自己几个为什么:为什么用这个数据结构?为什么这个解法比那个好?如果换个条件,解法还成立吗?把刷题当成锻炼思维的方式,而不是背答案的任务。毕竟面试官想看到的,从来不是一台背题机器,而是一个能解决问题的人。
牛客51274894...:意思是光刷力扣还不够卷
AI时代还有必要刷lee...
点赞 评论 收藏
分享
04-24 13:51
已编辑
西安电子科技大学 Java
👋个人背景:211计算机混子,代码能力一般,春招急头白脸参加央国企最后拿下这两个offer👏offer1:中广核工程公司驻陆丰仪控调试,待遇19+4,离家1800km💯offer2:张家口卷烟厂待遇未知,应该有13个(猜测),离家500km牛油们帮忙选一下,家里人不是很喜欢卷烟厂这个offer,但是蜀黍烟草局下岸了
鸿雁于飞:先说offer1:中广核工程公司驻陆丰仪控调试(待遇19+4) 中广核这艘央企大船还是很稳的,集团综合效益稳居央企前列。但你得搞清楚,这个19+4的"19"是总包,不是到手数——招聘宣传待遇里把所有能算的都算进去了,饭卡福利积分啥的全包含,有牛油分享实际到手大概打七折。试用期到手可能就四五千的水平,转正后基本工资4800左右,其余靠绩效、年终、大修费撑着。不过核电的工作环境有点"牢笼感"——核电站位置偏僻,远离繁华都市。工程公司是承包商性质,干活比业主公司累,而且大概率要经常出差,有的岗位年出差天数100天以上。最大问题是你这1800km的距离过于离谱,核电员工工作强度最小的时候一周也就回一次家,离得远回家成本高,夫妻感情和亲子关系都是现实考验。说白了:高薪是拿青春和生活换的。 再来看offer2:张家口卷烟厂(待遇约13个) 张家口卷烟厂是河北中烟下属三家卷烟厂之一,河北中烟主打的"荷花"系列连续多年位居全国高端卷烟品牌销量前列。烟草系统薪资由基本工资+绩效+年终奖构成,综合年薪普遍显著高于当地平均水平,六险二金齐全,福利拉满。有人问"13个是不是太平平无奇了"——关键张家口是四线城市,生活成本低,这13万的购买力相当于深圳的二十多万。离家500km,开车半天到家,周末回趟家完全可行,幸福感直接上两个档次。中广核的牛油说了句大实话: "哪个核电站好?永远是离家近的那个最好。" 选烟厂同理。 但是,卷烟厂的坑你得清楚: 首先卷烟厂和烟草局不一样,卷烟厂是生产操作类岗位,很多要三班倒。报考条件明确写了要能"胜任夜班工作和长时间站立工作"。一线操作工每天盯着流水线卷烟,工作内容高度重复,有入职的人描述为"食之无味弃之可惜"。有牛油直言"卷烟厂和商业性质的烟草公司不一样,前者很坑很累"。其次你家里人不是不喜欢,而是担心你这211计算机科班出身,进了烟厂干操作工,技能会快速退化,未来如果行业改革,技术壁垒不高,转行比较困难。等你干两年再跳出来,技术栈全忘干净了,回头再去敲代码,发现连应届生都卷不过。 老牛油的灵魂三问: 1. 你是更怕穷,还是更怕想家? 如果特别恋家的人跑1800km之外,第一年哭鼻子的概率高达80%。陆丰那地方偏僻单调,核电基地又远又闷,闲下来除了打游戏没啥娱乐,社交圈也窄。找个对象都费劲——牛油亲测核电站"狼多肉少"。 2. 你的代码能力有多"一般"? 如果真的一般,仪控调试和你专业匹配度不算高,这活儿主要是工程改造设计、现场实施管理、在建机组设计审查等,偏工程向而非纯软开。干两年后跳回互联网赛道,竞争力不一定有明显提升。反倒是烟厂不需要你写代码,进去就是稳定躺平。 3. 烟草局下岸这事儿会不会让你耿耿于怀? 如果烟草局是你第一志愿,烟厂只是plan B,那得想清楚:进去了可能每天看着天花板想"如果当初去了烟草局该多好",这种内耗比钱少还折磨人。如果你能接受"反正都是烟草系统,先进去再说"的心态,那倒无所谓。 一句话总结: 如果年轻想拼想闯做技术积累,中广核虽然累和远,但简历上央企核电的金字招牌确实有含金量,加上到手收入在这两个选项里确实更高,考虑到你个人经济情况和家庭状况,假如家里不需要你常回去照顾,家里有兄弟姐妹帮手分担,那先去核电待三四年,积累经验再跳槽也不失为一步棋。 如果想安稳过日子离家近当"人上人",烟厂低线生活成本加持,加上稳定的编制和福利体系,在张家***得滋润,幸福感吊打陆丰。尤其家里人是那种离不开你的,有烟厂的稳定且离家近,比任何高薪都实在。
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务