使Objective-C类看起来很漂亮

Question

我想问你所有关于Objective C中代码味道的意见,特别是Cocoa Touch.我正在开发一个相当复杂的游戏,即将开始伟大的十二月重构.

我的很多课程,尤其是模型,都充满了处理内部业务逻辑的方法; 在我对抗大量头文件的战争中,我将隐藏在私人类别中.那些私人类别包含大量的声明,这让我感到不安......就像Objective-C一样让我对所有这些方法感到内疚.

我重构的越多(一件好事!),我就越需要保持所有这些重复(不太好).这只是感觉不对.

在像Ruby这样的语言中,社区强调非常简短,清晰,美观的方法.我的问题是,对于Objective C(特别是Cocoa Touch),您的方法有多长,控制器有多大,以及您在项目中找到的每个类的方法数量是多少？是否有任何特别漂亮,漂亮的课程由Objective C中的简短方法组成,或者它根本不是语言文化的重要组成部分？

披露:我正在阅读"The Little Schemer",这应该解释我的悲伤,重新:目标C.

Answer 1

美是主观的.对我来说,如果Objective-C类是可读的(我知道它应该做什么)并且可维护(我可以看到哪些部分负责做什么),它就很漂亮了.我也不喜欢被一个不熟悉的习语抛弃阅读代码.有点像你正在读书的时候,你读的东西会让你走出沉浸,并提醒你正在阅读.

你可能会得到很多不同的,互相排斥的建议,但这是我的想法.

• 私有方法属于私有类别没有错.这就是它的用途.如果您不喜欢堵塞文件的声明,请在IDE中使用代码折叠,或将扩展作为类别放在不同的文件中.
• 将相关方法组合在一起并用#pragma mark语句标记它们
• 无论您使用何种代码布局,一致性都很重要.花几分钟时间写下你自己的指导方针(这是我的指南)所以如果你忘记了你应该做的事情,你就有了参考.
• 控制器不必是委托和数据源,您可以始终拥有其他类.
• 对方法和属性使用描述性名称.是的,您可以记录它们,但是当Xcode应用代码完成时,您无法看到文档,其中命名良好的方法和属性得到了回报.此外,如果在代码本身更改时未更新代码注释,则代码注释会过时.
• 不要尝试编写聪明的代码.您可能认为最好在一行上链接一系列方法调用,但编译器在优化方面比您想象的要好.如果它提高了可读性,可以使用临时变量来保存值(大多数这些只是指针,所以相对较小).编写供人阅读的代码.
• DRY与其他语言一样适用于Objective-C.不要担心将代码重构为更多方法.只要它们有用,有很多方法没有错.

Answer 2

在实现类或方法之前,我做的第一件事就是问:"我怎么想从外面使用它？"

我从来没有,从来没有首先编写我的类和方法的内部.通过优雅的公共API开始,内部趋向于优雅免费,如果他们不这样,那么丑陋至少包含在单个方法或类中,并且不允许用其气味污染其余代码.

有许多设计模式,二十年的编码告诉我,经得起时间考验的唯一模式是:KISS.保持简单愚蠢.

对于任何语言或环境,一些一般的经验法则:

• 跟随你对你读过或听过的任何建议的直觉!
• 早退出来!
  • 如果需要,请尽早验证输入并快速拯救!减少清理工作.
• 切勿在代码中添加不使用的内容.
  • 对于选择"反向"可能会觉得东西不错的了了.
  • 在那种情况下,将它添加到路上!不要浪费时间增加你不需要的复杂性.
• 方法名称应描述完成的内容,而不是如何完成.
  • 只要结果相同,应允许方法更改其实现而不更改其名称.
  • 如果您无法从其名称中了解方法的作用,请更改名称!
  • 如果部分足够复杂,那么使用注释来描述您的实现.
• 不要害怕单身人士!
  • 如果您的应用只有一个数据模型,那么它就是一个单例!
  • 在整个地方传递一个变量只是假装它是除了单身之外的其他东西并且增加复杂性作为奖励.
• 从一开始就计划失败.
  • 始终使用doFoo:error而不是doFoo:从一开始.
  • NSError从头开始创建具有最终用户可读本地化描述的精美实例.
  • 将错误处理/消息改进到大型现有应用程序是一个很大的痛苦.
  • 如果您涉及用户和IO,将始终存在错误!
• Cocoa/Objective-C是面向对象的,而不是面向类的,因为大多数流行的孩子都声称自己是OOP.
  • 不要引入只有属性的哑值类,没有执行实际工作的方法的类也可以是结构.
  • 让你的对象变得聪明!FooParser如果你需要一个fooFromString:方法,为什么要添加一个全新的类Foo？
• 在可可,你能做的事情总是比你更重要.
  • 如果目标/操作可以执行,请不要引入协议.
  • 不要验证实例是否符合协议,是一种由编译器决定的类.