mam pytania odnoście tych 2 rodzajów programowania w PHP

programowanie obiektowe jeśli chodzi o serwisy ww gdzie znajdzie zastosowanie ?
większość CMSów jest pisane metodą strukturalną ?
w jakich przypadkach lepiej używać jednego lub drugiego ?

//większość CMSów jest pisane metodą strukturalną ?
to czy cms będzie pisany oop zależy od tego kto go pisze
lepiej oop

przy mega małych stronkach można się ograniczyć do strukturalnego programowania, przy reszcie lepiej oop

Duże aplikacje tylko w OOP. Łatwiej można kod zrozumieć po wielu miesiącach od napisania, łatwiej go udokumentować, no i jest krótszy.



Jeśli piszesz coś bardzo małego, to tak jak Spawnm napisał możesz pisać proceduralnie. Odpada wtedy problem rozumienia kodu, bo jest go mało. Ale jeśli piszesz coś dużego - np. chciałbyś sobie stworzyć jakis odpowiednik wp.pl, to tylko obiektowo.

ale istniejące darmowe typu jommola php-fusion itd. chyba są strukturalne

nie wiem jak z komercyjnymi np. edito

etid// czyli pisząc CMS pokroju php-fusion dużo lepiej będzie użyć oop
trza się będzie podszkolić ;] do strukturalny w porównaniu z tymi całymi classami to pikus

z całym szacunkiem, ale bzdury piszecie. co jest krótsze? kod? no chyba kpisz. że niby na jakiej podstawie OOP Ci kod skraca? OOP to nie tylko czytelniejszy kod, czego koledzy widzę nie wiedzą. OOP to przede wszystkim cały wachlarz możliwości (który w wypadku php jest ciągle skromny ale wersja 6 a nawet 5.3 wnoszą już sporo ku lepszemu). OOP to przeciążanie, metody magiczne, konstruktory, destruktory, dziedziczenie, ograniczanie widoczności i wiele wiele więcej. polecam lekturę manuala. OOP pozwala na hermetyzację danych - do których obróbki używany jest tylko konkretny zestaw funkcji (metod), mamy wtedy gwarancję że jakiś zewnętrzny kod nam nic nie napsuje itp. co by jednak nie mówić to użycie oop powinno wynikać ze specyfiki konkretnego zadania które należy wykonać. Nie należy pchać go wszędzie na siłę. Kiedy najlepiej używać? nie powiem Ci, bo nie ma złotego środka, jeśli opanujesz oop a wcześniej programowanie strukturalne to sam będziesz potrafił wyczuć kiedy lepiej jest zastosować którą z tych metod.

dlatego napisałem
z czego chyba jasno wynika że użycie oop lub nie powinno być każdorazowo przemyślane. Nie zmienia to faktu że nawet serwis z jedną podstroną można zbudować przy użyciu oop.

OOP to inny sposób myślenia, programy napisane obiektowo, mają mniej błędów i łatwiej je potem ewentualnie poprawić, lecz niestety nie jest to proste, wymaga wiele lat praktyki. Bez względu na to co piszesz dobrze się nastawić na obiektowość, czy jest to mała funkcja i wielki projekt, obiektowość ma te zaletę nad strukturalnym programowaniem, że jak coś raz napiszesz dobrze to możesz to wciągać w inne projekty, strukturalne niestety nie zawsze się tak da, nie jednokrotnie, wciągnięcie fragmentu kodu powoduje pociągnięcie za sobą połowy projektu.
w programowaniu strukturalnym skupiasz się krok po kroku, jak się będzie projekt zachowywał, w OOP tworzysz klasy, które mają sciśle określone zadania, i tworząc taką klase, głównie temu poświęcasz cały czas.

Polecam OOP

prawda, ale tylko po części, pamiętaj o tym że są też funkcje które tak samo dobrze napisane mogą zostać wyciągnięte i użyte gdzie indziej, analogicznie można skopać od góry do doły klasę jeśli jej kod będzie się odwoływał do innych klas z projektu - dzieje się dokładnie to samo - wyciągnięcie jej powoduje wyciągnięcie połowy projektu. nie ma sensu pchać oop do takich zastosowań jak "hello world" i podobnie banalne czynności - chyba że stoją za tym jakiej inne konkretne pobudki.

