LitwinWileński napisał(a):
wartek01 napisał(a):
orchowskia napisał(a):
Są klasy, które powinno się rozszerzać przez dziedziczenie
możesz podać przykład poza wzorcem projektowym Template, który w sumie i tak może być zastąpiony przez kompozycję.
Nie wiem, co masz na mysli, a to jak sobie wyobrażam wskazuje, ze nie będzie któregoś stopnia sprawdzania przez kompilator, przeniesione na runtime.
orchowskia napisał(a):
Wiem że mnie nikt nie pytał, ale ja tam jestem za tym żeby w ogóle nie dało się dziedziczyć a zamiast tego tylko implementować interfejsy. Takie sprytne wpinanie się w jakąś bibliotekę/framework i podmienianie ich wnętrzności już widziałem i skończyło się to tym że nie mogliśmy ich później zaktualizować - a bez tego nie mogliśmy podbić wersji javy itd.
Bo ktoś uznał, że to nie jest zewnętrzny interface rozwiązania. Tylko zapomnieli dodać final. Ryzyko wiąże się nie tylko z tym, że będzie ciężko zrobić upgrade. Gorzej, że możesz niechcący zmienić sposób działania klasy, po której dziedziczysz.
Pewnie że to skrajna opinia, ale zdecydowanie zbyt często dziedziczymy i założenie że programiści dziedziczą i robią tak żeby było dobrze jest wg. mnie naiwne bo w 90% przypadków nie wiedzą albo i nawet się nie zastanawiają nad tym co robią.
Co to znaczy "zdecydowanie zbyt często"? Ja nie pamiętam kiedy faktycznie coś tam dziedziczyłem, ale też piszę coraz mniej "obiektowo".
Scope pakietowy może pomóc itd, ale co z modułami? Java 9 już jest z nami jakiś czas i w sumie to nie widziałem żeby ktoś tego używał a mam wrażenie że mogłyby kilka problemów rozwiązywać.
Ile widziałeś intencjonalnych przypadków użycia dostępu pakietowego? I jeszcze takiego, żeby faktycznie to coś robiło, a nie tylko gasiło ostrzeżenie lintera. A Java 9 może jest stara, ale wciąż sporo jest projektów na J8. No i dlaczego ktoś, kto nie rozumie podziału projektu na jednostki miałby się przejmować stosowaniem modułów, skoro wprowadzają one dodatkowe upierdliwości do projektu?
Taki wykastrowany język w projektach większej złożoności tylko spowoduje wiecej syfu, przestanie być "turing-complete" (w luźnym sensie) bo ludzie będą emulować dziedziczenie / mutowalność / wstaw friczer jaki lubisz. Jakaś proteza w postaci wyniesienia poza jezyk (XML-programming, lubi ktoś ?), przeniesienie kontroli z kompilatora na runtime itd ...
Jakoś @jarekr000000 sobie radzi ;]
scibi_92 napisał(a):
Taki wykastrowany język w projektach większej złożoności tylko spowoduje wiecej syfu, przestanie być "turing-complete" (w luźnym sensie) bo ludzie będą emulować dziedziczenie / mutowalność / wstaw friczer jaki lubisz. Jakaś proteza w postaci wyniesienia poza jezyk (XML-programming, lubi ktoś ?), przeniesienie kontroli z kompilatora na runtime itd ...
Jakoś @jarekr000000 sobie radzi ;]
Nie tylko, że radzę sobie dobrze bez zmiennych, dziewiczenia, pętli itp. - to jeszcze czasem piszę w języku, który nie jest "turing-complete" i chciałbym, żeby więcej takich było.
LitwinWileński napisał(a):
możesz podać przykład poza wzorcem projektowym Template, który w sumie i tak może być zastąpiony przez kompozycję.
W Javie? Enum.
Jeśli chodzi o taki przykład z kodu to stary jak świat przykład uczelniany:
public class Person {
private final int uniqueId;
private final String name;
private final String surname;
// Getters
}
public class Student extends Person {
private final String studentId;
// Getters
}
Za pomocą kompozycji:
public interface Person {
String getName();
String getSurname();
}
public class ConcretePerson implements Person {
private final String name;
private final String surname;
// Getters
}
public class Student implements Person {
private final Person person;
private final String studentId;
public String getName() {
return person.getName();
}
public String getSurname() {
return person.getSurname();
}
public String getStudentId() {
return studentId;
}
}
Ani to nie jest specjalnie czytelne, ani też logiczne - bo sugeruje, że student składa się z osoby i numeru indeksu. W przypadku, gdy wiesz, że student nie może być jednocześnie profesorem czy pracownikiem uczelni takie rozwiązanie jest najczytelniejsze, i tyle.
jarekr000000 napisał(a):
scibi_92 napisał(a):
Taki wykastrowany język w projektach większej złożoności tylko spowoduje wiecej syfu, przestanie być "turing-complete" (w luźnym sensie) bo ludzie będą emulować dziedziczenie / mutowalność / wstaw friczer jaki lubisz. Jakaś proteza w postaci wyniesienia poza jezyk (XML-programming, lubi ktoś ?), przeniesienie kontroli z kompilatora na runtime itd ...
Jakoś @jarekr000000 sobie radzi ;]
Nie tylko, że radzę sobie dobrze bez zmiennych, dziewiczenia, pętli itp. - to jeszcze czasem piszę w języku, który nie jest "turing-complete" i chciałbym, żeby więcej takich było.
Na marginesie: przypisałeś scibi moje slowa.
Dla mnie akurat "turing-complete" (w użytym tu sensie) jest duża wartością
... chociaż ...
Mocno we mnie jest obecny embedded language / język wbudowany, od lat ta koncepcja mi do kilka lat wraca. I ten "wewnętrzny" .. może nie sam język, ale jego biblioteka standardowa nie tylko nie musi, ale nie powinna być "turing-complete"
Ale to zupełnie inny obszar, zupełnie inny punkt cięcia