andron81,

хотя возможно меня сейчас начнут жестко пинать , обвиняя в полном непонимании ООП , но я вот о чем :

если предположить , что метод employees не абстрактный, можно было бы организовать в нем такой метод который эту сортировку бы осуществлял, хотя возможно это полный бред , хотя вот в это я тоже с трудом поверил , что так можно , когда увидел :

Сергей АрсеньевМожно при помощи Comparator и Arrays.sort(T[] a,Comparator<? super T> c)


ну то есть я могу создать метод Sorting внутри класса Employee в предположении, что Employee не абстрактный? (исходный код смотреть выше )
я просто не понимаю, если JAVA позволяет экземпляры класса (в нашем случае это Employee) создавать в виде элементов массива,
но тогда не укладывается в голове как мы можем организовать метод Sorting внутри класса Employee , который будет работать не только с текущим экземпляром , но и вмешиваться в другие. наверно это фантастика но это было бы идеальное решение . Хотя возможно это совсем недопустимо ?

Petro123andron81,
По ООП уже придумали Списки





совсем не пойму причем тут списки. я упростил задачу : свёл количество элементов к константе.
мне непонятна технология сортировки массива . Всё было бы ясно, если бы экземпляр содержал массив в качестве поля. но у нас элементы разбросаны по разным экземплярам каждый из которых будет содержать свой метод Sorting, тем не менее метод должен работать с группой экземпляров, но внутри одного метода, как так получается )))))))))))))))))

p.s. и не хочу пользоваться стандартными возможностями Comparator и Arrays.sort . хочу для понимания изобрести свой велосипед.

Petro123andron81Всё было бы ясно, если бы экземпляр содержал массив в качестве поля
Если тупой массив, то - Да.
Т.к. вы добаляете функционал типа сортировки, то массив уже не годится.
Что тут непонятного?


функционал сортировки я бы мог добавить в виде говнкода в методе main. но поэтому случаю я и спришваю если мы делаем так:



то с ваших слов выходит не представляется возможным спрятать логику сортировки в класс employees в виде метода - если так то оно понятно. Однако это выйдет если мы организуем экземпляры не как элементы массива, а как список.
Верно ?

Petro123andron81хочу для понимания изобрести свой велосипед.
Изобретайте - делайте наследник или помощник для массива. Но ОТДЕЛЬНЫЙ класс - список.

последнее предложение ваше про отдельный класс-список поясните, пожалуйста .

Petro123тогда будет:



да, тяжко для меня : вот это "абстрактныйКласс" вынос мозга )))))

Blazkowiczandron81Вы наверно вот так хотели написать ?

Ну, да. Многопоточность дала сбой.

andron81я наверно крайне невежественный в ООП. Но не понимаю как скажем в экземпляре "employees[0]" класса "pers" есть конструктор от класса fix, тогда как класс fix это наследник от pers , а не наоборот.
Класс FixedPriceEmployee расширяет класс Employee.

да. не спорю
andron81Экземпляр FixedPriceEmployee является так же экземпляром Employee. Поэтому всё что может Employee может и FixedPriceEmployee.

да. может я не так вопрос ставил ?
смотрите
Employee e = new FixedPriceEmployee();

выражение слева от "=" означает , что резервируется переменная e с типом Employee, то есть под экземпляр класса Employee .
а справа создаётся новый экземпляр с типом класса FixedPriceEmployee.
Но как это реально ??? присвоить переменной зарезервированной под класс Employee экземпляр FixedPriceEmployee?
Ведь последний является потомком первого, как раз-таки в экземпляре могут содержаться методы о которых не знает переменная e.

Blazkowiczandron81Ведь последний является потомком первого, как раз-таки в экземпляре могут содержаться методы о которых не знает переменная e.
Всё верно. И это не страшно.


ну как это не страшно ?

вам же никто не позволит сделать например вот так :

int i = 5;
i="Hello, world";

BlazkowiczМы можем обращаться с FixedPriceEmployee, как с Employee.


да, можем так как FixedPriceEmployee наследник Employee.
Blazkowicz Просто часть методов нам может быть не видна. Но мы используем переменную типа Employee в том случае когда нам всё равно какой именно там Employee внутри.


где там внутри ??? как может быть внутри Employee быть FixedPriceEmployee ? это в FixedPriceEmployee может быть Employee.

Blazkowicz...тип объекта должен быть наследником типа переменной.


вооот !
в этом то и фишка. в моём понимании наоборот )))
у меня именно это в голове и не укладывается
с точки зрения логики переменная e резервируется под предка (набор функций предка)
а объект наряду с функциями предка обладает ещё доп. функциями (набор функций предка + собственные функции)

и как можно первому дать значение в виде второго.

Blazkowicz
Мне кажется, вам стоило бы отложить ООП в сторону и освоить азы С\С++ или другого низкоуровнего языка. Тогда бы было поверх чего строить понимание.

ну да. я никогда не задумывался в такой конструкции как :

int i ;
i=10;

всегда расценивал с математической точки зрения. и мне этого хватало

Petro123,

вроде бы стал немного допекать :

Employee e = new FixedPriceEmployee();

мы в e присваиваем ссылку на экземпляр подкласса FixedPriceEmployee. А new FixedPriceEmployee() - это создание экземпляра. таким образом в "e" будут доступны только методы которые есть в "e" .
понятно , что если есть методы с такой же сигнатурой описанные в FixedPriceEmployee то будут они выполняться. но это другая история. Самое важно, что я для себя уяснил выделил выше.

Blazkowiczandron81понятно , что если есть методы с такой же сигнатурой описанные в FixedPriceEmployee то будут они выполняться. но это другая история. Самое важно, что я для себя уяснил выделил выше.

Смотри.




финт ушами мне пока рано .
спасибо участникам за помощь и терпение