AForge.Net

Definitely something to play with when my brain has more oxygen (suffering from anaemia right now)

Deneme 1 2 3!

AForge.NET  is a C# framework designed for developers and researchers in the fields of Computer Vision and Artificial Intelligence – image processing, neural networks, genetic algorithms, machine learning, robotics, etc.

  • AForge.Imaging – library with image processing routines and filters;
  • AForge.Vision – computer vision library;
  • AForge.Neuro – neural networks computation library;
  • AForge.Genetic – evolution programming library;
  • AForge.Fuzzy – fuzzy computations library;
  • AForge.MachineLearning – machine learning library;
  • AForge.Robotics – library providing support of some robotics kits;
  • AForge.Video – set of libraries for video processing
  • etc.

are mainly topic in this framework. İf you want more information and help  visit: https://code.google.com/p/aforge/

View original post

Object Oriented, Test Driven Design in C# and Java: A Practical Example Part #1

Download the code in C#

For a brief overview, please refer to this post.

At this point, many tutorials start by launching into a “Hello, World” style tutorial, with very little practical basis.

HelloWorld

This isn’t the most exciting concept, so let’s try a more practical example. Instead of churning out boring pleasantries, our application is going to do something a bit more interesting…build robots.

Robot

Specifically, our application is going to build awesome robots with big guns.

Ok, let’s get started with a narrative description of what we’re going to do.

“Mechs with Big Guns” is a factory that produces large, robotic vehicles designed to shoot other large, robotic vehicles. Robots are composed of several robotic parts, delivered by suppliers. Parts are loaded into a delivery bay, and are transported by worker drones to various rooms; functional parts such as arms, legs, etc., are dispatched to an assembly room. Guns…

View original post 876 more words

SOLID principle

Chanmingman's Blog

There is a lot of debate on SOLID principle.

The video Applying SOLID Principles in .NET   (http://channel9.msdn.com/events/TechEd/Europe/2014/DEV-B210) is worth to watch.

I like the last slide Consideration

SOLID

As he mentioned.

1. Someone just over engineering using the term SOLID

2. How readable for your Dependency Injection if you have large set of object.

3. When talking about maintainable, before SOLID is 50 lines of code, after SOLID is 230 lines of code previewing the same functionality. So you think 50 lines of code is easier to maintain or 230?

View original post

Clean event handler invocation with C# 6

Jon Skeet's coding blog

The problem

Invoking event handlers in C# has always been a bit of a pain, because an event with no subscribers is usually represented as a null reference. This leads to code like this:

It’s important to use the handler local variable, as if instead you access the field twice, it’s possible that the last subscriber will unsubscribe between the check and the invocation:

Now this can be simplified slightly using an extension method:

Then in each event, you can write a single line:

However, this means having a different extension method for each delegate type. It’s not too bad if you’re using EventHandler but it’s still not ideal.

C# 6 to the rescue!

The null-conditional operator (?.) in C# 6 isn’t just for properties. It can also be used for method calls. The compiler does the right thing (evaluating the expression only once) so you can do…

View original post 407 more words

Dependency Injection and highly coupled objects

Coding Journeyman

power-plugI consider that Dependency Injection (DI) is a very helpful pattern, I love to use it in order to reduce the coupling in my code and it helps me when writing unit tests. But sometimes the code depends on objects that are difficult or impossible to mock.

The HttpContext class of the ASP .NET MVC framework is one example of this kind of object.

I created the following Controller and View as examples:

publicclass IndexController : Controller
{[HttpGet]public ActionResult Index(){string[] languages = HttpContext.Request.UserLanguages;return View(model:languages);}}
@model string[]
@{
    Layout = null;
}
 
<!--DOCTYPE html>
 
<html><head><metaname="viewport"content="width=device-width"/><title>Index</title></head><body>

View original post 759 more words

Unity Interception Extension

DarioSantarelli.Blog(this);

Starting from Enterprise Library 5.0, Unity supports interception mechanisms which captures the call to an object at invocation time and provides the full implementation of the object through lightweight code generation (ILEmit). It’s something very similar to the aspect-oriented programming (AOP) approach.

However, Unity is NOT an AOP framework implementation for the following reasons:

  • It uses interception to enable only preprocessing behaviors and post-processing behaviors.
  • It does not insert code into methods, although it can create derived classes containing policy pipelines.
  • It does not provide interception for class constructors.

Instance Interception VS Type Interception

With instance interception, when the application resolves the object through the container,

  1. The Unity interception container obtains a new or an existing instance of the object and creates a proxy.
  2. Then it creates the handler pipeline and connects it to the target object before returning a reference to the proxy.
  3. The client then calls methods…

View original post 980 more words

Design Patterns – Command and Strategy

These two patterns are quite often mixed up, since they both perform an action when invoked.

However there are quite substantial difference:
1) Command should only be used as a trigger for a more complex action and should have no computational logic.
2) Strategy in the meantime encapsulates logical operations.

In simple terms command should have as little logic as possible, whereas strategy might encapsulate some complex calculations. It is also possible that a command triggers a strategy to be executed.

An example from WPF would be a particular control bound to an instance of ICommand which in turn could run a particular strategy.

Design Pattern – Abstract Factory

Abstract Factories are used to provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Consider an example where we need to create a service for sending data. The data could be sent using various means: by calling a web service, WCF service or by using plain sockets.

To avoid tight coupling the object that sends the data should not be aware of how the data is sent. That’s where abstract factory comes into play. Assuming that all senders implement a  common interface, all the code has to do is call the method that accepts data in whichever format. The benefit of that approach is that we can later easily substitute the protocol for sending data without making any changes to the object that sends data.

In addition, the abstract factory allows the creation of multiple instances of the class responsible for sending data. This is a very useful property when we use dependency injection. The abstract factory can be injected through the constructor and the object responsible for sending data is free to create as many instances of the service as it requires.

That pattern not only solves the coupling problem and separation of concerns, but also allows for better unit testing, since the abstract factory can be very easily mocked.

Blog at WordPress.com.

Up ↑