Posts Tagged ‘Object Orientation’

Linq and Reflection

Wednesday, April 2nd, 2008

I’ve been using Linq to do queries on Reflection objects recently and I’ve found that it works quite well.  An example: -

From pi In Me.GetType.GetProperties Select pi Where pi.CanRead And pi.CanWrite And Not pi.Name Like “*_Display” And pi.GetGetMethod.GetParameters.Length = 0 And (pi.PropertyType Is GetType(String) Or pi.PropertyType Is GetType(Boolean) Or pi.PropertyType Is GetType(Date) Or pi.PropertyType Is GetType(Integer) Or pi.PropertyType Is GetType(Boolean?) Or pi.PropertyType Is GetType(Date?) Or pi.PropertyType Is GetType(Integer?) Or pi.PropertyType.IsEnum)

On Reflection Part 2: GetType

Monday, March 24th, 2008
This entry is part of a series, On Reflection»

In order to use reflection in .NET, you need to get an object of class Type.  I will explain how to use the Type object later, but first, you need to be able to get it.

There are 3 ways to get a Type in .NET.

  1. VB.NET has a GetType keyword which takes a class as a parameter.  eg. you can writeDim T as Type = GetType(String)

    This is not really a function, because you are passing in a class, not an actual value, and not even the name of a class!  C# has a similar keyword, which I think is called typeof.

  2. All .NET objects inherit from Object.  Object has a function defined on it called GetType, so all you need to do is eg.Dim p as New Person()
    Dim T as Type = p.GetType()

    Note that if you have an Interface reference you may need to cast it using the CType operator in order to access the GetType function.  You should be able to cast any .NET object to Object.

  3. You can get a Type by name from an Assembly.  I will post details on this in a later post on Assemblies.

On Reflection Part 1: What is Reflection?

Friday, March 14th, 2008
This entry is part of a series, On Reflection»

Reflection is a way of finding out information about the structure of an object. In other words, we can find out information about what fields, methods, properties, events etc. it contains, usually including names and types. Once we have this information, we need to be able to use it, so in .NET, we have methods for accessing all these things via reflection.

The point in this is that we can write reusable code that can be very generalised to work across all sorts of different classes. This can save us a lot of time in the long run and it often makes the code a lot neater. I quite often find that reflection can save me time even in the short run, so it is well worth the investment of time in learning how to use it.

Entries in this series:
  1. On Reflection Part 1: What is Reflection?
  2. On Reflection Part 2: GetType
Powered by Hackadelic Sliding Notes 1.6.5

Structured Exception Handling in .NET Part 1: Try/Catch/Finally

Thursday, March 13th, 2008
This entry is part of a series, Structured Exception Handling in .NET»

A friend has asked me to write some articles on how to handle exceptions in .NET, so here we go… A little bit of background first: -

Exceptions occur when things go wrong or other exceptional circumstances. They are a bit more complicated than the older error trapping systems, but the complexity lets you do a lot with them. Every Exception is an object, and it is either an object of type Exception, or of a type that inherits from Exception.

In this post, I’m just going to deal with catching a general Exception. I’ll cover what you can do with the Exception class itself, multiple Catch clauses, different Exception types, re-throwing and creating your own Exception classes in other posts.

So here is the way it works. When something goes wrong, an Exception object gets created and “thrown”. This means that the stack rewinds back until it finds something that catches the Exception. Basically, this means that anything that gets called inside a Try clause will be handled if an Exception gets thrown. Not only that, but any functions that that calls etc. on and on either forever or until there is another Try clause that will handle it. “Later” Try clauses take precedence over earlier ones.

This is how to use it…

Try
   Some code
Catch ex as Exception
   Some exception handling code
Finally
   Cleanup code that gets called whatever
End Try

Note that the Finally clause is actually optional – it is fine to leave it out. You would normally use it if you wanted to close a database connection, file, stream, network connection etc. or some other form of cleanup code. Also, you can have multiple Catch clauses, but I’ll cover that later.

Coupling and Cohesion

Wednesday, March 12th, 2008

There are a 2 factors that affect object oriented design a great deal – coupling and cohesion.

Coupling is how many links there are between different objects, and to what extent objects are dependent on each other.

Cohesion is how well an object is defined in terms of performing a specific task, all the things it needs to do for that task and sticking to that task without it blurring into doing too many other things.

The idea is to minimise coupling, and maximise cohesion.

In other words, you want your classes to have as little reliance on each other as possible, and  to be as specialised as possible at performing specific tasks.

Custom Constructors and Overloading Constructors in .NET

Wednesday, March 12th, 2008

A lot of people don’t take advantage of the fact that .NET will let you create custom constructors and overload them.  The advantage of this is that you can force an object to be in a valid state once it has been created even if it needs some data to be able to be in that state.  Even if it doesn’t need any data, you can still provide a constructor with no parameters and overload it with parametarised constructors as alternatives.  That just makes using the class a lot easier when it comes to creating objects.

Black Box Coding

Wednesday, March 12th, 2008

I’m a big fan of designing my code to work like black boxes. The idea is that you can interact with each object without ever having to worry about how it works inside. You should never need to look inside. It should have all the functionality you need from the outside. My ideal way of building up a framework is by building layers of objects based on this principle on top of each other.

For example, if you build a Windows Forms UserControl, whenever you use it, you should never need to know what controls are inside it. Everything should be accessed via a set of properties and methods on the object, not via accessing the child controls.