Как сейчас рынок в UK для Junior Java

[crypto5]

Code: Select all

		Holder<Integer> a = Holder.new(1);
		Holder<Integer> b = Holder.new(2);

Вот так красивее

Что то не ест у меня
А вот так съела

Code: Select all

		Holder<Integer> a = new Holder (1);
		Holder<Integer> b = new Holder (2);

Я имелв виду что new() это кастомный статический метод, но так нельзя, new слово зарезервировано, можно поменять на create например. А твой вариант не типобезопасен, ты можешь в контруктор хоть стринг передать, все равно ошибки компиляции не будет, только варнинг.

[valchkou]

на самом деле swap на жабе делается например так

public static void main(String[] args) {
Integer a = 1;
Integer b = 2;
Integer i = a;
a = b;
b = i;
System.out.println("a: " + a + ", b: " + b);
}

а придумывание холдеров и прочего это скорее для интервью, чтобы отсеять кандидатов их придумывающих.

[M. Ridcully]

а придумывание холдеров и прочего это скорее для интервью, чтобы отсеять кандидатов их придумывающих.

Т.е. правильный ответ - swap (как ф-ция) жабе не нужен?

[valchkou]

а придумывание холдеров и прочего это скорее для интервью, чтобы отсеять кандидатов их придумывающих.

Т.е. правильный ответ - swap (как ф-ция) жабе не нужен?

гениально ! я сам бы до этого не допер

[crypto5]

а придумывание холдеров и прочего это скорее для интервью, чтобы отсеять кандидатов их придумывающих.

Т.е. правильный ответ - swap (как ф-ция) жабе не нужен?

Я например уже и не помню когда такое бы понадобилось, вполне возможно что не нужен

[Интеррапт]

В копилку к тому, что Джава, как язык, устаревает. По сравнению с тем же C#, где возможно параметры передавать и by value и by reference.

[dotcom]

Радует, что нашими стараниями каждый топик сваливается в java bash русло.

[crypto5]

В копилку к тому, что Джава, как язык, устаревает. По сравнению с тем же C#, где возможно параметры передавать и by value и by reference.

Бизнес кобол и должен быть максимально простым языком. Я и так считаю что джава перегружена фичами.

[Интеррапт]

Бизнес кобол и должен быть максимально простым языком.

Простой - это не значит, что языку для нормального функционирования нужно столько бойлер-плейт кода. Swap? Извольте писать отдельный holder класс (или массив использовать). Properties? Извольте вводить локальную переменную и писать многостраничные getter/setters, к каждому из которых нужно еще и javadocs прикручивать. И т.п.

[Sergunka]

В копилку к тому, что Джава, как язык, устаревает. По сравнению с тем же C#, где возможно параметры передавать и by value и by reference.

Ну, тут замысел на мой взгляд более хитровывернутый оказывается Integer, Double, Boolean и прочие как и String immutable т.е. неизменямые объекты типо чтоб народ очень повеселить на предмет мультипоточности

Поэтому тот же StringBuffer будет в подобной ситуации работать, а immutable классы нет. В scala это даже явно указывается чтоб чего не перепутать.

[Интеррапт]

Радует, что нашими стараниями каждый топик сваливается в java bash русло.

А топикстартер этот все-равно задает почти риторические вопросы, а когда ему чего-то в других топиках советовали, то он особо на советы не реагировал

[Sergunka]

Swap? Извольте писать отдельный holder класс (или массив использовать).

Ну только для иммютабл классов для того же StringBuilder вполне и так прокатит

Code: Select all

	private static void swap(StringBuilder a, StringBuilder b) {
		StringBuilder i = new StringBuilder(a);
		a.delete(0, a.length()).append(b);
		b.delete(0, b.length()).append(i);
	}

[crypto5]

Бизнес кобол и должен быть максимально простым языком.

Простой - это не значит, что языку для нормального функционирования нужно столько бойлер-плейт кода.

отсутствие pass by reference параметров это такой подход к дизайну, как в хаскеле например, жертвование элементами удобства в пользу борьбы с сайдэфектами.

[Интеррапт]

Бизнес кобол и должен быть максимально простым языком.

Простой - это не значит, что языку для нормального функционирования нужно столько бойлер-плейт кода.

отсутствие pass by reference параметров это такой подход к дизайну, как в хаскеле например, жертвование элементами удобства в пользу борьбы с сайдэфектами.

Да я вас прошу. Весь этот "подход к дизайну" постепенно убирается в пользу большего удобства. Достаточно посмотреть эволюцию Джавы. Так что еще увидим версию, в которой out параметры появятся.

[crypto5]

Бизнес кобол и должен быть максимально простым языком.

Простой - это не значит, что языку для нормального функционирования нужно столько бойлер-плейт кода.

отсутствие pass by reference параметров это такой подход к дизайну, как в хаскеле например, жертвование элементами удобства в пользу борьбы с сайдэфектами.

