Wpis z mikrobloga

#programowanie #programista15k #python
Ma ktoś jakiś dobry sposób na nauczenie się obiektówki? Wszystkie te przykłady ze zwierzątkami, pieskami i kotkami przerabiałem, ale to są tylko podstawy, a w prawdziwym kodzie dużo więcej się dzieje. Po prostu w głowie coś nie może mi przeskoczyć na ten sposób myślenia.
Od wieków pisałem proceduralnie i nigdy obiektówka nie była mi potrzebna (poza pojedynczymi przypadkami, gdzie udało się to obejść). Jak już mam Cos w tym grzebać, to jakoś sobie radzę, ale wiem, że w pełni tego nie rozumiem i potrzebuje dużo czasu by ogarnąć kod.
  • 24
@avr250: przykład trochę nietrafiony, bo asembler to jest inny poziom abstrakcji.
Natomiast wyjaśnij czym się różni poziom abstrakcji tych dwóch przykładów:

1. strukturalne: write(file, "foo")
2. obiektowe: file.write("foo")
Przecież to nawet tej samej długości jest (nie licząc white-space).
@Krolik: niczym, C++ zreszta tłumaczy wywołania metod w obiektów właśnie na takie wywołania funkcji jak pokazałeś. Tak samo w assemblerze:

push file
push "foo"
call write

Po prostu trzeba zadbać o przekazywanie argumentów i jest to mniej wygodnie niż w C. Ale da się zrobić te sama architekturę co w C i C++.
@avr250: Uważasz że miedzy strukturalnym a obiektowym jest taka różnica jak między asemblerem a strukturalnym? xD W asemblerze musisz znać dokładnie sprzęt na który piszesz program. Języki wysokiego poziomu pozwalają nie myśleć o sprzęcie, a pisać na abstrakcyjny, mocno uproszczony model tego sprzętu. Dzięki temu można napisać program raz i skompilować na wiele różnych sprzętów. A co wnosi OOP ponad programowanie strukturalne? Bez zrozumienia jaki problem rozwiązuje OOP raczej trudno będzie
@Krolik: To Twoja teza, a nie moja. Ja tylko napisałem, że czego byś nie zrobił w C, to i tak zostanie do skompilowane do kodu maszynowego. Czego byś nie zrobił w C++ też zostanie to zamienione w kod maszynowy. Czyli wszystko co da się zrobić w C i w C++ da się też zrobić w assemblerze. To, że istnieją różne architektury sprzętu jest nieistotne dla naszej dyskusji.