FP vs OOP

0

Cześć,

mam do Was pytanie. Otóż jako zapaleniec - amator zacząłem uczyć się Pythona, ponieważ zawsze chciałem umieć coś samemu napisać. Jednak samodzielna nauka bez wsparcia kogoś obeznanego w temacie napotyka pewnego rodzaju momenty, w których to za cholerkę nie można czegoś zrozumieć. Wtedy zazwyczaj taki temat wrzuca się do działu "na później" licząc na to, że za jakiś czas wreszcie coś w głowie zaskoczy. W taki oto sposób pominąłem naukę OOP.

Oczywiście w sieci jest mnóstwo tutoriali, w których to tworzy się klasę rycerza, samochodu czy psa, ale do mnie to nie przemawia. Zapewne dlatego że nie zajmuję się takimi tworami. Moje aplikacje w 90% są oparte o GUI, a pozostałe 10% konsolowe (głównie Linux chociaż Windows też się trafia). Próbowałem już wiele razy podejść do tematu, jednak bezskutecznie. Nie wiem kiedy i co powinno mieć self, a co nie. Programowanie funkcjonalne opanowałem, jednak chciałbym się także wreszcie nauczyć obiektowego.

I tu moje pytanie: Czy znacie może jakieś źródła wiedzy, które mogłyby mi moje braki uzupełnić?

A może nie skupiać się na OOP skoro FP mam opanowane? Oba paradygmaty mają jeden cel, jakim jest tworzenie zrozumiałych i wolnych od błędów programów, a jego wybór należy właśnie do osoby piszącej.

1

Python nie jest językiem funkcyjnym, (nie ma typowych - immutable struktur danych używanych w FP) możesz tylko pewne konstrukcje z FP stosować, HOF, pure functions, functions as first class citizens; powiedziałbym, że użycie tych technik czyni programowanie proceduralne przejrzystszym, łatwiejszym do testowania, etc... OOP na pewno Ci się przyda, praca z bibliotekami, gdzie tworzysz klasę dziedziczącą z zaimportowanej, przy uzyciu super inicjalizujesz obiekty...
Co do self, to to samo co this w innych językach, różnica jest taka, że zawsze je przekazujesz do metody, jako pierwszy parametr.
https://realpython.com/python3-object-oriented-programming/
https://runestone.academy/runestone/books/published/thinkcspy/ClassesBasics/toctree.html

4

Moje aplikacje w 90% są oparte o GUI

No ale to też jest dobra rzecz do OOP - masz obiekt okno który posiada właściwości w stylu height czy width, może posiadać jakieś elementy składowe w stylu przycisków czy editów. One także mogą/powinny być obiektami, przez co możesz korzystać w pełni z pisania w postaci okno.przyciskOK.height = 50.

Co do wyboru "zwykłe programowanie vs. OOP" - zabrzmi to jak slogan, ale dobór techniki powinien byś dopasowany do tego, co konkretnie robisz. Na pewno pchanie na siłę OOP wszędzie (ale także jakiegokolwiek innego paradygmatu) tylko dlatego, bo to jest "seksi" nie ma sensu. Ale z drugiej strony - skoro za bardzo OOP nie kojarzysz i nie umiesz, to może po prostu nie widzisz, w jaki sposób by miało to sens. Piszesz, że robisz aplikacje konsolowe - ale nie napisałeś nic o tym, co one mają robić.

Tak na szybko mi przychodzi do głowy - możesz zrobić sobie np. obiekty, które odpowiadają za wypisywanie tekstów na ekranie. W ten sposób, jak będziesz chciał coś wyświetlić, to po prostu skorzystasz z obiektu output i dasz mu polecenie write. I nie obchodzi Cię cała reszta - jak technicznie to zostanie zrealizowane. Na pierwszy rzut oka może się to wydawać zbędnym komplikowaniem czegoś prostego. Ale jakbyś za jakiś czas chciał dodać obsługę drukarki, albo jakąś komunikację sieciową, to zamiast screen dajesz jako output obiekt printer czy sendViaTCP. I z punktu logiki aplikacji NIC się nie zmienia - dajesz polecenie wypisania danych. A to już wewnętrzna logika obiektu odpowiada za to, żeby później te dane wyświetlić w adekwatny sposób - czyli na ekranie, drukarce, albo przesłać przez sieć.

Poza tym wiele z istniejących bibliotek, z których możesz chcieć skorzystać, to jest kod OOP - więc chociażby dlatego warto się tego nauczyć.

EDIT

Python nie jest językiem funkcyjnym, możesz tylko pewne konstrukcje z FP stosować

@lion137 - wydaje mi się, że OP pisząc o języku funkcyjnym nie miał na myśli typowego FP (jak np. Haskell), tylko pisanie kodu z procedurami/funkcjami, które sobie luźno wiszą, nie są spięte w żadne obiekty, nie są metodami itp. Po prostu - w kodzie na funkcje, więc pisze funkcyjnie ;)

3

@Dorian331: wydaje mi się że mylisz programowanie funkcyjne z proceduralnym.

2

Do OOP masz takie pozycje:

Czytaj raczej coś co jest specyficzne dla Pythona bo on ma kilka odchyleń od normy.
Poczytaj: https://www.quora.com/What-OOP-features-is-Python-missing

A jeśli chodzi o FP to też warto przeczytać coś specyficznego, Python nie jest językiem czysto funkcyjnym ale można kilka jego elementów wykorzystać w tym celu:
https://helion.pl/ksiazki/python-programowanie-funkcyjne-steven-f-lott,pythpf.htm#format/e

0

Jeśli chodzi o FP i coś robieniu w tym kierunku to przejdź na Elixir

1

Zastrzeżenia co do przydatności OOP mnie nie dziwią, zważywszy na to jak jest zwykle prezentowane. Polecam ten wykład Alana Kaya (twórcy pojęcia i języka SmallTalk): . Dużo mi wyjaśnił na ten temat, sam przyznaje, że nazwa OOP jest bardzo myląca. :)

Niezależnie od tego, OOP jest opcjonalne, zwłaszcza jak robisz dobre FP, ale do tego to inne języki są dobre. Ja np. lubię scalę.

1 użytkowników online, w tym zalogowanych: 0, gości: 1