惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Cisco Talos Blog
Cisco Talos Blog
V
V2EX
C
Check Point Blog
GbyAI
GbyAI
D
Docker
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
B
Blog RSS Feed
H
Hackread – Cybersecurity News, Data Breaches, AI and More
N
Netflix TechBlog - Medium
T
Troy Hunt's Blog
博客园 - Franky
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Microsoft Security Blog
Microsoft Security Blog
P
Privacy & Cybersecurity Law Blog
WordPress大学
WordPress大学
The Cloudflare Blog
S
SegmentFault 最新的问题
Latest news
Latest news
Microsoft Azure Blog
Microsoft Azure Blog
P
Proofpoint News Feed
I
InfoQ
博客园 - 【当耐特】
NISL@THU
NISL@THU
A
About on SuperTechFans
T
Tailwind CSS Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
The Hacker News
The Hacker News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Scott Helme
Scott Helme
雷峰网
雷峰网
C
CXSECURITY Database RSS Feed - CXSecurity.com
Security Latest
Security Latest
V
Vulnerabilities – Threatpost
Security Archives - TechRepublic
Security Archives - TechRepublic
A
Arctic Wolf
Hacker News: Ask HN
Hacker News: Ask HN
N
News and Events Feed by Topic
IT之家
IT之家
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
aimingoo的专栏
aimingoo的专栏
T
Threat Research - Cisco Blogs
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
阮一峰的网络日志
阮一峰的网络日志
SecWiki News
SecWiki News
大猫的无限游戏
大猫的无限游戏
S
Security Affairs
The Register - Security
The Register - Security
www.infosecurity-magazine.com
www.infosecurity-magazine.com
L
LINUX DO - 热门话题
T
Tor Project blog

博客园 - Anders小明

关于架构的思考 如何定义和建立架构 企业应用下的业务组件开发实践 浅谈领域驱动设计 浅谈基础平台 浅谈企业应用架构(二) 浅谈企业应用架构(一) 技术书籍推荐 AOSD的实践冲动——Use Case的实现 业务流程的层次和内容 Domain Model的三种类型及其级别 基于业务模块组件的系统架构 小议领域模型(Domain Model)补充以及更新 软件架构乱弹——问题域及其解决方法 软件工程中的经济行为与软件架构师的工作 Web框架比较 AspectJ应用--软件产品化的新方法 [转贴]做好个人时间管理 基于抽象的分层结构
Interface plays as Placeholder, without any class implement it
Anders小明 · 2007-02-09 · via 博客园 - Anders小明

Interface plays as Placeholder, without any class implement it
Author:Anders小明

有个这个题目是在ApectJ的应用,以及博客园子中一个blog讨论什么时候用接口(一个很古老的话题)。
接口作为一种重要的抽象能力,重要意义在于:
模型上看:接口代表做什么,而实现表示怎么做!
在框架上:接口代表稳定,而实现代表多变!
在语言上:接口代表0,而实现代表1,通过对象类型消除if…else…。
(这段话我<<Domain Model:业务流程的进一步分析2>>提过)
既然是应用开发,模型角度看根据现实意义,没有AspectJ前的开发,都是设计好一个接口,然后至少一个实现类,然后通过factory获取正确的实现类,后来spring出现了,实现了IoC。然而由于AspecJ横空出世了,我们又多了一种手段:接口作为占位符, 而没有实现类(当然有实现)。这是我在看到partech的sunflower的代码后才想到的!虽然我在<<AOSD:应用AOP实现业务逻辑>>一文中已经想到了一些,然而还是没有partech来的狠!
下面是一个简单的例子:
Order类

OrderService类

Main类

OrderServiceAspect

虽然AspectJ的功能如此强大, 接口真正做占位符用的情况,估计还是有很多人提出异议,这样做我有什么好处,和我写接口实现类相比?
好处目前,我能想的到的只有两个
1. 模型上,强迫所有人思考——接口到底做什么,而不是怎么做
2. 语言上,更加动态性,不在依赖接口的完整签名,只是输入参数和输出参数,看上去更接近.Net的Delegate

技术好坏只有自己展控了才知道,AspectJ提供这样一个选择,怎么做还是自己琢磨着吧。