Programowanie obiektowe a sQL

Question

Witam

mam taki problem, z którym nie mogę sobie poradzić, nie dotyczy on stricte programowania, czy zaptań jeżeli chodzi o SQL'a raczej to problem typu "Po co?"

Dajmy dla przykłady SQLite i Pythona (ale to może być wszystko inne - MySQL, Postgre etc Java, C# czy każdy język, który ma paradygmat obiektowości).

No i tutaj pytanie, po co obiektowość, skoro sam rekord w bazie można potraktować jako obiekt w tym przypadku. Dla przykładu
Mamy table id, imie, nazwisko, mail
To po co jeszcze tworzyć to samo z poziomu kodu? No i co potem wsadzać do bazy danych? self.imie, self.nazwisko i self.mail? Jakby nie potrafię zrozumieć tego po co coś takiego robić?

Czy może obiektowość tego typu powinna wyglądać w następujący sposób:
Tworzymy klasę User/Uzytkownik
Następnie w initcie wsadzamy naszą bazę danych - chodzi o te wszystkie connection, cursor oraz metody które daliśmy dla klasy baza danych.
No i wreszcie robimy metody, które będą odzwierciedlać użytkownika czyli dodaj_uzytkownika(self, imie, nawisko, mail). I wtedy używając naszej self.db wykonujemy execute z Insertem do db?

Czy dobrze to rozumiem? Czy może jednak jest coś jeszcze co warto na początku przygód z obiektowością przy bazach danych wiedzieć?

Z góry dzięki :)

Answer 1

Jeśli nic nie robisz po drodze z tymi danymi w kodzie, to rzeczywiście kod jest bez sensu, można wystawić do używania samą bazę. Zazwyczaj jednak coś z nimi robisz, w jakiś sposób je przetwarzasz, weryfikujesz, podejmujesz decyzje w oparciu o nie, komunikujesz się z innymi aplikacjami w oparciu o te dane.

Dużo rzeczy można zrobić z poziomu samego SQL, kiedyś się tak robiło, ale SQL nie jest zbyt czytelny ani nie pozwala na bardzo dużo, nie ma do niego wielu bibliotek itd. Zazwyczaj aplikacje oparte głównie na SQL sprawiały dużo problemów przy większej skali. Później była moda na pisanie jak najmniej SQL samemu, najlepiej wcale i używanie ORM do wszystkiego co możliwe. Osobiście po latach obserwowania różnych podejść, uważam że najlepiej jest to odpowiednio zbalansować, mieć procedury SQL które wykonują proste akcje wokół bazy danych, poza prymitywną edycją danych potrafią wykonać proste operacje, typu podstawowa weryfikacja spójności albo podstawowa normalizacja

A obiektowość to po prostu jeden z sposobów wyobrażenia sobie jak działa projekt i masz mechanizmy w językach które ułatwiają pisanie kodu żeby wyglądał "jak w twojej wyobraźni", nic więcej. Takich sposobów jest sporo, jest podejście strukturalne, obiektowe, funkcyjne, proceduralne itd.

Kiedyś była moda na obiektowość i dużo książek z tamtego okresu wprowadza narracje że to najlepsze co udało nam się wymyślić, w ostatnich latach dużo ludzi widzi, że fascynacja obiektowością często powoduje mnóstwo problemów, lepsze jest podejście funkcyjne bo zmusza programiste do unikania wielu problemów... ale to też tylko obecna moda, za 5-10 lat będziemy na to narzekać i będziemy zachwycać się czymś innym.

Comments

Haha racja, widzę właśnie tę narrację nastawioną na obiektowość i sam też widzę przyjemność z funkcyjnego programowania, jednak chcę poznać możliwość każdego paradygmatu :)

W ogóle za tak obszerną odpowiedź :)

---

@marcin99b,

Takich sposobów jest sporo, jest podejście strukturalne, obiektowe, funkcyjne, proceduralne itd.

Strukturalne to jakie? Podasz przykłady?

---

Marcin dobrze opisałeś problem. Programowanie funkcyjne jest super, przykładowo taki ELM na froncie sprawia, ze niemal unikamy błędów w kodzie finalnym. Elixir też jest ciekawym językiem, a szczególnie jego ekosystem.

Co do:

ale to też tylko obecna moda, za 5-10 lat będziemy na to narzekać i będziemy zachwycać się czymś innym

za 10 lat może AI zastąpić kompletnie programistów, AI tak zapierdziela....

 

---

@reaktywny, Takie dość prymitywne które jest w prawie każdym współczesnym języku - takie oparte na ifach, pętlach, blokach kodu itp

Praktycznie każdy popularny język jest u swoich podstaw strukturalny, nie da się napisać zbyt dużo kodu bez używania elementów programowania strukturalnego... ale zamiast używania go jako samej podstawy, można pisać kod w większości ograniczony do tych podstaw - w sql i cobolu często się ogranicza do tych podstaw

Tak samo nie da się napisać pełnoprawnej aplikacji bez używania funkcji, a korzystanie z nich nie sprawia że nagle piszemy kod z podejściem "funkcyjnym"

---

Wiem czym są języki funkcyjne czy paradygmat funkcyjny, bowiem jeden język może wspierać ich kilka (jak np. Python). Nie spotkałem się z językiem strukturalnym, tylko paradygmatem strukturalnym.

Tu jest to nieźle opisane:

https://boringowl.io/blog/czym-jest-programowanie-strukturalne

---

Też sie nie spotkałem z językiem strukturalnym i nigdzie nie napisałem że takie są, tak samo nie spotkałem się z obiektowym ani funkcyjnym, bo każdy pełnoprawny język zawiera kilka paradygmatów

Ale pisząc kod któryś z nich jest dominujący w konkretnym projekcie.

Często twórcy języków preferują określony paradygmat i projektując język, troche sugerują którego chcieliby żeby ludzie używali, ale jeszcze nie spotkałem się z wymuszaniem któregoś

---

Mogę się mylić ale Elixir, ELM, Scala, F#, OCaml czy Haskell wspierają (chyba) tylko paradygmat funkcyjny. Co do Elixir jestem pewien, natomiast reszty nie znam za bardzo.

Pomijając oczywiście podejście strukturalne, bo to wykorzystuje chyba każdy język,

---

Z elixirem, scalą, ocamlem i f# to na pewno się mylisz, bo na pewno mają mieszane paradygmaty. Twórcy projektowali je myśląc o programowaniu funkcyjnym, ale wrzucili też inne rzeczy, żeby te języki były bardziej uniwersalne.

Kiedyś interesowałem sie paradygmatami i podobno haskell jest najbardziej "czysty rasowo" w kontekście funkcyjności, czyli ma najmniej zapożyczeń z innych paradygmatów.

Nie pamiętam czy jest 100% funkcyjny, dawno o tym czytałem, chyba nie 100% tylko najbliżej 100% (wśród popularnych języków)