“不要给我们打电话,我们会给你打电话(don‘t call us, we‘ll call you)”这是著名的好莱坞原则。在好莱坞,把简历递交给演艺公司后就只有回家等待。由演艺公司对整个娱乐项的完全控制,演员只能被动式的接受公司的差使,在需要的环节中,完成自己的演出。
好莱坞,一个让许多俊男靓女欲罢不能的地方。在通往成功的路上,有谁不愿意通过捷径而一炮而红,在这之中影视声色是许多人会尝试的方式之一。
不过,好莱坞不是一般的场所,它不是什么阿猫阿狗都可以进入的地方,他们不缺少俊男靓女。因此,如果你有一双俊俏的脸庞,你不要在他们面前显摆,他们不在乎。你可能会说,我的演技非常棒,哦,没用,这样的人在好莱坞遍地都是。
梦想进入好莱坞的人们,你们不要找好莱坞。那怎么办呢?答案是,让好莱坞来找你!
这就是非常著名的好莱坞原则。
模板方法模式充分的体现了“好莱坞”原则。IOC是Inversion of Control的简称,IOC的原理就是基于好莱坞原则,所有的组件都是被动的(Passive),所有的组件初始化和调用都由容器负责。
所有的framework都是遵循好莱坞原则设计的,否则就不叫framework。framework使用IoC的目的:
1.对基于接口编程的支持
2.减少单件和抽象工厂的依赖
3.降低业务和框架的耦合
4.业务组件可复用,可插拔
依赖注入(IoC)
如果对象A包含对象B的话,就需要在A里new一个B
依赖注入从具体类B里抽象出接口IB——IB的具体实现可能有很多B,B1,B2…很多种——这样A可以不用再new具体的B了,而是跟IoC容器说:我要一个IB(getBean("IB"))。然后,由容器根据配置文件来做具体的new的工作。具体new的是哪个,由配置文件从代码外部决定,要更换成B,B1,或是B2…修改配置文件就能做到,不用再改代码了
例:
假设你编写了两个类,一个是人(Person),一个是手机(Mobile)。
人有时候需要用手机打电话,需要用到手机的dialUp方法。
传统的写法是这样:
//code public class Person{ public boolean makeCall(long number){ Mobile mobile=new Mobile(); return mobile.dialUp(number); } }
也就是说,类Person的makeCall方法对Mobile类具有依赖,必须手动生成一个新的实例new Mobile()才可以进行之后的工作。
依赖注入的思想是这样,当一个类(Person)对另一个类(Mobile)有依赖时,不再该类(Person)内部对依赖的类(Moblile)进行实例化,而是之前配置一个beans.xml,告诉容器所依赖的类(Mobile),在实例化该类(Person)时,容器自动注入一个所依赖的类(Mobile)的实例。
接口:
//code public Interface MobileInterface{ public boolean dialUp(long number); }
Person类:
//code public class Person{ private MobileInterface mobileInterface; public boolean makeCall(long number){ return this.mobileInterface.dialUp(number); } public void setMobileInterface(MobileInterface mobileInterface){ this.mobileInterface=mobileInterface; } }
在xml文件中配置依赖关系
//code <bean class="Person" id="person"> <property name="mobileInterface"> <ref local="mobileInterface"></ref> </property> </bean> <bean class="Mobile" id="mobileInterface"></bean>
这样,Person类在实现拨打电话的时候,并不知道Mobile类的存在,它只知道调用一个接口MobileInterface,而MobileInterface的具体实现是通过Mobile类完成,并在使用时由容器自动注入,这样大大降低了不同类间相互依赖的关系。
相关推荐
总的来说,Simple Sprint是一种适应敏捷开发理念的简化流程,强调了短周期的迭代、任务专注和低耦合的设计原则。结合好莱坞原则和AddIn的使用,团队可以在保证效率的同时,降低复杂性,提升代码质量,从而更好地应对...
设计原则 找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。 针对接口编程,而不是针对实现编程。 多用组合,少用继承。 为了交互对象之间的松耦合设计而努力。 类应该对扩展开放...
- 程序的执行流程主要由用户操作触发,而非线性执行,遵循“好莱坞”原则。 - 数据存储可能采用数据库技术,如SQL Server或SQLite,用于存储和检索联系人信息。 2. 系统设计: - 模块设计:通讯录系统可能包含...
#### 设计原则 1. **分离变化**:识别应用程序中可能会发生变化的部分,并将其隔离,避免与稳定代码混杂。例如,将变动频繁的功能抽象为接口或行为类,确保核心逻辑不受影响。 2. **针对接口编程**:无论接口是...
《惑星历险》的罗比是根据艾萨克·阿西莫夫的“机器人三定律”行动的,这一原则在后来的科幻作品中广泛引用,成为机器人行为准则的基石。罗比的形象深入人心,不仅在电影中扮演重要角色,还在其他电视节目中露面,...
#设计模式 Christopher Alexander 说:“每个模式都描述了一个在我们环境中反复出现的问题... 好莱坞原则 - 不要打电话给我们,我们会打电话给你。 单一职责——一个类应该只有一个改变的理由。 ##OO 模式:## 战略
1. **基本动画原理**:课程首先会介绍经典的12条动画原则,如 squash and stretch(挤压与拉伸)、anticipation(预备动作)、staging(舞台布置)、follow through 和 overlapping action(跟随与重叠动作)等,...
在技术层面,有若干关键原则指导着架构设计。 首先,**分层原则**是降低软件复杂性的核心思想。通过将系统划分为不同的层次,如同社会的阶层划分,可以使得每个层次专注于特定的职责,降低各部分之间的相互依赖。...
- 好莱坞原则是DI的一个体现,它表示"Don't call us, we'll call you"。这意味着组件不需要主动寻找服务,而是由容器主动调用,增强了组件的被动性和灵活性。 4. **依赖查找(Dependency Lookup)** - 依赖查找...
美国洛杉矶的好莱坞地铁站则巧妙地平衡了功能性与景观价值,通过独特的设计解决了人流冲突问题。而加拿大蒙特利尔的拉沙尔地铁站则以创新的材料和光影效果,为乘客提供了舒适且富有艺术感的乘车环境。 相比之下,...
OO设计原则识别应用程序中各个方面,将其与保持不变的方面分开。 编程到接口,而不是实现。 优先考虑组成而不是继承。 力争在相互作用的对象之间实现松散耦合的设计。 最少知识的原则:仅与您的直属朋友交谈。 ...
21. 塔特林的第三国际纪念塔代表了构成主义的探索,主张以结构和功能性为核心的设计原则。 22. 查尔斯·鲁克斯提出的“后现代主义”概念,对20世纪晚期的建筑设计产生了重大影响。 23. 现代主义建筑五大师的贡献...
#设计模式 OO模式 面向对象原则 封装各种内容。 优先考虑组成而不是继承。... 好莱坞原则:请勿致电给我们,我们会致电给您。 一个班级只有一个改变的理由。 您需要.NET Core 3.1才能运行这些示例。
使用Java的设计模式 介绍 此回购包含中的所有设计。... 设计原则 好莱坞原则 单一责任原则 我想推荐的其他资源很少 头先设计模式 克里斯托弗·奥克拉维(Christopher Okhravi)的精彩播放列表 重构大师
在 DUM 部分回调机制中,我们可以看到著名的“好莱坞原则”的应用。句柄和代理的一个特点就是重载了 operator->、operator* 等操作符。 Resiprocate 的源代码为我们提供了一个很好的学习资源,让我们可以了解 SIP ...
好莱坞原则(Hollywood Principle)是对IOC的一个形象比喻,意味着“不要调用我,让我来调用你”。例如,通过依赖注入容器,对象的创建和依赖关系的建立交由容器处理,而不是由对象自身管理。 依赖注入(Dependency...
- **布局原则**:遵循良好的布局原则,如对齐、间距等。 - **控件位置**:合理安排控件的位置,确保用户界面整洁有序。 #### 第十章:DataSnap(三层)技术和iOS客户端 本章介绍了如何使用DataSnap技术实现三层架构...
- **好莱坞原则**:框架调用应用提供的函数,而不是反之。 - **函数签名**:所有函数具有相同的签名`f(Req, Data, Context) -> {Result, Req, Data, Context}`。 - `Result`:通常包含布尔值,用于向决策核心发送...
2. DIP(Dependency Inversion Principle,依赖倒转原则):也称为好莱坞原则(Hollywood Principle),即“别找我们,我们会找你”。它强调低层次模块(如业务逻辑)依赖高层次模块(如框架),并且高层次模块通过...