Od miesiąca piszę system w PHP i myślę, że pora ogarnąć jakieś zasady organizacji kodu i trochę posprzątać. Niepokoi mnie to, że mam kupę funkcji, a w wielu z nich pobierane 1-3 globale na starcie. 1 to obiekt bazy danych, którym wykonuję zapytania. Inne to jakieś tablice, które już wcześniej pobrałem z bazy i nie chcę powtarzać. Chciałem zacząć używać obiektów do wszystkiego gdzie się opłaca, ale później miałem 20 obiektów i każdy przechowywał taką samą listę podstron w systemie. Bez sensu, ale nie wiedziałem jak to inaczej zrobić. Jak nie zobaczę przykładu dobrego użycia obiektowości w jakimś praktycznym systemie to sam szybko tego nie wymyślę. Przeglądałem książki o programowaniu obiektowym, ale miauczące kotki i latające koniki to za mało. Polecilibyście jakiś kod do przejrzenia, żeby się zainspirować, albo książki konkretnie o tym? Nie chcę brać pierwszego lepszego gwiazdkowanego kodu z githuba, bo czasem czytam, że nawet taki Laravel ma (albo miał) dziwności w kodzie. Chciałbym się najpierw nauczyć kodować bez frameworków.
Patrząc na Twoje problemy wydaje mi się, że jednak najlepiej będzie zacząć podążać za tutorialem jednego frameworka. I konsekwentnie się tego trzymać, budując coś większego, zaglądając w kod frameworka. "Dziwności" będziesz miał i w frameworkach i w każdym materiale jaki znajdziesz, a później we własnym kodzie, itd. Zawsze coś można zrobić lepiej.
Wybaczcie za kopanie i odświeżanie starych tematów.
Jak sobie poradziłeś? Też jestem dość początkujący, zapewne nurtują mnie podobne problemy co Ciebie. :)
Może dobrze byłoby napisać kontener usług? Masz wtedy jedno miejsce, które skupia obiekty klas usług (które coś robią, np. obsługa bazy danych). Do tego pewność, że taki obiekt tworzony jest jeden raz. Dodatkowo wykorzustać można, nawet trzeba, wstrzykiwanie zależności. Korzystamy wtedy z tego, że przekazanie obiektu do jakiejś metody (np. do konstruktora takiego kontenera) to nie przekazanie kopii obiektu, a jego referencji. Ja bym kombinował w ten sposób.
Wykorzystując taki kontener usług programowanie obiektowe nabiera mocy, tak samo jest to rozwiązane we frameworkach (np. w Symfony 2).
Jak myśli ktoś bardziej doświadczony?
Korzystamy wtedy z tego, że przekazanie obiektu do jakiejś metody (np. do konstruktora takiego kontenera) to nie przekazanie kopii obiektu, a jego referencji
Dopóki sam nie poprosisz to przecież zawsze obiekt jest przekazywany jako referencja.
Ja taki kontener wykorzystuję tylko na globalne przechowywanie paru danych (np. aktualny język), obiektu systemu szablonów i połączenia z bazą.
Może dobrze byłoby napisać kontener usług? Masz wtedy jedno miejsce, które skupia obiekty klas usług (które coś robią, np. obsługa bazy danych).
na pewno wydzielenie kodu obsługi bazy danych do osobnego modułu to dobry pomysł (separation of concerns), chociaż wydaje mi się, że samo to nie musi wcale gwarantować dobrej architektury. Co z tego, że zrobisz moduł do obsługi bazy danych jeśli będziesz tego modułu używał wszędzie, na dobrą sprawę łamiąc zasadę separation of concerns, pomimo wydzielenia kodu?
W sensie: na przykładzie MVC - jeśli będziesz miał warstwę widoku i w niej odpalał zapytania SQL to nawet przy użyciu osobnej klasy będzie to chaotyczne.
Ten fragment mnie niepokoi:
Niepokoi mnie to, że mam kupę funkcji, a w wielu z nich pobierane 1-3 globale na starcie. 1 to obiekt bazy danych, którym wykonuję zapytania.
Czemu wykonujesz zapytania w "kupie funkcji"? Nie mówię, że to źle. Możliwe, że to w pełni usprawiedliwione działanie. Ale z drugiej strony intuicja mi podpowiada, że tutaj może być coś nie halo.