Java-та е тъп боклук

Батка, обяснявал съм ти 100 пъти, че конете с капаци са аут от бизнеса. Ако не си способен да се развиваш във всички посоки, вечно ще си трепериш за мястото. И изгонят ли те, става тежко. Единствените коне с капаци, които могат да са ценни, са тия, дето са супер развити в няква посока и/или фирмата е силно зависима от тях.
В конкретния случай си кодя на C++, но нямам нищо общо с решението на Гугъл юзер спейса на Андроида да е на Джава. Това което ми остава е да се съобразявам и да се опитвам да си свърша работата по най-добрия начин.

Окей, как се фиксват нещата без да имаш правото да пипаш класа? Принципно (или не?) се прави нещо такова (псевдо код):

A legacyMethod_CreateInstanceOfA(); // part of untouchable API

class B extends A
{
// greasy jewish slavedriver told me to fix the class, or else my services are no longer required
void quickPatch() {
access_protected_member1_of_A;
access_protected_member2_of_A;
job_done;
}
}

void main() {
A a = legacyMethod_CreateInstanceOfA();
B b = (B)a;
b.quickPatch();

a.WorkWithInstanceOfA();
}

ми много просто

class B extends A
{
// greasy jewish slavedriver told me to fix the class, or else my services are no longer required
void quickPatch() {
access_protected_member1_of_A;
access_protected_member2_of_A;
job_done;
}
}



void main() {
B a = new B;
ИЛИ
B a = newMethod_CreateInstanceOfB();

a.quickPatch();

a.WorkWithInstanceOfA();
}

нищо не си пипал, няма мръсен код, сафе

Нищо не ти се разбира от обяснението, обаче най-вероятно с рефлекшън ще стане твоята. Може и инструментиране, каквото те кефи.

В случая по добре е да оставиш тая работа на професионалистите защото само хабиш ресурси.

За съжаление Джавата не се припокрива на едно към едно нито с Ц, нито с Асемблер.
Преминаването от един на друг език не е толкова леко и се иска известно обновяване на знанията. Така че не е редно да се оплакваш, че една сравнително нова кола ти писка, защото не си си сложил колана, и да се чудиш как така този проблем отсъства при старата Лада на 30 години.

Спри да мислиш за inheritance...

С composition нещата стават перфектни.

class B extends A
{
public void getTheJobDone()
{
access_protected_member1_of_A;
access_protected_member2_of_A;
}
}

class C
{
public A = new A();
public B = new B();
}


void main()
{
C c = new C();
c.B.getTheJobDone();
c.A.WorkWithInstanceOfA();



Composition over inheritance пич...

е браво бе

завършваш с два инстанса + половината работа (да не дава господ инициализацията) я вършиш с единия инстанс, останалата, с другия.

Може да съм песимист но предполагам, че проблема е в това, че legacyMethod_CreateInstanceOfA(); идва от няково замразено фактори и е единствения начин за създаване на валидни инстанции на А. Така, че не може просто да си правиш Б-та без да го викнеш.

не знам как е в жабата, но в ц++ единствения наин да не можеш да направиш клас е да нямаш публик конструктор и да го правиш с някой френд.
в такъв случай обаче не можеш и да направиш клас който да го наследява.

така че аргумента отпада

Проблем с инстансите ли имаш? В менедж инваермънт? При положение, че нямаш "никаква тежка инициализация"?

Нали за псевдо код става въпрос...
Направи си рифакторинга на базата на този псевдо код, така както ги виждаш нещата

Въпросът не е дали можеш да направиш обект, а дали можеш да направиш _използваем_ обект.

Иначе това което прави Реконструктора е пълно малоумие, няма заплата за която бих се съгласил да се занимавам с такива идиотщини.

The last good thing written in C was Franz Schubert's Symphony No. 9.

ами по-добре е да си напишеш нов метод дето да ти прави използваем обект
ако не знаеш как питаш, търсиш, искаш размразяване на кода.

иначе такива малоумия обикновено излизат през носа.

ами ако ония протектед методи бяха привате, какво ще прави тогава?
пък щом са протектед - явно мислено е за наследяване.

абе изобщо целия пример е една голяма глупост.

той реконструктора май сменя работата секи месец, та може и да не му пука де.

при това такова чудо не може да бъде "всекидневна" и "обикновена" практика, както той го твърди

излишното си е излишно
а и от къде знаеш каква е инициализацията?

айде кажи сега какво става ако пача в клас Б променя състоянието на обекта за да може да стане работата
а ти после използваш другия инстанс, в който състоянието не е променено

не знам какво означава "бум" в случая, обаче да се твърди че каст от родител към наследник е "лоша практика" и не трябва да се прави е пълна глупост. за такива цели е измислено ртти или ако няма ртти се ползва някаква система за идентификация на класа.




NE SUTOR ULTRA CREPIDAM

Очевидно е, че в общия случай (като не можеш да пипат съществуващия код) не можеш да напишеш нов метод, който да прави използваем обект.

Напълно съм съгласен, че такива малоумия излизат през носа. И то не обикновено, а _винаги_.

The last good thing written in C was Franz Schubert's Symphony No. 9.

е не, не можеш да пипаш съществуващ код не значи не можеш да го препишеш и да го ръчнеш тук там

просто за спора

Е, ако можеш да го пренапишеш, решението е лесно.

The last good thing written in C was Franz Schubert's Symphony No. 9.

Друго иска Реконструктора.

The last good thing written in C was Franz Schubert's Symphony No. 9.

в повечето случаи говори за лош дизайн или кръпка а-ла реконструктр

един що-годе приемлив случай е ако имаш виртуална функция от родителския клас която има за параметър указател или референс към базовия клас и ти я реимплементираш. но и в тоя случай не трябва да се прави с лека ръка.

1. Без инициализация на клас А няма да минеш...така, че въпроса "от къде знаеш каква е инициализацията" не стои на дневен ред!

2. Нищо не си разбрал пич, не се излагай, моля те...на глупави въпроси не ми се отговаря...Но...все пак, ако клас Б промени състоянието на клас А, то в клас С нямаш проблем...(освен ако не правиш глупости и не разбираш основни неща, като велю тайп и референс тайп...)

3. Излишно казваш...ОК, има излишни неща в псевдо кода, който дадох, но ти май не схвана идеята...повтарям я за специално за теб Агрегация/Композиция наместо наследяване.