Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
C语言程序框架
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Bob Liu
January 09, 2014
Technology
210
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
C语言程序框架
C语言程序框架 我的博客:
http://akagi201.org
Bob Liu
January 09, 2014
Other Decks in Technology
See All in Technology
Kiro Crewで「みのるん式」仕事術やってみた
minorun365
PRO
1
270
20261017福岡devIO 「AIは"良いダッシュボード"を作れるか?
jtakeda
0
180
Running Kotlin + Quarkus with Lambda
nealle
1
3.9k
大型犬好きによるPugの紹介
yamanoku
1
160
SAENM ~Jupyterで残すPoCの試行錯誤、未来の自分と仲間を助ける記録!~
terapyon
0
120
hackers_champloo_2026_tidb
makocchi
0
170
フロントエンドカンファレンス関西2026 - 速すぎるUIに、待ち時間を
teamlab
PRO
0
180
"優秀な誰か"の下位互換にならないために
yut0naga1_fa
1
1.8k
専門領域のAIをどう評価するか
bengo4com
2
280
AIがコードを書く時代に、エンジニアは何で自分の価値を証明するのか / In an era where AI writes code how do engineers prove their value
carta_engineering
3
1.1k
USB PDを使ってスマホを労わりたい
raspython3
0
180
Browser Spec: Testing Hotwire with Ruby
takahashim
1
130
Featured
See All Featured
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
Building a Scalable Design System with Sketch
lauravandoore
464
34k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
22k
sira's awesome portfolio website redesign presentation
elsirapls
0
460
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.7k
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
600
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
750
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
68
58k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.6k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
300
StorybookのUI Testing Handbookを読んだ
zakiyama
31
7k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
270
Transcript
C语言程序框架 刘博
目录 框架 面向对象 lw_oopc
框架是什么?
“框架是构成一类特定软件可复用设计的一组相互协作的类.” –<设计模式>
框架=面向对象+一类问题+设计模式
面向对象的重点 封装(Encapsulation) 继承(Inheritance) 多态(Polymorphism) 这三者是有次序性的,没有封装就不可能有继承、没有继承就不可能有 多态。
封装(encapsulation) 封装(encapsulation)的目的是要将代码切割成许多模块(module), 每个模块之间的关联性降到最低,这么一来比较不会产生「牵一发而动 全身」的状况,降低相互依赖的程度,也等于是降低复杂度,可以让开 发与维护更容易。
事实上,没有人用「模块」一词来称呼封装的结果,而是称为「类」, 把模块一词做更高阶的包装用途。因此我们现在应该将「类」视为封装 的结果,把「模块」视为整个程序切割出来的许多片段。而在OO的世 界,一般来说,一个程序有多个模块,一个模块内包含多个类。
封装是以数据为核心,将相关的数据放在一起,将会用到这些数据的函 数也放进来。封装等于是将数据和函数放在一起。尽管有的语言还有其 它的东西,例如event、property,但是从内部来看,这些都是函数的变 形。 为了和非OO的世界做出区隔,OO也做了一些名词上的改变,将 Function(函数)改称为Method(方法)、将Call(呼叫)改称为 Invoke(调用)。但是新旧词汇基本上还是通用的。
能见度(visibility) 封装的目的既然是要「降低互相依赖的程度」,就牵涉到能见度的问 题:这个「类/方法/栏位」该不该暴露给别的模块、同一个模块的不同 类、自己的「次类」、友伴类(Friend Class)、内部类(Inner Class)?这就是所谓的「能见度」(visibility)。 我们当然希望尽可能降低能见度,这才能「降低互相依赖的程度」。也 就是,别人不需要知道的,就不要让它知道,这就是所谓的「信息隐 藏」(information hiding)。
最该被隐藏的是数据。极致的封装主义者,主张所有的数据一定都不可 以直接被外部(包括次类)访问。
设定能见度不是一件容易的事,往往需要深思熟虑。特别是对于设计 「框架」(framework)的人来说,能见度设定得太宽,造成信息隐藏 效果不佳,可能会带来相当多负面的效果(例如复杂度提高、程序容易 出错、非thread- safe…等);能见度设定得太紧,造成效率变差、扩充 程度变差(有些设计因而做不出来)。
继承 被继承的对象称为基底类(base)或超类(super)或亲类(parent), 继承者称为衍生类(derived)或次类(sub-)或子类(child)。 继承的目的,是要达到「代码复用」(Code Reuse)或「接口复用」。 而继承的手段,就是「扩充」或「修改」。这是继承的重点,请务必牢 记。
继承所导致的代码复用,是指次类能自动沿袭超类的所有代码,好让你 可以不用写太多代码,只需要稍微扩充或修改,就能符合你的需求。 「扩充」指的是定义新的方法(Method),修改指的是「针对超类中的 某方法重新定义其行为」。 继承所导致的接口复用,是在为OO的下一个阶段(也就是多态)作准 备。接口复用,搭配方法的修改,就形成了多态。
将许多类之间的继承关系,绘制出一张关系图,如果绘制的时候依循 「超类在上,次类在下」,或者「超类在左,次类在右」,就可以形成 一个类阶层(Class Hierarchy)。由于大多数的类阶层设计都是采用单 一继承(Single Inheritance),而非多重继承(MultipleInheritance), 所以阶层图往往是树状结构,符合树状结构的阶层图,也称为继承树、 类树。
多态(Polymorphism)与虚拟 Polymorphism中文一般称为「多态」,早期也有人称为「同名异式」。 我比较喜欢前者,不喜欢后者。 「多态」让人觉得对象可以以「多种面 貌」出现,同名异式则太强调「不同的函数」。其实,「型态的不同」 是因,而「函数的不同」是果。当一个对象具有不同的型态,就有可能 会引发多态机制。
一个对象为何会有不同的型态?这是因为继承而来,对象可以扮演所有 祖先类的角色。例如当某对象的类是Sub,当此对象被「转型」成超类 Super之后,此对象就具有两种不同的类,「实际类」是Sub,「形式 类」是Super,此时呼叫此对象的方法m,会执行到的是Super定义的方 法m?还是Sub定义(修改)的方法m? 答案是实际类的方法,也就是Sub定义的方法m。所以所谓的多态就 是:不管形式类是什么,一定会执行到实际类的方法。
如果你的程序中,大量使用switch/case语法,很有可能是你的设计不 良,而没有好好地使用多态。你最好能「重构」(Refactoring)你的程 序。 [不要if else编程](http://www.v2ex.com/t/90780) 不要滥用if else编程
类的方法,可以分成虚拟(Virtual)与非虚拟两种。只有虚拟方法才能 搭配多态机制使用。如果是非虚拟方法,则会执行到形式类(而非实际 类)的方法,因为多态没有发挥作用。 关于虚拟,每个语言有不同的作法。 Java强调动态,所以默认是虚拟; C++注重效率,所以默认不是虚拟。
应用框架 框架厂商先将一大部分的程序先写好,编程员只需要「利用继承来做修 改」,就能套用整个框架,为了要让你修改的部分能够确实被执行到 (而不是执行到框架本身的方法),所以这些允许修改的方法都是定义 成虚拟的。
单一继承架构中,良好的框架设计(例如Java Swing)会将代码不需要 被修改的部分,设计成类。至于需要被继承修改的部分,设计成 Interface(Interface的方法全都是虚拟的),以及实践这些Interface的 类。框架内的类尽量只使用到这些接口。
框架设计上,近年来比较不一样的是,阶层有变深的趋势(例如AIR和 WPF的框架);也就是说,继承树的叶节点到根节点之间的距离变大 了。这样的好处是代码重复利用度增加(所以框架档案的体积变小), 接口重复利用度增加(学习速度可以加快)。
lw_oopc (Light-Weight Object-Oriented Programming in C)
总共一个.h文件,20个宏,约130行代码,非常的轻量级,但却很好的 支持了很多面向对象的特性,比如继承、多态,可以优美的实现面向接 口编程。这个框架系由台湾的高焕堂先生以及他的MISOO团队首创。
LW_OOPC是什么? 简而言之:LW_OOPC是一套C语言的宏,总共1个.h文件(如果需要内 存泄漏检测支持以及调试打印支持,那么还需要1个.c文件 (lw_oopc.c,约145行)),20个宏,约130行代码。LW_OOPC是一 种C语言编程框架,用于支持在C语言中进行面向对象编程。 https://github.com/Akagi201/aklw_oopc
Adam Dunkels Protothreads uIP Contiki lwIP <Interconnecting Smart Objects with
IP> https://github.com/adamdunkels
<UML+OOPC嵌入式C语言开发精讲> <Object Oriented Software Construction>