Kiedy OOP absolutnie nie pasuje do problemu i jak to poznać? Jakie jest wasze doświadczenie w tej sprawie?
Jak mam do przetworzenia dane w bazie danych. Nie ma nic bardziej produktywnego niż SQL + procedury.
yarel napisał(a):
Jak mam do przetworzenia dane w bazie danych. Nie ma nic bardziej produktywnego niż SQL + procedury.
Wyczuwam hejt na ORMy/
Gdzie się nie stosuje, chociaż zakazu nie ma:
- W przetwarzaniu numerycznym - w programowaniu "kerneli" sprawdzają się lepiej języki proceduralne (tzn. OOP niczego nie wnosi). Patrz OpenCL, OpenMP => Fortran/C.
- W bazach danych - PL/SQL i SQL to języki nieobiektowe
- W pisaniu jądra systemu operacyjnego
- W prototypowaniu obliczeń naukowych i ekonomicznych
- W oprogramowaniu rakiet kosmicznych i próbników
vpiotr napisał(a):
Gdzie się nie stosuje, chociaż zakazu nie ma:
- W przetwarzaniu numerycznym - w programowaniu "kerneli" sprawdzają się lepiej języki proceduralne (tzn. OOP niczego nie wnosi). Patrz OpenCL, OpenMP => Fortran/C.
- W bazach danych - PL/SQL i SQL to języki nieobiektowe
- W pisaniu jądra systemu operacyjnego
- W prototypowaniu obliczeń naukowych i ekonomicznych
- W oprogramowaniu rakiet kosmicznych i próbników
Dlaczego?
O, już sobie wyobrażam oprogramowanie rakiety na JVM jak sie nagle Garbage Collector odpala ;]
OOPa można mieć i bez garbage collectora.
Przetwarzanie danych (jakichkolwiek), wtedy operujesz na danych i obiektowe wrappery tylko potrafią komplikować sprawę, a nawet wręcz utrudniać (bo odciągają cię od prawdziwego problemu, na rzecz szczegółów implementacji typu "deserializacja danych do obiektów i z powrotem").
OOP to tylko sposób organizacji kodu i danych. Czy program składający się z jednego obiektu przetwarzajacego dane prywatne dla tego obiektu i udostępniający wynik metodą to program obiektowy? Formalnie tak. A przecież praktycznie niczym się nie będzie różnic od proceduralnego.
Krolik napisał(a):
OOP to tylko sposób organizacji kodu i danych. Czy program składający się z jednego obiektu przetwarzajacego dane prywatne dla tego obiektu i udostępniający wynik metodą to program obiektowy? Formalnie tak. A przecież praktycznie niczym się nie będzie różnic od proceduralnego.
Straszie szeroka definicja, można pod nią podciągnąć kod pisany w paradygmacie czysto funjcyjnym. w zasadzie prawie każdy kod.