Obie techniki programowania mają swoje zastosowania. Można je ze sobą łączyć. Skrypty od podstaw szybciej pisze się strukturalnie, chociaż stworzenie klas np. do obsługi szablonów ułatwia wiele zadań.

Strukturalne: większa wydajność, mniejszy rozmiar plików, prostota, ale niektóre fragmenty kodu trzeba powtarzać
Obiektowe: łatwiej przenieść fragmenty kodu, funkcje magiczne, więcej możliwości, protekcja metod i zmiennych

Jeżeli mówimy o przenośności kodu OOP, nie można odwoływać się do zmiennych globalnych ani funkcji spoza klasy, których w innych projektach może nie być lub mogą nazywać się inaczej. Eliminuje się problem "global".

Aby modyfikować inny - często rozbudowany - projekt w OOP, trzeba najpierw go dobrze poznać.

to się raczej wyklucza zresztą od tego są funkcje żeby się nie powtarzać

też bzdura - w nowych wersjach php które starają się być jak najbardziej obiektowe postawiono duży nacisk na wydajność obiektów i wszystkiego co z nimi związane. Wyniki działania kodu strukturalnego i obiektowego w php są na tyle porównywalne że nie może być mowy o większej wydajności jednego czy drugiego w wypadku gdy kod jest napisany dobrze

jednak przy projektowaniu małego CMS'a zostanę przy strukturalnym większość rzeczy powtarzających się pisze w funkcjach więc łatwo jest je później wyciągnąć. teraz myślę że oop ma chyba największe zastosowanie w grach przegladarkowych gdzie np. tworzymy pole bitwy czy losowe warunki pogodowe ;]

Jeśli się zastanawiasz to znaczy, że nie umiesz pisać obiektowo Nie ma nad czym gdybać. Tylko OOP, oczywiście pomijam tu jakieś "statyczne" wizytówki itd. Napisałem ostatnio artykuł na konkurs gdzie wyjaśniam (staram się wyjaśnić) jakie są korzyści z OOP. Na wortalu znajdziesz zresztą masę innych artykułów zgłębiających temat. Ja jednak (bo jestem bardzo nieskromny) podam Ci linka do swojego artykułu. Oto i on

Pozdrawiam!

I tak front kontroler nie może być w pełni obiektowy. Można nawet Hello World! napisać obiektowo, używając N klas i tworząc dla każdej M obiektów. Kod: http://pastebin.pl/7578 - prawda, że jest pro? Tylko po co, jeśli można napisać:

[PHP] pobierz, plaintext 
<?php
echo 'Hello World!';
?>
[PHP] pobierz, plaintext 

Oczywiście większe lub zaawansowane projekty lepiej napisać obiektowo, szczególnie frameworki, na których tworzy się serwisy internetowe. Nie przesadzajmy jednak z OOP w każdym skrypcie.

Jest jeszcze jedna zaleta programowania strukturalnego - jeżeli w kilku miejscach odczytujemy listę artykułów, fragment kodu można dostosować do potrzeb. Zwolennicy OOP zaraz napiszą o dziedziczeniu. W wortalu PHP.PL kiedyś trafiłem na artykuł napisany przez Zend. Zarówno zwolennicy S i OOP zyskali uznanie.

Używając OOP bez wątpienia łatwiej tworzy się programy - szczególnie okienkowe, a także skrypty JavaScript.

Zamiast pisać kilka razy $query->bindValue() można wrzucić tablicę z parametrami: $query->execute($tablica). Kiedy to się przydaje? Na przykład wtedy, gdy po wysłaniu formularza wystąpią błędy - wtedy bez problemu wyświetlimy formularz z wysłanymi danymi, bo wcześniej przygotujemy sobie taką tablicę z nazwami pól i wartościami z POST - oczywiście zabezpieczonymi przed HTML, nieprawidłowymi wartościami, itd.

