五 24
NearApple技术 Objective C, sharedInstance, Singleton, Template
原文：http://blog.mugunthkumar.com/coding/objective-c-singleton-template-for-xcode-4/
___FILEBASENAME___.h
1
2
3
4
5
6
7
8
9
10
| #import <foundation /Foundation.h>
@interface ___FILEBASENAMEASIDENTIFIER___ : NSObject {
}
+ (___FILEBASENAMEASIDENTIFIER___*) sharedInstance;
@end
</foundation> |
___FILEBASENAME___.m
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
| #import "___FILEBASENAME___.h"
static ___FILEBASENAMEASIDENTIFIER___ *_instance;
@implementation ___FILEBASENAMEASIDENTIFIER___
#pragma mark -
#pragma mark Singleton Methods
+ (___FILEBASENAMEASIDENTIFIER___*)sharedInstance
{
@synchronized(self) {
if (_instance == nil) {
_instance = [[self alloc] init];
// Allocate/initialize any member variables of the singleton class here
// example
//_instance.member = @"";
}
}
return _instance;
}
+ (id)allocWithZone:(NSZone *)zone
{
@synchronized(self) {
if (_instance == nil) {
_instance = [super allocWithZone:zone];
return _instance; // assignment and return on first allocation
}
}
return nil; //on subsequent allocation attempts return nil
}
- (id)copyWithZone:(NSZone *)zone
{
return self;
}
- (id)retain
{
return self;
}
- (unsigned)retainCount
{
return UINT_MAX; //denotes an object that cannot be released
}
- (void)release
{
//do nothing
}
- (id)autorelease
{
return self;
}
#pragma mark -
#pragma mark Custom Methods
// Add your custom methods here
@end |
八 23
NearApple技术 assign, attribute, copy, Objective C, property, readonly, readwrite
一直以来个人觉得如果一个类是的property是readonly的那么再指定其他的如assign/retain/copy这样的属性就实在是没有什么意义了。确实你想想既然都readonly了，肯定是没有setter的，既然没有setter那么谈assign/retain/copy又有什么意义呢？所以一直以来我从来不对readonly的property加retain/copy属性申明，默认assign就足够了，simple is beautiful！
但是我现在发现我错了，其实一直都有一种这种感觉，只是没有找到100％的充分理由为readonly加上retain/copy。但是假如你要在你的subclass改写property，而加入你要改写的是一个NSString，你像把这个属性设置为readwrite和copy，往往杯具就发生了，编译时候可恶的warning 产生了，因为copy和之前默认的assign明显不相同啊！
终上，不论什么时候，都要为你的readonly的对象属性加上合适的retain/copy申明。你现在不用，但不说明你将来就不会用，出来混迟早都要还的！
八 17
NearApple技术 Category, Objective C, OC, OCP, Protocol, webservice, 开放封闭原则, 继承
开放封闭原则（OCP）就是，“对扩展开放，对更改封闭”。是所有面向对象设计的一个核心宗旨。感兴趣的可以看百度百科的一些解释：http://baike.baidu.com/view/2493421.htm。
在用Objective C进行开发的时候，OCP当然也是宗旨。利用继承，多态是一个很好的保持OCP的办法，也是最常见的一种方法。Objective C还支持另外两种语法来支持OCP：Protocol和Category。（想要了解Objective c语法的可以看这里：http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html）。
Protocol只能定义一套接口，而不能提供实现，变相的也是一种Abstract class的实现方式（oc 语法上本身不支持抽象基类）。Category可以为类提供额外的接口和实现。那么到底三者（继承, Protocol，Category）在使用上到底有什么本质的区别呢？在我看来，protocol的作用是为一些列类仅仅提供一套公用的接口，而完全没有办法也没可能去提供具体的一些实现情况；category则是为一个已有的类提供一些额外的接口和具体实现；而继承则基于两者之间，既可以想protocol一样提供只是纯粹提供接口，也可以像Category一样提供完整的实现，而且继承还能对类以后的功能进行改写，所以说继承的力量是最强大的。那么具体在使用的时候各自都适合什么样的情况呢？
- Protocol是定义行为而不管谁去怎么实现，这是一种比较洒脱和不负责的情况，就好像在外包项目中的客户一样，他只是他需要什么什么东西，具体实现他不会也不能给出一样。delegate datasource这样的就用protocol实现比较好
- Category是对一个功能完备的类的一种补充，就像是一个东西的主要基本功能都完成了，可以用category为这个类添加不同的组件，使得这个类能够适应不同情况的需求（但是这些不同需求最核心的需求要一致）。找个就像你已经有了一辆能够开动的汽车一样，我们可以用Category为你的汽车添加各种之前没有的功能，最后让这辆汽车变成超级跑车一样。
- 继承则是都可以完成上面的工作，但是继承有很大的代价问题，一是通过继承来进行扩展是一种耦合很高的行为，对父类可以说是完全依赖；二是继承由于对父类依赖，所以开发代价相对大，要求对父类的工作流程相对熟悉；三是继承体系如果太复杂会导致整个系统混乱，难以维护。所以在能够用上面两种方法完成扩展的时候，就千万不要使用继承。什么情况才是迫不得已要使用继承呢？那就是如果你既想提供一系列接口的定义，同时又想提供一些但是又不能提供全部的实现的时候，这种情况就要使用继承了。所以这么看来继承是对上面两种功能的一个黏合剂。
之所以会想到这些，是因为自己在写一个webservice加载库的时候得到的体会。这个库已经提供了一系列最基本的加载webservice的功能，但是不同的程序webservice的api和类型都不是相同的，要怎么才能应用到不同程序中去呢？之前我一直想都不想直接继承了，产生一个新的webservice加载器，然后对不同api分别进行实现。但是每次这么做的时候就发现继承的时候做了很多重复而且没有什么创造性的工作。今天才突然发现了问题的所在，既然我的webservice库已经是一个功能基本齐备的加载器了，为什么我不简单的为这个加载器在不同的程序中创建不用的category呢，然后在复用一些已有的api，不就能够完成工作了吗？确实，我现在通过category的方式减少了之前太多太多的重复劳动，真恨自己为什么没有提早注意到这个问题。
RSS
Twitter
Buzz
LinkedIn
Flickr
近期评论