dotnetomaniak.pl - Artykuły z tagiem zasady programowania

Kto z nas nie słyszał o regule DRY? Zastanawialiście się jednak, czy złote zasady w programowaniu są wieczne? Co jeśli reguła DRY nie jest już aktualna?

Źródło: kalkus.dev
Dziel się z innymi:
DRY is dead | O programowaniu

Sztuka programowania 1909 dni, 7 godzin, 53 minuty temu landeeyo 307 źrodło rozwiń

W poprzednim wpisie przedstawiłem różnice pomiędzy logiką aplikacji, a logiką biznesową. Taki podział doskonale ilustruje zasadę podziału odpowiedzialności, tzw. Separation of Concerns, w skrócie SoC. Cofnijmy się do wspomnianego artykułu na moment i przypomnijmy sobie główne różnice pomiędzy logiką aplikacji, a logiką biznesową...

Blog piwno-programistyczny: Podział odpowiedzialności - SoC

Sztuka programowania 3458 dni, 19 godzin, 3 minuty temu markone 354 źrodło rozwiń

Zastanawiacie się co to takiego ten tunel kodu? Otóż chodzi tutaj o specyficzny stan świadomości, z dużym skupieniem i widzeniem tunelowym, w który mogą wejść programiści tworzący kod. Można o nim przeczytać np. w książce autorstwa Roberta C. Martina "Mistrz czystego kodu. Kodeks postępowania profesjonalnych programistów", choć tam nosi on nazwę strefy lub przepływu (flow). Zgodnie z opisem we wspomnianej książce, stan ów charakteryzuje się tym, że znajdujący się w nim programiści czują się ...

Me z .NET tete-a-tete » Tunelem kodu pędzę do przodu

Sztuka programowania 3817 dni, 21 godzin, 36 minut temu PaSkol 308 źrodło rozwiń

W poprzedniej części dokonałem kolejnego odwrócenia – tym razem zależności. W tej – choć będzie o wstrzykiwaniu – odwracać się do tego zabiegu nie będzie trzeba ;). Wręcz przeciwnie (by nie rzec odwrotnie) to wstrzykiwanie pomoże w odwracaniu i to zarówno zależności jak i sterowania (kontroli). Jeśli więc chcecie dowiedzieć się jak to możliwe – nie ma odwrotu, należy przeczytać niniejszy wpis :D ...

Me z .NET tete-a-tete » Odwracanie, wstrzykiwanie – pora rzucić okiem na nie. Część 3

Sztuka programowania 3845 dni, 2 godziny, 3 minuty temu PaSkol 180 źrodło rozwiń

Poprzednio odwracałem sterowanie (lub kontrolę, jak kto woli). Dzisiaj pora odwrócić zależność. Zasada odwracania zależności (Dependency Inversion Principle) to ostatnia (licząc wg porządku liter w nazwie) z zestawu zasad SOLID. O co więc chodzi z tą zależnością i na czym tak naprawdę polega jej odwracanie? Najlepiej będzie zademonstrować to na przykładzie. Oglądaliście "Seksmisję" (to już 30 lat od jej premiery)? Był w niej...

Me z .NET tete-a-tete » Odwracanie, wstrzykiwanie – pora rzucić okiem na nie. Część 2

Sztuka programowania 3851 dni, 5 godzin, 48 minut temu PaSkol 208 źrodło rozwiń

Trafiłem ostatnio na tekst o nadużywaniu var. Przede wszystkim zafrapowało mnie użycie pojęcia „nadużywanie„, bo sugerowało, że podczas tworzenia kodu należałoby (oprócz wielu reguł) brać jeszcze pod uwagę czy danej konstrukcji nie używa się zbyt często (czyli nadużywa). Tylko jakie w takim razie powinno być kryterium umożliwiające stwierdzenie, czy coś jest nadużyciem, czy nie? Czy jeśli ...

Me z .NET tete-a-tete » Oto moja perspektywa: „var” się nie da nadużywać

Sztuka programowania 3860 dni, 17 godzin, 13 minut temu PaSkol 345 źrodło rozwiń

W kwietniu na jednym z blogów poruszany był temat odwracania (inwersji) w kontekście tworzenia oprogramowania. Dotyczyło to takich zagadnień (pozwolę sobie na wstępie użyć ich angielskich nazw) jak Inversion of Control (w skrócie IoC) oraz Dependency Inversion Principle (DIP). Przy okazji tego drugiego odniesiono się też do Dependency Injection (DI), które ...

Źródło: paskol.robi.to
Dziel się z innymi:
Me z .NET tete-a-tete » Odwracanie, wstrzykiwanie – pora rzucić okiem na nie. Część 1

Sztuka programowania 3865 dni, 16 godzin, 9 minut temu PaSkol 269 źrodło rozwiń

Zgodnie z obietnicą wypada przedstawić drugi z rezultatów inspiracji wynikłej ze swoistego dialogu (diaBlogu ;) ) pomiędzy Krzysztofem Morcinkiem a mną. Tym razem skupię się na następującym fragmencie jego wpisu ...

