C++Swift 十二云 第八章节 类型扩展(Extensions)和商讨 (draft)

1. Extensions

扩充指的凡指向都局部类还是项目丰富一些你自己定义之习性,方法。甚至对内建之花色也得开展扩展。这分明极大的提高了马上宗语言的威力和灵活性。如下例:

extension Int
{
var a:String{
    return "你是个好人"
}
}


var b:Int=2
println(b) //输出2
println(b.a) //输出 "你是个好人"
  • 恢宏只能加加计属性,不克补加存储属性。

  • 卿可以让类添加快捷初始化函数。但是未可知吃结构体扩展一个委托初始化函数。

  • 实例方法的扩大

实例方法的扩充,就是添加一个成员函数。这个成员函数和为创造的实例绑定。例如:

extension Int
{
func a()->String{
    return "你是"+String(self)+"个好人"
}
}


var b:Int=20
println(b) //输出20
println(b.a()) //输出“你是20个好人”

若因此mutating关键字,那么实例方法好改实例的值。例如:

extension Int
{
mutating func a()
{
    self = -self
}
}


var b = 1
println(b) //输出1
b.a()
println(b) //输出-1

路方法的恢弘,前面要加static之类的重大字。这是为这方式是和类的定义绑定以一起的。例如:

extension Int
{
static func a()
{
   println("坏蛋")
}
}


var b = 20
println(b)  //输出20
Int.a()    //输出"坏蛋"
  • 下标扩展

而还足以于项目丰富下标扩展,方便使用。下表扩展以及道扩展的写法非常相近。例如:

extension Int
{
subscript(i:Int)->Int
{
   println("下标扩展被调用")
   return 123
}
}


var b = 20
println(b[0]) //输出“下标扩展被调用”;输出 123
  1. Protocols

商是一致组属性,方法,下标等的扬言的容器。当您定义一个看似的下,可以指明它用遵循的协商,然后以相近的中,实现协议规定的那些东西。注意,协议就是单容器,不是实现。所以实际是比类更强一级的描述。描述的凡基本上单近乎的同台特性。所以协议里的变量,只能声明,不克初始化。方法下标也是这么。例如

protocol a {
var ax:Int = 1
}  //Playgroudn会立即报错,"initial value is not allowed here"

了解了协和是语法的计划思路。它的一部分现实写法与用法就好自然而然的知了。

  • 商定义的格式为:

protocol 协议名
{//里面写你要定义的东西
}
  • 谋使用的格式为:

class 类的名:[上类的讳] 协议的名,第二独协议的讳,..等等

设一个好像是从上类继承而来,那么要拿上类的名写于商量名字前。一个接近可以遵循多独商量。

  • 协商里的性方法等等前面可加optional
    关键字,这之所以来代表这些元素不肯定要以类似中实现。协议里的性能,后面可以同{get,set}以表示其也而读也只是写的特性。如果只是所以get,那即便是特待可读。如果一味所以set,那表示仅待可写。

  • 而外类以外,一般的数据类型也堪用extension关键字,来使她遵从一个早就定义了的商事。例如:

protocol a {
func ax()-> Int

}

extension Int: a
{
func ax() -> Int {
    println("对不起,你是个好人")
    return 0
 }
}

var b = 1
b.ax() //输出: 对不起,你是个好人

由上例可以观看,协议是用以多单近乎的概念之。例如你多多接近都设发作好人卡,那么定义个协议就好吃您的代码组织结构更好。如果单独是一个像样需要是好人口卡函数,那就没有必要运用协议。

面向对象的一对语言因素,到就等同回就基本介绍完了。这里尚牵扯到一个又特别之话题。一般的话,面向对象的多特性,例如类继承扩展协议等等都是为还发出集体的拓代码复用。但是,每多同重叠容器,代码的冗余部分也不怕更繁杂,组织结构吧就重新复杂。那么,到底以设计项目的结构体系之时节,应不应该用面向对象特性也?笔者的看法挺简单:跟着常识走。如果一个靶要经过,在切实可行世界被特别爱让拟物,而且后面有很死时让复用,那设计一个看似往往是没错的。例如图形界面元素,按钮。按钮本身即是只物体,然后让图形界面拟物。按钮是物体显然是来颜色,有大小,有给以后展开什么操作的效力的。所以您计划个类,就不会见出错。因为每个程序员脑子里的按钮都是坐求实经验吗根基的,观念也即比较平。

