面向对象基础-开放封闭原则

开放封闭原则:软件实体(类、模块、函数等等)应该是可以扩展的,但是不可以修改。
我们在做系统的时候,都希望希望一开始时需求确定,以后就不需要修改了,但是这似乎不太科学,出现了变化,我们要如何去做呢?也就是说,怎么设计才能面对需求的变化却可以保持相对的稳定,从而使得系统可以在第一个版本以后不断推出新的版本呢?这就是我要说,在设计的时候需要遵循的开放封闭原则。
封闭:按照我的理解是我们把对象封装成一个类,或者把一些算法封装成一个个函数。这个时候,开发者对于对象来说是封闭的,我们并需要了解具体的类、函数是如何实现,但是无论你的模块、类、函数是多么的封闭,都会存在一些无法对之封闭的变化,既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪些变化冰壁做出选择。他必须先猜测最有肯能的变化种类,然后改造抽象来隔离那些变化。这就是说:我们在最初编写代码的时候,假设变化不会发生,当变化发生地时候,我们就创建抽象来隔离以后发生地同样变化。比如,我做的以前那个算术器,我们首先设计了一个加法类,但是后来发现还有很多运算,我们不能每次都来改动加法类,所以,这个时候,我们需要抽象一个运算类出来,通过面向对象的手段,如继承,多态等来隔离加法、减法、乘法、除法等等。所有的这些需求变化,对程序的改动是通过增加新代码进行的,而不是改变现有的代码,这就是封闭开发原则
开放封闭原则是面对对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处,也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中出现频繁变化的那些部门作出抽象,然后对于应用程序中的每个部门都刻意地进行抽象同样不是一个好的办法,拒绝不成熟的抽象和抽象本身一样重要。

转载于:https://www.cnblogs.com/chenamo5776/archive/2011/11/13/2247182.html

(1)普通用户端(全平台) 音乐播放核心体验: 个性化首页:基于 “听歌历史 + 收藏偏好” 展示 “推荐歌单(每日 30 首)、新歌速递、相似曲风推荐”,支持按 “场景(通勤 / 学习 / 运动)” 切换推荐维度。 播放页功能:支持 “无损音质切换、倍速播放(0.5x-2.0x)、定时关闭、歌词逐句滚动”,提供 “沉浸式全屏模式”(隐藏冗余控件,突出歌词与专辑封面)。 多端同步:自动同步 “播放进度、收藏列表、歌单” 至所有登录设备(如手机暂停后,电脑端打开可继续播放)。 音乐发现与管理: 智能搜索:支持 “歌曲名 / 歌手 / 歌词片段” 搜索,提供 “模糊匹配(如输入‘晴天’联想‘周杰伦 - 晴天’)、热门搜索词推荐”,结果按 “热度 / 匹配度” 排序。 歌单管理:创建 “公开 / 私有 / 加密” 歌单,支持 “批量添加歌曲、拖拽排序、一键分享到社交平台”,系统自动生成 “歌单封面(基于歌曲风格配色)”。 音乐分类浏览:按 “曲风(流行 / 摇滚 / 古典)、语言(国语 / 英语 / 日语)、年代(80 后经典 / 2023 新歌)” 分层浏览,每个分类页展示 “TOP50 榜单”。 社交互动功能: 动态广场:查看 “关注的用户 / 音乐人发布的动态(如‘分享新歌感受’)、好友正在听的歌曲”,支持 “点赞 / 评论 / 转发”,可直接点击动态中的歌曲播放。 听歌排行:个人页展示 “本周听歌 TOP10、累计听歌时长”,平台定期生成 “全球 / 好友榜”(如 “好友中你本周听歌时长排名第 3”)。 音乐圈:加入 “特定曲风圈子(如‘古典音乐爱好者’)”,参与 “话题讨论(如‘你心中最经典的钢琴曲’)、线上歌单共创”。 (2)音乐人端(创作者中心) 作品管理: 音乐上传:支持 “无损音频(FLAC/WAV)+ 歌词文件(LRC)+ 专辑封面” 上传,填写 “歌曲信息
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值