Don’t forget that if you want to get my upcoming video courses with 50% discount, then fill the following form.
C# provides many ways to compare objects, not only to compare class instances, but also structures. Actually, there are so many ways, that it requires to put them in order. All those possible options of comparing confuse people in case of misunderstanding them and their possible implementations.
This is a brief introduction into .NET cryptography.
Hashing is a transformation process of some input data of an arbitrary length into an array of bytes of fixed size.
Hash is a one-side transformation function, the result of which cannot be reversed for receiving original input data. Very often it is used to store passwords. Even if an attacker gets a hash, he can’t retrieve the password from it. The length of a hash is determined by a hashing algorithm. In .NET you can find the following hashing algorithms (all of which derive from the HashAlgorithm base class):
- MD5 — 128 bits in length
- SHA (Secure Hash Algorithm) — there is no such a class, but there are SHA1 (160 bits), SHA256, SHA384, SHA512
- KeydHashAlgorithm (also known as Message Authentication Code). Represented by the following classes of algorithms: HMAC and MACTripleDES
Primitive Types Obsession Problem
Today I’m going to discuss the problem of using primitive types instead of abstractions. This problem was discussed in the blog of Mark Seemann. Read it, if you haven’t read it yet.
In this post I’m going to talk about Money type as an abstraction instead of using decimal type for representing money-values.
In the last project I’ve been participating in, we relied on a decimal and integer types for a long time. From the beginning, we knew that using primitive types for values of that kind is an anti-pattern, but we stubbornly have been using them. In the US there are cents and dollars. In the Russian Federation – rubles and kopeks. 1 ruble = 100 kopeks. Our system inter-operated with an external system which performed all its calculations in kopeks. So it required kopeks as the input and returned kopeks as the output. If we wanted to pass in 2rubles and 50kopeks, then we passed in Int32 amount = 250;
Are you sure know the difference between the following events?
These days I’m working on a video course about Microsoft WPF foundations. And today I want to address some basic notions that every UI-developer should be aware of and be able to explain them. That will become an entry point for my WPF tutorial. The notions I’m talking about are the following:
- DPI (dots per inch), PPI (pixels per inch). What’s the difference?
- Raster Graphics and Vector Graphics
- Independent Pixel
- Aspect Ratio
- ClearType rendering
That’s a well known question. Actually, I knew the difference between methods and properties long ago. Despite of that, recently I stumbled upon my own incorrect choice between those semantic constructions. That’s why I decided to write this post – in order to solidify the understanding of the difference between property and method.
Method vs Property fail in BCL
The most notorious fail of creating a property inside the BCL (FCL) in .NET instead of a method is the DateTime.Now property. In my opinion, this particular case is not the worst in history, though it’s an embarrassing one. So, what’s wrong with that the DateTime.Now is implemented as a property rather than a method? This isn’t wrong from the point of the actual implementation, it is implemented correctly, the point is that this is semantically wrong from the API design perspective. If every time the getter of a property returns different values, then this is a method, not a property. Why? Because a property is an attribute of an entity. For example, Year is an attribute of a Date, so it would be correct to get the year as it follows: DateTime.Now().Year. Yes, that’s it, that’s how it should look like, not like a chain wreck – DateTime.Now.Year. By the way, similar by the case Guid.NewGuid() member is implemented as a method. In this case, the word “New” dictates that this should be a method, but for example they could have named it Guid.Next and even in this case it should be a method, as well as the DateTime.Now!
Sometimes we think that a certain thing is simple, but in the end it appears it’s not as simple as we have thought. I mean, BinarySearch is pretty simple, right? Every meaningful programmer can implement a binary search algorithm. Everyone knows that InsertionSort sucks and QuickSort shines, yep?
Today asynchronous programming is everywhere. It’s hard to find software which doesn’t perform asynchronous operations. Many async operations can take a long time to finish. Sometimes they can last infinitely. This situation dictates the necessity to have a possibility to cancel operations. And this is the topic we are going to talk about: cancelling operations.
When I was a newcomer I faced with a chunk of long-running code that didn’t support cancellation. I needed to cancel it somehow. Unfortunately, I had no access to that code, so I couldn’t modify it. I was struggling with the requirement to be able to cancel that code. I was thinking about the problem for two days as I remember and I couldn’t believe that it’s actually not possible to cancel random code. Yes, there is the Thread.Abort method presented since .NET 1, but it’s strongly not recommended to use it, because we can’t predict what will happen to the code which is going to be aborted. It’s even almost (or absolutely) impossible to write code which is reliable in case it is aborted by Thread.Abort, because it’s even not guaranteed that your finally-blocks will be executed. One will say that I’m talking about self-evident things, but I’ve heard many times from developers exclamations like, “why we can’t simply use Thread.Abort in order to interrupt that function?” That’s why I decided to write this post, showing how simple it is to write cancellable code.
Mark Seemann has written a nice post “Service Locator violates encapsulation”. The name of the post speaks for itself that it’s about a pattern (anti-pattern) named Service Locator. When a programmer arbitrarily inside the code base calls for the IoC-container to resolve a dependency of an object – he uses a Service Locator anti-pattern. Mark provides the following example:
public class OrderProcessor : IOrderProcessor
public void Process(Order order)
var validator = Locator.Resolve<IOrderValidator>();
var shipper = Locator.Resolve<IOrderShipper>();
The previous blog post received many comments, and this approves that the problem of handling errors\exceptions is palpitating. I thought I’m going to address practical points of errors\exceptions handling in the second part. But I feel I need to address comments of readers firstly.