Witam,

W jaki sposób tworzycie elastyczne, łatwo rozbudowywalne aplikacje?
Interesuje mnie w jaki sposób radzicie sobie np. z rozbudową serwisu w przypadku kiedy do np. tabelki z produktem trzeba dodać kilka pól.

Zapoznaj się z programowaniem obiektowym + wzrorce projektowe.

Na początku najlepiej zastosować jakiś prosty framework, który ma swoja budowe i strukturę plików.
Polecam CakePHP, Code Igniter, a dla bardziej zaawansowanych Zend Framework.

Pozdrawiam

Od pewnego czasu stosuje OOP, ale on przeciez nie narzuca elastycznosci kodu.
Zarowno w obiektowce jak i stukturalnym mozna sobie odpowiedno napisac kod.

Tu się nie zgodzę, a właściwie: programowanie obiektowe nie narzuca - racja - ale umożliwia pisanie elastycznego i łatwo modyfikowalnego kodu. Poczytaj o klasach abstrakcyjnych, o interfejsach. Programowanie obiektowe pozwala - m. in. głównie dzięki dziedziczeniu i nadpisywaniu metod - wielokrotnie wykorzystać raz napisany kod. Poza tym łatwiej i przyjemniej konserwować kod napisany obiektowo niż strukturalnie. Co to tematu, to jeśli chodzi o elastyczność kodu względem zmian w strukturze tabel, to zależy od wielu czynników. Ja radzę sobie z tym w ten sposób, że stosuję pewną konwencję nazewniczą kolumn, przykładowo, kolumny tabeli settings:
users_send_email_activate
users_send_email_deactivate
images_max_size
images_min_size
images_max_width
images_min_width
itd.

Następnie za pomocą preg_match wydzielam z nazw kolumn określone grupy dotyczące konkretnej funkcjonalności, np. obrazków - images, użytkowników - users itd. i na tej podstawie generuję sobie formularze do edycji/dodawania danych. Przykład może słaby, bo oczywiście dane powinny być w różnych tabelach, a baza znormalizowana, ale dzięki temu przykładowi łatwo mi było pokazać Ci, jak można w miarę porządnie uodpornić się na wszelkie zmiany w strukturze tabel w bazie bez zmieniania ani jednego znaku w kodzie. Rozwiązanie sprawdziło się i funkcjonuje w moim przypadku w całkiem sporym cmsie od ponad roku.
Pozdrawiam.

//post scriptum
Czasami zdarza się, że bardziej elastyczny jest bardzo dobrze napisany kod strukturalny, niż źle zaprojektowany i chaotyczny kod obiektowy

I o takie mechanizmy mi chodzi.

Nie mam problemu z interfejsami i klasami abstrakcyjnymi. Ale w przypadku zmiany struktury tabeli jednak trzeba kilka rzeczy zmienic. A jak zrobić żeby się nie narobić ?

Gdzieś widziałem rozwiązania OOP gdzie pola klasy podawalo w zmiennej array() - odpowiednio skonstruowane metody klasy byly w stanie poradzic sobie z ze zmienna ilością pól danej tabeli.
Tylko czy to wlasciwa droga?

Przeczytałeś mojego posta wyżej ? Właśnie napisałem że nie trzeba nic zmieniać. Przykładowo pola dla formularzy rozpoznaję tak:

users_send_email_activate_desc - textarea
users_send_email_deactivate_file - input type file
images_max_size_select - select option
itd.

Generalnie powinieneś zainteresować się rozwiązaniami active record, orm, np. Propel lub Doctrine

Podstawa to trzymanie się konwencji. W ciągu lat wypracowałem styl pisania obejmujący zarówno wizualne, jak i funkcjonalne zasady mówiące, jak realizować konkretne zadania. Jako przykład mogę podać konsekwentne stosowanie null do oznaczania, że metoda, która powinna mi zwrócić określoną wartość, nie posiadała jej. Jeśli założenie było takie, że nie można nic nie zwrócić, wtedy zamiast null idzie wyjątek. Moim zdaniem jest to punkt wyjścia do dalszych rozważań - jeśli dwa skrypty napisane są według kłócących się ze sobą konwencji, ciężko mówić o ich elastycznym połączeniu.

Druga rzecz to projekt i wiedza o tym, co chcę osiągnąć. Analizuję, w których miejscach daną funkcjonalność będzie można rozszerzać i czy powinno to być rozszerzanie statyczne, dynamiczne czy jakieś inne. Kluczowe jest zrobienie odpowiedniego modelu interakcji między elementami oraz wyobrażenie sobie, jak całość powinna działać. Oczywiście po drodze także odpowiadam na pytanie, czy przy okazji nie zarżnę też wydajnościowo kodu, bo akurat jestem jednym z tych programistów, którzy nie olewają optymalizacji, zwalając wszystko na szybsze komputery, co nie do końca jest prawdą, jak się okazuje z teorii złożoności obliczeniowej i paru prostych przekształceń matematycznych .

Dopiero na końcu dobieram narzędzia: obiektówka, klasy, interfejsy, dobór wzorców projektowych, projektowanie odpowiedniego API. To są narzędzia, a narzędzi można poprawnie użyć tylko wtedy, gdy wiemy, do czego dążymy. I jeśli wszystko zostało zrobione, jak należy, to dodanie nowych pól do tabelki ogranicza się do edycji jednego pliku .