我正在为餐馆提供的菜肴做模型。我可以做一个像这样的菜类:
class Dish
attr_accessor :name, :price, :ingredients, etc...
def initialize(dish_name, dish_price, etc...)
name= dish_name
price= dish_price
end
end
关于内存使用,最好为每个盘创建盘的实例,<代码>盘。新(“咖喱鸡”,…)
为了澄清起见,ChickenCurry类将只包含一个构造函数,其中它设置了适当的字段,如下所示:
class ChickenCurry < Dish
def initialize
super("Chicken Curry", ...)
end
end
哪个使用更多的资源,Dish.new
还是ChickenCurry.new
?差异可以忽略不计吗?我计划拥有数千个这样的对象,因此即使是10 KB的差异也值得考虑。
我正在使用JRuby,所以在回答时请考虑JVM,但也欢迎回答与Matz的Ruby相关的问题。
这不是关于设计的问题。我只对资源使用感兴趣。
继承的全部目的是子类继承超类的公共内容,并添加它们需要的更具体的内容。
如果咖喱鸡没有糖,为什么它应该有一个字段文件。因此,IMHO您应该使用继承来进行良好的OO设计,所以要有一个具有共同点的超类,然后每个子类将继承共同点并为其添加更具体的内容。
如果您将所有内容都放在一个类中,那么将导致html" target="_blank">代码滥用,并产生大量不必要的字段。
简而言之,您需要根据您的案例使用继承和内聚的概念来制作一个好的OO设计。
什么使用更多内存,Class对象还是该类的实例?
当您构造菜肴的对象时,使用继承肯定会导致较少的内存使用。
对象是类的运行时表示,它将根据类中字段的内存需求占用内存。尽量减少字段的数量(通过继承和实际实现),您将拥有良好的内存占用。如果你把所有的东西都放在一节课上,那么肯定会有一个非常糟糕的记忆脚印。
假设在同一dish类中有1000个字段,并且在创建对象时,所有1000个字段将根据其数据类型占用一些内存空间。
通过继承和内聚,您可以拥有更好的内存占用OO设计。
P. S.:我是素食主义者:)
不要担心内存,要问自己的主要问题是:您的ChickenCurry
是否有任何扩展Dish
行为的行为?如果您的答案是否定的(就像您所说的那样只有构造函数),那么只使用一个类。
使您的系统清晰易懂。
把这个记在心里:
“过早优化是万恶之源”-DonaldKnuth
问题内容: 实施接口的最佳方法是什么? 让您的类实现ActionListener并将其添加为ActionListener: 或添加匿名ActionListener类的对象: 问题答案: 有些人(jeanette / kleopatra)表示几乎 从不 使用ActionListener,而是使用诸如AbstractAction之类的Action。让GUI类实现侦听器几乎总是一个糟糕的理想选择,因为这
实现接口的最佳方法是什么? 让您的类实现ActionListener并将其添加为ActionListener: 或者添加匿名ActionListener类的对象:
问题内容: 我对Python 3中的和类有些困惑。也许有人可以消除我的困惑或提供一些其他信息。 我目前的理解是,每个类(除外)都从称为的基类继承。但是每个类(包括)也是该类的一个实例,它是自身的实例,并且也从继承。 我的问题是: 是否有一个原因/设计决策,为什么是的实例并从中继承?对象的/ class是否也可以是对象本身? 类()如何成为其自身的实例? 哪一个是真正的基类或? 我一直认为这将是最“
假设我的代码是这样的: 简而言之,使用add()将对象添加到ArrayList时: ArrayList是“对对象的引用”的列表,还是“实际对象”的列表???
问题内容: Java中的类,对象和实例是什么? 问题答案: Java(和任何其他编程语言)是根据类型和值建模的。从理论上讲,值是某种信息量的表示,类型是一组值。当我们说值X 是类型Y 的实例时,我们只是说X是类型Y的值集合的成员。 这就是“实例”一词的真正含义:它描述的是一种关系而不是事物。 Java编程语言的类型系统支持两种类型,原始类型和引用类型。引用类型进一步分为类和数组类型。Java 对象
问题内容: 在同一个类的定义中创建对象并不奇怪吗?因为然后作为响应-该对象创建了一个新对象,然后该新对象创建了另一个对象,并且无限循环直到存储空间已满才开始永不结束。 问题答案: 在同一个类的定义中创建一个对象是否比响应该对象创建一个新对象并不奇怪,然后这个新对象创建另一个对象,并且无限循环开始 不,主方法仅在运行程序时运行一次。它不会再次执行。因此,该对象将仅创建一次。 认为您的主要方法超出了您