Wybacz ale hahahahahahahaha
Wyjrzyj poza świat PeHaPe: FrontController

I będą mieli rację. Co masz na myśli, że pisząc strukturalnie można dopasować kod do potrzeb? To pisząc zgodnie z OOP już nie można?
Oczywiście, że można. I to prościej i elastyczniej.

ayeo artykuł się na pewno przyda ale narazie zostanę przy zwykłym programowani ucząc się opp
z drugiej strony uczenie się oop PHP jest dobre bo później szybciej można przejść do JS, AJAX, AS3 bo już się zna jego strukture

można by go też napisać w assemblerze - ale pytanie "po co?" skoro można łatwiej i przyjemniej. Różne metody programowania nie powstały po to żeby utrudniać życie stawiając nas każdorazowo przed trudnym wyborem "czego użyć" tylko po to żeby dać odpowiednio szeroki wachlarz możliwości z którego będziemy mogli wybrać rozwiązanie optymalne w danej sytuacji. Na tym między innymi polega programowanie - na umiejętności dobrania odpowiedniej metody do zadanego problemu, a nie tylko na klepaniu pętli i warunków w jeden określony schematyczny sposób, całkowicie bezmyślnie tworząc nieefektywny i ciężki w późniejszym rozwijaniu kod.

Nauczenie się dowolnego języka prog. ułatwia poznanie kolejnego.
Nauczenie się dowolnego algorytmu umożliwia wykonanie go w dowolnym języku
Nauczenie się dowolnej "idei" pozwala na stosowanie jej niezależnie od języka

btw: AJAX to JS - zapamiętajcie to w końcu...

Ogólnie to jest tak, że programowanie strukturalne (proceduralne) jest nieco szybsze niż OOP Dlatego np PhpMyAdmin jest napisany strukturalnie (tzn gdzies tak czytałem, nie sprawdzałem). Ja np. jestem za łączeniem tego, w sumie to może troszkę się kłócić z ogólnymi zasadami OOP, ale wychodzi jak narazie fajnie, zobaczymy jak to będzie w PHP 6

To wytłumacz mi co robi w moim htdocs ściągnięty już dawno temu PHPMyAdmin napisany w pełni obiektowo?

pewnie pisali go jacyś amatorzy nie mający pojęcia o temacie

Ściągnąłem najnowszą wersję phpMyAdmin i nie widzę, by był napisany w pełni obiektowo. Kod HTML przeplata kod PHP, wciąż dużo odwołań do zmiennych globalnych... Może obiektowy phpMyAdmin to tylko przeróbka third-party?

faktem jest iż nie jest w pełni obiektowy jak sugeruje pyro jednak mimo to spora część kodu - szczególnie ta odpowiedzialna za operacje na bazie została przepisana na obiekty. phpmyadmin nie jest małym projektem i trzeba naprawdę dużo pracy żeby doprowadzić wszystko do sensownego stanu pozbywając się jednocześnie nawarstwionych przez wszystkie lata nieładnych rozwiązań. Wszystko jednak wskazuje na to że idzie ku lepszemu. Jeśli nie wierzysz na słowo że użyto tam OOP to proponuję poszukać plików ze słowem kluczowym class w nazwie - jest ich sporo, a to nie jedyne pliki które mają w sobie coś z obiektówki

Możliwe... nie oglądałem całego kodu źródłowego phpmyadmina, poprostu tam gdzie zajrzałem, tam była obiektówka

tak wiem chodziło mi o to że to jest coś jeszcze niż sam JS bo jak by to był JS to by się nie nazywał AJAX ;p

A JS'owy DOM (getElementById(), createElement() itp.) to JS czy może DOM?

AJAX jest technologią (jeśli można to tak nazwać) a nie językiem, podobnie DOM

No właśnie IMO AJAXa nie można nazwać technologią.
No chyba, że (przykład z PHP będzie dobrze obrazowywał to) przyjmujemy, że mamy dwie technologie: PHP oraz curl - wg mnie bezsens.

za wiki

co do curl to jest to biblioteka - dostępna nie tylko z poziomu php, więc tak, mamy dwie technologie PHP i cURL. Piękny strzał w stopę Crozin

