Wpis z mikrobloga

[ #csharp #dotnet #programowanie #dotnetnews #maavfeed ]

#designpatterns
Follow-up do poprzedniego artykułu odnośnie Repository. Nie lubię repository, ale to rozwiązanie podoba mi się jeszcze mniej.
Piotr Gankiewicz - Extension methods to the rescue (from repository)
Jeremy Miller - An Example of the Open/Closed Principle in Action
Dyskusja pod spodem jest ciekawsza od samego artykułu.
Peter Vogel - The Special Case Pattern

#csharp
Peter Vogel - Share Information Among Asynchronous Processes Sans Locks

#aspnet
Henrik F Nielsen - Announcing ASP.NET WebHooks Release Candidate 1
Matthew Jones - Custom Validation in ASP.NET Web API with FluentValidation

#performance
Matt Warren - Adventures in Benchmarking - Method Inlining
Miha Markic - Use async keyword only when required
  • 10
@andrzej-kopara:

Nie chcę mi się zbytnio rozwodzić, więc skopiowałem z internetu.

Extension methods concept is just syntactic sugar as some authors call it. It makes the code more readable though less understandable. Ultimately extension methods are just static ones which are the heritage of the procedural paradigm. They make the code tightly-coupled and less cohesive, harder to test and reuse.

Cytowany tekst...I am biased against this tendency of the C# programming
A extention method np. Dla wbudonych klas tj. Np ogólnej uielements badz dependenyObject. Powiedzmy ze do zmiany rozmiaru przyciskow i grida bez odpalenia eventu sizeChanged? Chyba jednak sa sytuacje w których Extenion methods mogą uprościć kod, a nie służyć tylko jako ciekawostka komplikujca program. Tak, jeśli byśmy napsali wlasna klasę dziedziczącą po danym typie, np TextBox to głupota jest użycie metod rozszerzających klasę TextBox. No ale dla pierwszego przykładu, czy jest sens