Tom*_*m R 3 java oop performance android
在他们的Android开发者文章中,Google声明你应该通常使用getter和setter来声明公共变量而不是私有变量来增强嵌入式设备的性能(我认为函数调用比写入地址更昂贵).
我想知道 - 在多大程度上应该牺牲性能来坚持OOP范式？在其他情况下,优化是否意味着脱离"良好"的编码实践？
只要性能没有受到明显影响,就应该使用适当的抽象.
过早优化令人尴尬.
当公司发表类似的陈述时,我讨厌它,但不提供统计数据来量化问题.
这就是说:权衡并不是OO范式.如果你同时拥有get和set,并且这是类设计的固有部分,那么从OO的角度来看,将变量设置为public是完全有效的.如果性能提升足够重要,我会在这些情况下公开变量,但不会.
从某种意义上说,我认为这取决于性能对您的应用程序的重要程度,以及您通过使用您可能不会认为"好"的编码实践看到的性能提升程度.但话虽如此,我总是鼓励开发人员不要坚持教条并继续以同样的方式编写代码,因为这是你教授的方式是"正确的".如果你很好地记录代码并使用一致且可解释的编码实践,那么我认为做一些可能不适合"OOP范例"的事情是完全正确的.最后,它是关于可维护的工作代码.
一般而言,所有形式的工程都是处理权衡的问题.您需要将一种方法的成本与另一种方法的成本进行比较.
以牺牲其他任何东西为代价来牺牲可维护性总是很棘手,因为很容易低估不可维护代码的未来成本.
"程序优化的第一条规则:不要这样做.程序优化的第二条规则(仅限专家!):不要这样做." - Michael A. Jackson
也就是说,有一些论点认为拥有访问器的好处实际上非常小.有多少次你曾经用一种实际做某事的方法替换一个只读/写一个字段的getter或setter？鉴于这在实践中似乎有多么罕见,人们可能会争辩说,使用访问器是"过早的悲观化".