Jesteś OOP?
Czy to jest oop? Czy to dalej jest oop? Czy na pewno? Może coś nie tak?
Takie pytania pojawiają się niemal codziennie na forum i niemal codziennie można dać link do jednego, wybranego tematu i zamknąć dyskusję. Tak się nie dzieje w większości przypadków, bo każdy nowy temat wydaje się być z pozoru inny. Dopiero przy drugim, może trzecim poście wychodzi szydło z worka i zazwyczaj odpowiada się jednym, może dwoma słowami; Singleton, Registry, Data Mapper, Lazy Load, Front Controller.
Każdy jednak widzi to troszkę inaczej, poprzez pryzmat własnego systemu, czy konkretnego problemu do rozwiązania. Niby dobrze, ale wprowadza to zamieszanie, bo programista nie stara się dopasować wzorca do konkretnego problemu, tylko problem do innego problemu, z którego stara sie wyciągnąć ogólną zasadę. Z tego powodu pojawiają się pytania; Jak najlepiej? Jak Wy robicie? To jest moim zdaniem złe podejście, choć przyznam, że sam takie również stosuję, niekiedy. Z tą przewagę, że już zaskoczyłem i nie rozłożę rąk w razie błędnego wyboru. Wzorce po prostu wypada znać. Przychodzi mi na myśl porównanie jedynie z pisarstwem, gdzie podziwiamy styl, lekkość pióra i śliczne konstrukcje gramatyczne. Specjalista potrafi je nazwać i w czasie dyskusji z drugim specjalistą, który nie zna książki, może się tymi nazwami posłużyć i mieć niemal pewność, że zostanie dobrze zrozumiany. Jeśli zachodzi taka ścisła zależnośc pomiędzy znajomością teorii, a możliwością przekucia jej w praktykę, to właściwie wszelkie dyskusje z laikami sa bezcelowe. Powinni najpierw poczytać, zrozumieć i najważniejsze - zaskoczyć. Cały OOP właśnie na owym zaskoczniu polega.
Pomyślałem, że warto napisać wyraźnie, co nie jest OOP. To dość złożone, bo jakieś elementy orientacji obiektowej są zawsze obecne. Główna rolę gra świadomość. Jeśli uważamy, że coś jest zorientowane obiektowo, to zapewne tak jest. Jeśli mamy wątpliwości, to znaczy, że jeszcze trzeba poczytać.
Uważam (pewnie nie tylko Ja), że istnieje etap pośredni. Jest to programowanie strukturalne ujęte w klasy. Na tym etapie programista zdaje sobie sprawę, że klasy to coś fajnego i nawet przeczuwa drzemiące w nich możliwości. Nie rozumie niestety kluczowego pojęcia tożsamości obiektu i roli, jaką gra jego umiejscowienie w systemie. Koduje wówczas tak, jak do tej pory - zamienia jedynie ciało pliku na ciało klasy. Powstają przeróżne potworki, a forum jest zasypane nowymi-starymi pytaniami. Ten etap przechodziłem, więc nie są mi obce konstrukcje jak poniżej.
Najzabawniejszy jednak jest etap, który następuje po zrozumieniu OOP i opanowaniu części wzorców. Ten etap to świadome łamanie zasad programowania obiektowego w projekcie. Kiedy nie ma czasu na napisanie w pełni obiektowego kodu, lub mamy do czynienia z systemami napisanymi strukturalnie i chcemy jedynie je przebudować, lekko podrasować, to możemy doprowadzić ten system do stanu, kiedy używa ładnych, spójnych interfejsów, natomiast ich implementacja jest kodem strukturalnym (choć bywa, że jest obiektowy). Czym to się różnie od pseudo OOP, przez który przechodzi początkujący? Celowością działania, świadomością czynu. Kiedy oglądamy cudze pięćset linijek kodu odpowiedzialnego za wszystko; od zapytań do bazy danych, po układanie i walidację danych, to nie mamy szansy zrobić z tego dobrego, obiektowego kodu. Musielibyśmy napisać od nowa. Możemy wtedy wyłuskać procesy zachodzące w pliku i spróbować je enkapsulować. Nie będą to obiekty do jakich jesteśmy przyzwyczajeni, ale dadzą nam poczucie komfortu psychicznego, bo lepiej jest napisać w kodzie:
niż za każdym razem powtarzać 150 linijek kodu. To, że wewnątrz będzie jakiś paskudny kod, jest nieważne - ważne, że działa, a My mamy spokój. Jak znajdziemy trochę czasu, możemy zawsze przepisać na ładniejszy :)
Doświadczony koder zawsze będzie potrafił uzasadnić umiejscowienie danego obiektu, czy procesu.
Skończę ten wywód, bo zacząłem przynudzać. Podsumuję krótko:
Jeśli dopiero zaczynasz przygodę z oop, kup dobrą książkę na temat inżynierii oprogramowania, lub jakiś podręcznik UML. Zrozum teorię, bo inaczej zostaniesz odesłany do książek. Stracisz tylko czas i nerwy.
Takie pytania pojawiają się niemal codziennie na forum i niemal codziennie można dać link do jednego, wybranego tematu i zamknąć dyskusję. Tak się nie dzieje w większości przypadków, bo każdy nowy temat wydaje się być z pozoru inny. Dopiero przy drugim, może trzecim poście wychodzi szydło z worka i zazwyczaj odpowiada się jednym, może dwoma słowami; Singleton, Registry, Data Mapper, Lazy Load, Front Controller.
Każdy jednak widzi to troszkę inaczej, poprzez pryzmat własnego systemu, czy konkretnego problemu do rozwiązania. Niby dobrze, ale wprowadza to zamieszanie, bo programista nie stara się dopasować wzorca do konkretnego problemu, tylko problem do innego problemu, z którego stara sie wyciągnąć ogólną zasadę. Z tego powodu pojawiają się pytania; Jak najlepiej? Jak Wy robicie? To jest moim zdaniem złe podejście, choć przyznam, że sam takie również stosuję, niekiedy. Z tą przewagę, że już zaskoczyłem i nie rozłożę rąk w razie błędnego wyboru. Wzorce po prostu wypada znać. Przychodzi mi na myśl porównanie jedynie z pisarstwem, gdzie podziwiamy styl, lekkość pióra i śliczne konstrukcje gramatyczne. Specjalista potrafi je nazwać i w czasie dyskusji z drugim specjalistą, który nie zna książki, może się tymi nazwami posłużyć i mieć niemal pewność, że zostanie dobrze zrozumiany. Jeśli zachodzi taka ścisła zależnośc pomiędzy znajomością teorii, a możliwością przekucia jej w praktykę, to właściwie wszelkie dyskusje z laikami sa bezcelowe. Powinni najpierw poczytać, zrozumieć i najważniejsze - zaskoczyć. Cały OOP właśnie na owym zaskoczniu polega.
Pomyślałem, że warto napisać wyraźnie, co nie jest OOP. To dość złożone, bo jakieś elementy orientacji obiektowej są zawsze obecne. Główna rolę gra świadomość. Jeśli uważamy, że coś jest zorientowane obiektowo, to zapewne tak jest. Jeśli mamy wątpliwości, to znaczy, że jeszcze trzeba poczytać.
Uważam (pewnie nie tylko Ja), że istnieje etap pośredni. Jest to programowanie strukturalne ujęte w klasy. Na tym etapie programista zdaje sobie sprawę, że klasy to coś fajnego i nawet przeczuwa drzemiące w nich możliwości. Nie rozumie niestety kluczowego pojęcia tożsamości obiektu i roli, jaką gra jego umiejscowienie w systemie. Koduje wówczas tak, jak do tej pory - zamienia jedynie ciało pliku na ciało klasy. Powstają przeróżne potworki, a forum jest zasypane nowymi-starymi pytaniami. Ten etap przechodziłem, więc nie są mi obce konstrukcje jak poniżej.
123 |
<?php
|
Najzabawniejszy jednak jest etap, który następuje po zrozumieniu OOP i opanowaniu części wzorców. Ten etap to świadome łamanie zasad programowania obiektowego w projekcie. Kiedy nie ma czasu na napisanie w pełni obiektowego kodu, lub mamy do czynienia z systemami napisanymi strukturalnie i chcemy jedynie je przebudować, lekko podrasować, to możemy doprowadzić ten system do stanu, kiedy używa ładnych, spójnych interfejsów, natomiast ich implementacja jest kodem strukturalnym (choć bywa, że jest obiektowy). Czym to się różnie od pseudo OOP, przez który przechodzi początkujący? Celowością działania, świadomością czynu. Kiedy oglądamy cudze pięćset linijek kodu odpowiedzialnego za wszystko; od zapytań do bazy danych, po układanie i walidację danych, to nie mamy szansy zrobić z tego dobrego, obiektowego kodu. Musielibyśmy napisać od nowa. Możemy wtedy wyłuskać procesy zachodzące w pliku i spróbować je enkapsulować. Nie będą to obiekty do jakich jesteśmy przyzwyczajeni, ale dadzą nam poczucie komfortu psychicznego, bo lepiej jest napisać w kodzie:
123 |
<?php
|
niż za każdym razem powtarzać 150 linijek kodu. To, że wewnątrz będzie jakiś paskudny kod, jest nieważne - ważne, że działa, a My mamy spokój. Jak znajdziemy trochę czasu, możemy zawsze przepisać na ładniejszy :)
Doświadczony koder zawsze będzie potrafił uzasadnić umiejscowienie danego obiektu, czy procesu.
Skończę ten wywód, bo zacząłem przynudzać. Podsumuję krótko:
Jeśli dopiero zaczynasz przygodę z oop, kup dobrą książkę na temat inżynierii oprogramowania, lub jakiś podręcznik UML. Zrozum teorię, bo inaczej zostaniesz odesłany do książek. Stracisz tylko czas i nerwy.
Co do podręcznika UML i książek - myślę, że jest pewna pułapka. Inżynieria oprogramowania to jednak w większości praktyka. Interesującą drogą jest własny projekt, na tyle duży, żeby te problemy wyszły. Przeprowadzenie go przez wszystkie fazy, w tym stabilizacja, utrzymanie (maintenance), itd. - wtedy dużo lepiej się zrozumie pewne zależności, niż na suchych i uproszczonych przykładach z książki (która jednak ma tę zaletę, że jest dobrym startem).
Pamiętaj jednak że inżynieria Oprogramowania jako nauka nie zajmuje się projektowaniem systemów informacyjnych. Projektowanie to zupełnie inna dziedzina nauki która jest w pełni steoretyzowana Inżynieria zastanawia się jak efektywnie wykonywać postulaty projektantów - nie kwestionuje ich zasadności.