只是,例如有些生意逻辑,你以面向对象的计划性思路,就不一定是个好方式。这是为对生意逻辑的懂得,人人都或两样。想想看,买火车票排队就回事,实际上是多的复杂。这种气象下,笔者以为,不要用面向对象的方式。不然设计这体系布局的人口走了,你的项目基本就是作废了。因为这种场面下统筹下的接近协议等等,肯定是个人观点和见解的产物。而人及人里面的交流,往往比较一般人设想的设困难的多。

多计算机书,拿个什么电话号码本,什么矩形长宽,什么员工进出纪录之类的物,来显示面向对象的法门多么来因此,这实际是不负责任的做法。没有考虑到复杂系统自身的盘算出和保安开销。只考虑了那作用。

自,你一旦说我不少钱。开个种类,写文档的也罢是先后一流人才,或者文档的人口于写代码的素质尚高。那自己不怕会推荐你用面向对象的元素多片。

3. 附录,GIT为什么是纯C写的?


作者以为,Linus的眼光有点偏老了。面向对象编程经过几千万人口未彻底程序验证了的场所,最保险的尽管是图形界面设计。为什么当是小圈子如此牢靠?为什么今天图用户界面部分的编程主流或面向对象的?我认为根本由就是图形界面都是拟物的。每个人之公共共识都多,所以不见面错。

From: Linus Torvalds <torvalds <at>
linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better
String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36
minutes ago)

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:

When I first looked at Git source code two things struck me as odd:

  1. Pure C as opposed to C++. No idea why. Please don’t talk about
    portability,
    it’s BS.

下面是Linus的回答:

YOU are full of bullshit.
C++ is a horrible language. It’s made more horrible by the fact that a
lot
of substandard programmers use it, to the point where it’s much much
easier to generate total and utter crap with it. Quite frankly, even
if
the choice of C were to do nothing but keep the C++ programmers
out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know
Miles
Bader jokingly said “to piss you off”, but it’s actually true. I’ve
come
to the conclusion that any programmer that would prefer the project to
be
in C++ over C is likely a programmer that I really would prefer to
piss
off, so that he doesn’t come and screw up any project I’m involved
with.
C++ leads to really really bad design choices. You invariably start
using
the “nice” library features of the language like STL and Boost and
other
total and utter crap, that may “help” you program, but causes:

  • infinite amounts of pain when they don’t work (and anybody who tells
    me
    that STL and especially Boost are stable and portable is just so
    full
    of BS that it’s not even funny)
  • inefficient abstracted programming models where two years down the
    road
    you notice that some abstraction wasn’t very efficient, but now
    all
    your code depends on all the nice object models around it, and you
    cannot fix it without rewriting your app.
    In other words, the only way to do good, efficient, and system-level
    and
    portable C++ ends up to limit yourself to all the things that are
    basically available in C. And limiting your project to C means that
    people
    don’t screw that up, and also means that you get a lot of
    programmers that
    do actually understand low-level issues and don’t screw things up
    with any
    idiotic “object model” crap.
    So I’m sorry, but for something like git, where efficiency was a
    primary
    objective, the “advantages” of C++ is just a huge mistake. The fact
    that
    we also piss off people who cannot see that is just a big
    additional
    advantage.
    If you want a VCS that is written in C++, go play with Monotone.
    Really.
    They use a “real database”. They use “nice object-oriented
    libraries”.
    They use “nice C++ abstractions”. And quite frankly, as a result of
    all
    these design decisions that sound so appealing to some CS people,
    the end
    result is a horrible and unmaintainable mess.
    But I’m sure you’d like it more than git.

Linus