Может возврат класса объект себя
протестированный это на присвоения на 10 м номера 10
One:
real 0m5.610s
user 0m5.098s
sys 0m0.220s
Two:
real 0m6.216s
user 0m5.700s
sys 0m0.213s
Three:
real 0m12.986s
user 0m11.767s
sys 0m0.489s
Каждый, кажется, побеждает
Редактирование: JVM является стандартным '/usr/bin/java' в соответствии с Mac OS X 10.5
java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)[еще 118] редактирование:
Код, как требуется
public class One {
public static void main(String[] args) {
int someValue = 10;
for (int i = 0; i < 10000000; i++) {
String stringValue = Integer.toString(someValue);
}
}
}
случай 2 и 3 так же
выполненное использование
javac *.java; time java One; time java Two; time java Three
7 ответов
Да, может. Фактически, это именно то, что делает одноэлементный класс. Когда вы в первый раз вызываете его метод уровня класса getInstance () , он конструирует сам себя и возвращает его. Затем последующие вызовы getInstance () возвращают уже созданный экземпляр.
В вашем конкретном случае можно использовать аналогичный метод, но вам нужен какой-то способ определения списка последних изменений. Поэтому ему необходимо будет вести свой собственный список таких изменений. Вы можете сделать это с помощью статического массива или списка изменений. Просто убедитесь, что основная информация в списке не исчезнет - это могло произойти в C ++ (например), если вы поддерживали указатели на объекты и эти объекты были освобождены вашими клиентами.
В среде автоматической сборки мусора, такой как Java, проблема не возникает, поскольку объект не исчезнет, пока на него есть ссылка.
Однако у вас нет , чтобы использовать это метод. Я предпочитаю то, что вы описываете, - иметь два класса: список изменений и изменение. Когда вы создаете экземпляр класса изменений, передайте объект списка изменений (null, если вы не хотите, чтобы он ассоциировался со списком изменений) с конструктором и добавьте изменение в этот список перед его возвратом.
В качестве альтернативы создайте список изменений. метод, который сам создает изменение и возвращает его, запоминая изменение для своих целей.
Затем вы можете запросить список изменений, чтобы получить последние изменения (как бы вы ни определяли недавние). Это было бы более гибким, поскольку позволяет использовать несколько списков.
Another reason to return this is so that you can do function chaining:
class foo
{
private int x;
public foo()
{
this.x = 0;
}
public foo Add(int a)
{
this.x += a;
return this;
}
public foo Subtract(int a)
{
this.x -= a;
return this;
}
public int Value
{
get { return this.x; }
}
public static void Main()
{
foo f = new foo();
f.Add(10).Add(20).Subtract(1);
System.Console.WriteLine(f.Value);
}
}
$ ./foo.exe 29
There's a time and a place to do function chaining, and it's not "anytime and everywhere." But, LINQ is a good example of a place that hugely benefits from function chaining.
Да, класс может иметь метод, который возвращает экземпляр самого себя. Это довольно распространенный сценарий.
В C # пример может быть таким:
public class Change
{
public int ChangeID { get; set; }
private Change(int changeId)
{
ChangeID = changeId;
LoadFromDatabase();
}
private void LoadFromDatabase()
{
// TODO Perform Database load here.
}
public static Change GetChange(int changeId)
{
return new Change(changeId);
}
}
Методы свободного интерфейса работают на принцип возврата экземпляра самого себя, например
StringBuilder sb = new StringBuilder("123");
sb.Append("456").Append("789");
Класс часто возвращает экземпляр самого себя из того, что иногда называют «фабричным» методом. В Java или C ++ (и т. Д.) Это обычно был бы общедоступный статический метод, например, вы вызываете его непосредственно в классе, а не в экземпляре класса.
В вашем случае в Java это может выглядеть примерно так :
List<Change> changes = Change.getRecentChanges();
Это предполагает, что класс Change сам знает, как отслеживать изменения, а не за эту работу отвечает какой-то другой объект в системе.
Класс также может возвращать собственный экземпляр в одноэлементном шаблоне, где вы хотите убедиться, что в мире существует только один экземпляр класса:
Foo foo = Foo.getInstance();
Вам нужно подумать о том, что вы пытаетесь моделировать. В вашем случае у меня был бы класс ChangeList, содержащий один или несколько объектов Change.
С другой стороны, если вы моделировали иерархическую структуру, в которой класс может ссылаться на другие экземпляры класса, то то, что вы делаете, имеет смысл. Например, узел дерева, который может содержать другие узлы дерева.
Другой распространенный сценарий - реализация в классе статического метода, который возвращает его экземпляр. Это следует использовать при создании нового экземпляра класса.
Я не знаю ни одного правила проектирования, в котором говорилось бы, что это плохо. Так что, если в вашей модели одно изменение может состоять из нескольких изменений, сделайте это.