从Windows API迁移到Mac OS

可可是一种与MFC及其亲属完全不同的思维方式.如果您花时间了解Cocoa如何处理事物并适应其思维方式,而不是试图找到在ObjC中实现当前思维方式的最快方式,那么您将做得更好,更好.可以为Mac编写MFC风格的代码,但如果你这样做,你将永远与框架作斗争.我见过很多Windows开发人员都在努力解决这个问题.

学习Cocoa的最好的书是Cocoa Programming for Mac OS X.假设你是一个具有坚实OOP背景的C开发人员,这本书就是这本书的开头.如果您具有有限的面向对象背景,则从Programming Objective-C 2.0开始.

一旦理解了模式,您会惊讶于Objective-C可以快速编码.根据我的经验,与C相比,它确实令人惊叹.有更多类似RAD的系统,如REALbasic,你现在可以用Ruby开发Cocoa应用程序,这可以更快一些.但在ObjC的Mac市场上确实没有替代品.如果不使用Mac框架,很难制作出像Mac应用程序一样的应用程序,Mac用户往往比Windows用户对此类事情更加苛刻.

我没有LispWorks的背景,但LISP似乎是一种可怕的语言,用于开发Mac应用程序众所周知的丰富UI.我喜欢LISP(实际上非??常多),但是功能编程的“无副作用”哲学似乎与最丰富的UI目标不一致(特别是当Mac UI变得越来越以动画为中心时).如果有的话,Mac编程正朝着声明而不是功能编程发展(核心动画和Grand Central Dispatch有很多声明性的概念在蔓延).

没有像Windows那样大的第三方组件市场.其中一些原因是因为Cocoa已经提供了如此丰富的组件,而MFC没有这样做,并且因为行为良好的Mac应用程序需要使用这些组件,以便您像所有其他Mac应用程序一样工作. RadControls for .NET(非常好的工具包,那个)的商业组件市场肯定很少.但是有很多不错的免费组件可以使用灵活的许可证(通常是基于MIT的).我的一些最爱：

> Positive Spin Media’s excellent tabbar control
> OmniGroup’s frameworks(虽然我从来没有“按原样”使用它们,但它们最好用作如何做事的例子)
> Growl
> Sparkle
> RegexKit
> CocoaDev’s ObjectLibrary list of other stuff

正如我之前提到的,Mac用户对他们的UI很挑剔.比Windows用户更多,更多.他们希望事情能够得到完善,并且他们希望能够将所有能够与Mac相结合的小东西融为一体.这意味着拖放,Spotlight,服务,Applescript,Expose,QuickLook,集成拼写检查等.如果你不使用内置框架,很难做好所有这些事情.这就是为什么我建议新Mac开发人员从一开始就学习框架.

对于Mac,如果你有一堆硬件(如键盘和显示器),那么Mac Mini就是一个不错的便宜盒子.如果您想要一体机,iMac非常棒,如果您喜欢便携性,任何MacBook都是合适的.目前市场上没有Mac,这不是一个完美的开发盒.显然,如果你做了很多工作,8核Mac Pro可以让编译速度更快,但我已经在13英寸MacBook上做了很多专业开发.如果你想尽可能便宜地进入,请寻找refurbished或使用(我喜欢我翻新的Mac Mini).任何基于英特尔的Mac都可以用于开发,至少在你开始使用时.