Да я вас прошу. Весь этот "подход к дизайну" постепенно убирается в пользу большего удобства. Достаточно просмотреть эволюцию Джавы. Так что еще увидим версию, в которой out параметры появятся.

А поподробнее про убирается?

[Cabron]

Вот так:

Code: Select all

public class Swapper	 {
       public static void main(String[] args) {
	      Integer a = new Integer(1);
	      Integer b = new Integer(2);
	      
	      swap (a, b);
	      System.out.println("a: " + a +", b: " + b);
	}

	   private static void swap(Integer a, Integer b) {
	        int i = a.getVal();
	        a.setVal(b.getVal());
	        b.setVal(i);
	   }

}

class Integer {
	   private int val;

	   public Integer(int val) {
		   this.val = val;
	   }	   
	   public int getVal() {
	       return val;
	   }
	   public void setVal(int val) {
		   this.val = val;
	   }	   
	   public String toString() {
		   return String.valueOf(val);
	   }
}

[crypto5]

Вот так:

Code: Select all

public class Swapper	
       public static void main(String[] args) {
	      Integer a = new Integer(1);
	      Integer b = new Integer(2);
	      
	      swap (a, b);
	      System.out.println("a: " + a +", b: " + b);
	}

	   private static void swap(Integer a, Integer b) {
	        int i = a.getVal();
	        a.setVal(b.getVal());
	        b.setVal(i);
	   }

}

    class Integer {
	   private int val;

	   public Integer(int val) {
		   this.val = val;
	   }	   
	   public int getVal() {
	       return val;
	   }
	   public void setVal(int val) {
		   this.val = val;
	   }	   
	   public String toString() {
		   return String.valueOf(val);
	   }
}

Идея Сергунки лучше, т.к. у него не надо под каждый Long, Object, YourClass новый враппер делать.

[vm__]

...По сравнению с тем же C#, где возможно параметры передавать и by value и by reference.

А в античном (древнейшем/классическом) С можно ли было передавать и так, и так?
А в Фортранах всяких? (в ассемблере про такое, наверное, и задумываться даже не всякий станет?)
Давно пора уже идеи ("обобщённые"!) передавать, а не всякую там застарелую хрень!
Или вообще т.наз. инновации, а?

[Cabron]

Идея Сергунки лучше, т.к. у него не надо под каждый Long, Object, YourClass новый враппер делать.

Но с Integer-ами в итоге работает

А в своем классе я и так state поменяю как мне надо, если он не immutable.

[Интеррапт]

OMG. Только давайте не будем действительно код для swap писать
Holder pattern для Java настолько уже избитая штука, что даже не смешно.
Если кому уж так нужно, то берем обычный common lang и используем MutablePair

[crypto5]

Идея Сергунки лучше, т.к. у него не надо под каждый Long, Object, YourClass новый враппер делать.

А в своем классе я и так state поменяю как мне надо, если он не immutable.

А если в том классе 100500 полей?

[Cabron]

OMG. Только давайте не будет действительно код для swap писать
Holder pattern для Java настолько уже избитая штука, что даже не смешно.
Если кому уж так нужно, то берем обычный common lang и используем MutablePair

Вся Java в общем-то уже избитая штука со своими паттернами. Уже рекоммендуют switch statements заменять ООП дизайном, иначе некошерно. Целые лекции проводят о том, как правильно переписывать toString.

[Cabron]

Идея Сергунки лучше, т.к. у него не надо под каждый Long, Object, YourClass новый враппер делать.

А в своем классе я и так state поменяю как мне надо, если он не immutable.

А если в том классе 100500 полей?

Ну тогда рапперы делать если надо именно поменять референсы на объекты этих классов. Но обычно нужно просто изменить state самого объекта.
Насчет 100500 полей - плохой дизайн ООП.

[crypto5]

Идея Сергунки лучше, т.к. у него не надо под каждый Long, Object, YourClass новый враппер делать.

А в своем классе я и так state поменяю как мне надо, если он не immutable.

А если в том классе 100500 полей?

Ну тогда рапперы делать если надо именно поменять референсы на объекты этих классов. Но обычно нужно просто изменить state самого объекта.
Насчет 100500 полей - плохой дизайн ООП.

Ну вы же на работе открывая чужой код и видя плохой дизайн ООП не увольняетесь немедленно? Что то нужно делать!

[Cabron]

Идея Сергунки лучше, т.к. у него не надо под каждый Long, Object, YourClass новый враппер делать.

А в своем классе я и так state поменяю как мне надо, если он не immutable.

А если в том классе 100500 полей?

Ну тогда рапперы делать если надо именно поменять референсы на объекты этих классов. Но обычно нужно просто изменить state самого объекта.
Насчет 100500 полей - плохой дизайн ООП.

Ну вы же на работе открывая чужой код и видя плохой дизайн ООП не увольняетесь немедленно? Что то нужно делать!

Нужно загнать все объекты в ActiveMQ и пойти выпить кофе. Серьезно.