Me z .NET tete-a-tete » Bacz, bo w gąszczu uogólnień – skryty – rwie uproszczeń strumień.

Sztuka programowania 3997 dni, 5 godzin, 49 minut temu PaSkol 166 źrodło rozwiń

Swojego czasu zachwalałem wytrawność kodu i zapraszałem do jego degustacji. Pocieszające jest, że nikt z tego powodu nie był zdegustowany, a wręcz przeciwnie – niektórych zainspirowałem. Nie ukrywam, że lubię być inspiracją, a już uwielbiam, kiedy wynikiem tejże inspiracji jest z kolei zainspirowanie mnie. Nic tak bowiem nie pomaga poszerzaniu wiedzy, jak wymiana poglądów. W przypadku, który mam zamiar omówić, moja inspiracja jest podwójna. Na razie jednak skupię się na jednym jej aspekcie. Krzysztof Mor...

Źródło: paskol.robi.to
Dziel się z innymi:
Me z .NET tete-a-tete » Siekierka służy na wyrębach. Nie służy do dłubania w zębach.

Sztuka programowania 3999 dni, 1 godzinę, 37 minut temu PaSkol 239 źrodło rozwiń

Zapewne każdy profesjonalny programista zna zasadę DRY, której nazwa jest zarazem skrótem jej treści Don’t Repeat Yourself czyli zalecenia Nie Powtarzaj Się. Najczęściej stosuje się ją, by przeciwdziałać powielaniu kodu wykonującemu tę samą czynność (czy to przez jego niepotrzebne, ponowne napisanie czy też przez zwykłe przeklejanie). To co ciekawego w tej regule, to fakt, że w swej treści skierowana jest ona do ...

Me z .NET tete-a-tete » Refaktoryzator wprawny zmienia kodu smak … w wytrawny.

Sztuka programowania 4061 dni, 23 godziny, 56 minut temu PaSkol 210 źrodło rozwiń

Kiedy wprowadza się reguły? Zazwyczaj wówczas, kiedy zjawiska zachodzące w danym środowisku zaczynają wymykać się spod kontroli. Weźmy np. pojazd komunikacji miejskiej. Jeżeli jest on praktycznie pusty, to można z niego wysiadać w tym samym momencie, w którym ktoś chce wsiąść – ta garstka pasażerów wyminie się w drzwiach w sposób intuicyjny. Jeśli jednak liczba wysiadających jak i wsiadających zwiększy się, to konieczna będzie już jakaś regulacja – np. ...

Me z .NET tete-a-tete » Ma reguła konsekwencje, więc pytam: dlaczego dopatrywać się w nich czegoś niepożądanego?

Architektura 4209 dni, 23 godziny, 26 minut temu PaSkol 105 źrodło rozwiń

Reguły, zasady – przemyślenia na ich temat ostatnio opanowały mój umysł, więc naturalną konsekwencją jego stanu są kolejne moje wpisy. I czuję, że to jeszcze nie koniec. Na blogu ostatnio jest bardziej filozoficznie, ale tak bywa, kiedy dokonuje się retrospekcji. Dziś co nieco o regule nazywania warunków (wywodzącej się z reguły wydzielania metody). Chodzi w niej o to, aby wyrażenia logiczne występujące w kodzie...

Źródło: paskol.robi.to
Dziel się z innymi:
Me z .NET tete-a-tete » To wciąż zasada, czy już przesada?

Sztuka programowania 4215 dni, 20 godzin, 36 minut temu PaSkol 191 źrodło rozwiń

Informatyka z racji swojego sformalizowania kocha się w regułach. Nie można się praktycznie ruszyć, by w jakąś nie wdepnąć. Zaczynam się powoli zastanawiać, czy nie mamy tutaj do czynienia ze zjawiskiem podobnym do eksplozji klas – eksplozją reguł. Bezsprzecznie do tego stanu rzeczy przyczyniają się także blogi. Widywałem na blogach wpisy, w których ...

Źródło: paskol.robi.to
Dziel się z innymi:
Me z .NET tete-a-tete » Owszem, reguły trzeba stosować, ale nie dajmy się im zwariować.

Sztuka programowania 4221 dni, 3 godziny, 9 minut temu PaSkol 219 źrodło rozwiń

Komentarze z reguły są złe, zamiast nich należy pisać czytelny kod (czyli kod, który czytany wyjaśnia swoje działanie). Są złe bo się dewaluują, tj. po jakimś czasie nie korespondują z kodem, opisują go w nieprawdziwy sposób, bo kod się zmienił. Jest to prawda, której obecnie nie trzeba chyba już nikomu tłumaczyć, przynajmniej tym, którzy trzymają rękę na programistycznym pulsie. Czy zatem rezygnując z komentarzy oraz pisząc czytelny kod pozbyliśmy się całego ich zła? Niekoniecznie, ono czeka cierpliwie...