Wiki nie cytuj bo nie zawsze jest to dobre źródło. Zresztą tutaj "technologia" odnosi się bardziej do zastosowania, a nie samego JStu.

Fakt, z cURLem to zły przykład dałem - lepiej jakbym napisał o bibliotece GD.

gd także jest biblioteką wykorzystywaną poza PHP choćby w perlu czy C. Kolejny strzał w stopę to już druga, co będzie następne?
Wiki fakt że nie zawsze jest dobrym źródłem - jednak jest najszybszym (najłatwiej dostępnym). I mam nadzieję dotrze do Ciebie że AJAX to technologia łącząca w założeniu javascript i xml do asynchronicznej transmisji danych między przeglądarką a serwerem.

Ajax to niezupełnie JavaScript. Dzięki Ajaxowi możemy wysyłać dane do skryptu php i odbierać ze skryptu php.

@nieraczek: Przy pomocy AJAXa nie możesz wysłać/odebrać danych ze skryptu PHP. Możesz jedynie wykonać żądanie i odebrać jego wyniki. A to czy wyniki generowane są przy pomocy PHP czy dowolnego innego języka server-side oraz jakie są tego "uboczne" efekty to już inna bajka.

@devnul: z curlem to się zapędziłem, ale z gd (przyznam bez bicia) nie wiedziałem, że jest to biblioteka używana w innych językach.
To do czego AJAX służy wiem doskonale.
Wszysto zaczęło się od tego, że kilka postów wcześniej potraktowano AJAX jakby był zupełnie oderwany od JS.

Jeżeli "technologią" nazwiemy DOM w obrębie JS (document.createElement(), document.whatever() itp.) to można przyjąc, że AJAX jest technologią. Ale jak dla kogoś document.getElementById() to JS, a new XMLHttpRequest(); to AJAX, nie JS to z tym już się nie zgodzę i o to się właśnie czepiam.

Lekki OffTop się nam zrobił.

Rozważmy 5 aplikacji:

1. Pełna zgodność z MVC. Wszystkie moduły, kontrolery, narzędzia są obiektami.
2. Napisana strukturalnie bez żadnych klas. Ma funkcje do popularnych zadań, np. BBCode, stronicowania...
3. Tak jak wyżej, lecz warstwa prezentacji (kod HTML) jest oddzielona. Może istnieć klasa szablonów.
4. Napisana strukturalnie, ale stosuje klasy do szablonów, bazy danych, e-mail, PW, zapisu konfiguracji...
5. Moduły są klasami, warstwa prezentacji oddzielona, ale większość kodu napisana strukturalnie.

Które z nich można nazwać obiektowymi?

Rozważmy wyświetlanie komentarzy w pełni obiektowej aplikacji. Komentować mogą zarówno zalogowani i goście. Jak poprawnie wyświetlić przy każdym komentarzu informacje o użytkowniku, który go napisał?

1. Użyć JOIN, aby pobrać loginy i inne cenne informacje z bazy danych, a potem tylko wsadzić je do szablonu? Wtedy powiecie, że część kodu powtarza się, a przy zmianie struktury tabeli użytkowników lub funkcjonalności trzeba dokonać zmiany we wszystkich plikach, gdzie się te dane odczytuje.

2. Dla każdego komentarza stworzyć osobny obiekt $user = new User(...); który już zajmie się wyciągnięciem i przygotowaniem odpowiednich informacji. Tylko ile zapytań trzeba wykonać do bazy danych? Może przez referencje lub inne cuda da się ich ilość zminimalizować. Gdy jest dużo komentarzy, dodatkowy narzut czasowy może być widoczny - wreszcie tworzenie nowego obiektu kosztuje.

3. Użyć JOIN, tworzyć za każdym razem nowy obiekt klasy User i powstawiać do niego wyciągnięte dane z bazy.

zmień dealera albo bierz połowę. Zielonego pojęcia nie mam co próbowałeś udowodnić ale jedno wiem na pewno. Ani trochę Ci to nie wyszło

Bełkot.