Posts Tagged ‘Program Design’

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.

Tags: , , , , ,
Posted in Uncategorized | No Comments »

Structured Exception Handling in .NET Part 5: Throwing new Exceptions

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

As I mentioned earlier, throwing Exceptions can be a very useful way of notifying the appropriate code that something unexpected happened.  In order to throw an Exception, first you create an object of type Exception, or a class which inherits from Exception if there is a more appropriate one.  You should also set the Message property, which can usually be done from a constructor.  You can actually do all this in a single line.  eg.

Throw New Exception(“Invalid username”)

Some Exception classes will want additional data, depending on the type of Exception that you are notifying about.  It is worth looking around the .NET framework or any other set of code that you are using to see what Exceptions are available.  I will post up some common ones in a later post.

Tags: , , ,
Posted in Uncategorized | No Comments »

Design Patterns

Friday, March 14th, 2008

Sometimes in programming, you find the same problem coming up quite often. It is usually worthwhile working out a standard solution to the problem, or finding out if someone else already has. This solution is called a design pattern. It isn’t actually a piece of code itself, but it is a way of solving a particular recurring problem.

Once you have worked out a design pattern, you can often come up with some code to implement all or part of it, or at least a set of utility functions that will help.

Tags: ,
Posted in Uncategorized | No Comments »

Practical Code Organisation and Reuse

Thursday, March 13th, 2008

I find the following are useful pieces of advice for keeping code organised: -

  • Try to plan out as much as you can do beforehand and work out what you are going to need to reuse.
  • If you feel like you are doing the same task a second time, see if you can work out a way of making it reusable code then. If you leave it, it will be a bigger job to go through afterwards and sort it out.
  • It is usually worth putting all the data access and business logic code into a library for a project, and just keeping the user interface in the actual executable or website. Even if it looks like you are never going to need the library for anything else, it makes you organise the code better, and you never know when the client will decide that they want a new system to access the existing data.
  • Work out the scope of what you are going to reuse. It is worth having one or more shared code libraries for use across different projects for anything that you think will come in useful again. If you are certain you are only going to reuse within this project, put the code inside this project’s executable or library, otherwise, it is worth thinking about how you might reuse it in future and put it in your shared library.
  • Train yourself to spot patterns. If you use your imagination, you can work out some clever reusable pieces of code that can perform all sort of general functions.
  • Build it up slowly. Don’t try to make an enormous function that does everything at once. If you are absolutely sure you are never going to use the internal functions, make them private. If they are going to be useful by themselves directly from outside, make them public. See my articles on Black Box Coding and Coupling and Cohesion for more details.
  • It is worth using well thought out Namespaces to organise your code.

Tags: , ,
Posted in Uncategorized | No Comments »

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.

Tags: ,
Posted in Uncategorized | 1 Comment »

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.

Tags: , , , ,
Posted in Uncategorized | No Comments »

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.

Tags: , ,
Posted in Uncategorized | 1 Comment »