![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 248 Pomógł: 55 Dołączył: 1.06.2010 Skąd: mam to wiedzieć? Ostrzeżenie: (0%) ![]() ![]() |
Mam taką propozycję, aby ktoś kompetentny (nie ja...) napisał artykuł o podstawowych różnicach między obiektowym i strukturalnym (proceduralnym, liniowym - ile jeszcze określeń?) PHP.
Dlaczego? Dwa razy czytałem książkę o OOP... Jedynie pobieżnie czytałem podrozdział o różnicach pomiędzy tymi dwoma światami. A różnice są i jeżeli np. (tak jak ja, ale dzięki odpowiedzi mike'a w tym wątku zacząłem czytać książkę po raz 3ci i...) uważasz, że programowanie obiektowe to takie w którym jedynie używasz klas, obiektów, narzędzi i przeplatasz to z liniowym php - to jesteś w błędzie. Pewien jestem, że przyda się to każdemu samoukowi. Edit: Żeby jakaś mądra głowa nie wpadła na pomysł "że jest to oczywiste" - nie nie jest to oczywiste, może zapomnieliście już te czasy, że nawyk ze struktur przenikał wasze kody od szpiku... Ale ja nie i dlatego chcę pomóc mnie podobnym, którzy "jeżdżąc dieslem - myślą że olej silnikowy jest nie potrzebny". Około 19:00 dopiszę "punkty" jakie moim zdaniem powinny znaleźć się w takim artykule, bo fakt "mądre głowy" nie do końca mogą wiedzieć o co mi chodzi. Peace Y Ten post edytował ixpack 6.05.2011, 10:17:04 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 248 Pomógł: 55 Dołączył: 1.06.2010 Skąd: mam to wiedzieć? Ostrzeżenie: (0%) ![]() ![]() |
Jak obiecałem tak piszę.
Głównie chodzi mi o wykorzystanie (nie każdy samouk czyta książki) podrozdziału "Programowanie obiektowe i proceduralne" z PHP5 Obiekty, wzorce, narzędzia. Cytat Najłatwiej powiedzieć, że główna różnica tkwi w obecności obiektów w programowaniu proceduralnym. Nie jest to jednak stwierdzenie ani odkrywcze, ani prawdziwe. W języku PHP obiekty mogą być bowiem wykorzystywane w kodzie proceduralnym. Na początku dziennym jest również definiowanie klas opartych na kodzie proceduralnym. Są jednak kluczowe różnice pomiędzy dwoma kodami. Moją propozycją jest aby w artykule porównać (tak jak w książce) dwa kody robiące "to samo" oraz wyszczególnić wspomniane różnice: Podział odpowiedzialności: dla kod porceduralny to sekwencje poleceń, które nie raz są powielane (chociażby sprawdzanie czy zmienna x jest stringiem). W kodzie obiektowym natomiast następuje próba minimalizacji tych zależności i zepchnięcie pewnego zadania na dany obiekt istniejący w systemie, przez co kod nie jest powielany. Spójność i sprzęganie: w proceduralnym kodzie nasze funkcje, klasy - nawet jeżeli są w jakiś sposób powiązane często wędrują po naszym kodzie. Często trzeba zmieniać kilka funkcji, klas, bo części kodu są od siebie tak zależne, że przy zmianie jednej funkcji musimy zmieniać kolejną... W obiektowym zaś - klasa często niejako spaja kilka metod w jednym miejscu - a jeżeli wiele metod z różnych klas robi "to samo" - to mamy już do czynienia z rozluźnieniem i należy przeanalizować kod. W kodzie obiektowym konserwacja jest zminimalizowana. Za zwyczaj zmienia się jedną klasę, metodę i dodaje kolejną klasę, która ma być odpowiedzialna za jakieś zadanie. Ortogonalność: promuje łatwość wykorzystania istniejących już komponentów (co praktycznie nie istnieje dla programowania zorientowanego proceduralnie) przez włączanie ich do nowych systemów bez konieczności ich przystosowywania w sposób spartański. Nie ma automatycznego narzędzia mierzącego spójność, sprzęganie czy ortogonalność - musimy użyć mózgu (IMG:style_emoticons/default/smile.gif) . Kolejnymi "ważnymi regułami" są: zasięg klas, polimorfizm (trudne słowo (IMG:style_emoticons/default/wink.gif) ) i hermetyzacja (kolejne trudne słowo (IMG:style_emoticons/default/smile.gif) ). Kolejnym "punktem" w artykule moim zdaniem powinien być "dekalog", według którego należy projektować i pisać nasz kod. Dekalog to za mocne słowo, ale coś w stylu dobrych rad jak np.: Cytat Zwielokrotnienie kodu: Zwielokrotnienie kodu jest jednym z cięższych grzechów programowania. Uczucie deja vu przy programowaniu procedury może sygnalizować problem projektowy. Przyjrzyj się wtedy wystąpieniom powtórzonego kodu. Być może uda się je scalić [...] we wspólnej klasie. Jak Cysiaczek napisał: "OOP to sposób myślenia o kodzie." - i to jest prawda. Ale gdzie leży ta "granica"? Ok lecę na zakupy - bo mnie kobieta goni (IMG:style_emoticons/default/wink.gif) . Ręczniki trzeba kupić :/ |
|
|
![]() ![]() |
![]() |
Aktualny czas: 8.10.2025 - 15:56 |