Źródło: paskol.robi.to
Dziel się z innymi:
Me z .NET tete-a-tete » Chociaż pozbyłeś się komentarzy ich zło się w kodzie wciąż może zdarzyć.

Sztuka programowania 4222 dni, 21 godzin, 32 minuty temu PaSkol 199 źrodło rozwiń

Po odłożeniu kodu na weekend, jego przeglądzie i uwzględnieniu komentarzy, można uznać proces refaktoryzacji za zakończony. Pisząc „proces” mam tu na myśli wykonanie refaktoryzacji o ściśle określonym celu – w tym przypadku było to stworzenie mechanizmu importu, który zastąpi używany obecnie. Nie wchodziły zatem w ten proces...

Me z .NET tete-a-tete » Nadeszła pora na cykl publikacji: „Historia pewnej refaktoryzacji”. Podsumowanie.

Sztuka programowania 4304 dni, 21 godzin, 15 minut temu PaSkol 84 źrodło rozwiń

Ostatnią z czynności refaktoryzacyjnych będzie przystosowanie dotychczasowej klasy MethodObject do używania powstałych w trakcie refaktoryzacji klas. Jak można sprawdzić w części drugiej, klasa ta posiadała cztery publiczne metody: ImportCSV(), ImportTabSeparated(), ImportFixed(), ImportBinary(). Metody te były następnie wykorzystywane przez interfejs użytkownika do wykonywania odpowiednich importów. Te metody muszą zostać zachowane, zmieni się natomiast ich implementacja. Zmianie ulegnie też...

Me z .NET tete-a-tete » Nadeszła pora na cykl publikacji: „Historia pewnej refaktoryzacji”. Część 19.

Sztuka programowania 4313 dni, 7 godzin, 54 minuty temu PaSkol 35 źrodło rozwiń

W dotychczasowym procesie refaktoryzacji udało nam się stworzyć elastyczny mechanizm importu – uzyskaliśmy tym samym podstawową funkcjonalność w zadowalającej postaci. Pora zająć się pozostałymi operacjami, które są niezbędne, aby uzyskać kompletną, pierwotną funkcjonalność refaktoryzowanego kodu. Na implementację oczekują przecież: zdefiniowany na początku interfejs IFileSelector i jego pochodna IFilteredFileSelector. Konieczne jest też zaimplementowanie ...

Me z .NET tete-a-tete » Nadeszła pora na cykl publikacji: „Historia pewnej refaktoryzacji”. Część 18.

Sztuka programowania 4314 dni, 15 godzin, 29 minut temu PaSkol 43 źrodło rozwiń

Jak obiecałem – dziś uzupełnimy dotychczasowy zestaw testów o nowe testy. Co będziemy testować? Jeśli ktoś uważnie śledzi ten cykl zapewne oczekuje, że – zgodnie z wcześniejszymi zapowiedziami – przygotujemy test sprawdzający uruchamianie wszystkich metod biorących udział w przetwarzaniu pliku oraz dostosujemy stare testy sprawdzające powiadamianie o postępie przetwarzania. Tak – takie testy zostaną napisane. Ale najpierw utworzymy testy, których do tej pory nie było. Proszę zauważyć, że ...

Me z .NET tete-a-tete » Nadeszła pora na cykl publikacji: „Historia pewnej refaktoryzacji”. Część 17.

Sztuka programowania 4313 dni, 7 godzin, 54 minuty temu PaSkol 59 źrodło rozwiń

W tym wpisie zaprezentuję dwie klasy dziedziczące po FileOfValuesReader i realizujące odczyt z plików tekstowych oraz binarnych. Obie klasy będą współpracować z odpowiadającymi im klasami wyodrębniającymi wartości z odczytanej zawartości. A ponieważ dopełnią one całości mechanizmu importu, to przygotuję także odpowiednie testy, które pozwolą upewnić się, że mechanizm importu nadal działa tak samo. Jako pierwszą zaimplementuję ...

Me z .NET tete-a-tete » Nadeszła pora na cykl publikacji: „Historia pewnej refaktoryzacji”. Część 16.

Sztuka programowania 4316 dni, 8 godzin, 23 minuty temu PaSkol 37 źrodło rozwiń

Nadeszła pora, by doprowadzić do współpracy klas odczytujących pliki i klas wyodrębniających z nich dane. Aby ta współpraca była jednak w ogóle możliwa – klasa FileOfValuesReader musi zostać zmodyfikowana, albowiem musi być możliwe „wstrzyknięcie” do niej obiektu implementującego interfejs IValuesExtractor. W rezultacie konstruktor zyska jeszcze jeden, dodatkowy parametr, poprzez który będzie można przekazać odpowiedni interpreter danych. Ponieważ ów interpreter trafia od razu do klasy bazowej ...

Me z .NET tete-a-tete » Nadeszła pora na cykl publikacji: „Historia pewnej refaktoryzacji”. Część 15.

Sztuka programowania 4315 dni, 15 godzin, 27 minut temu PaSkol 45 źrodło rozwiń

1 2

Najaktywniejsi w tym miesiącu