New Site Section: Software

July 19, 2010 · Posted in applications, programming · Comment 

I’ve added a new section to the site for software I’ve created.  Check it out, either from the menu above or via http://matthewcory.com/software/.  There’s only one item there now, a simple todo list manager, but I’ll keep you posted on what else might come up.  Open to ideas, and if you find any bugs, let me know so I can take care of them.

Catch you on the flip side.

–Matt

  • Share/Bookmark

Tags: , ,

A Simple “Destructor” Pattern In Javascript

June 15, 2009 · Posted in programming · Comment 

I’ve been playing around with Javascript a lot more at work lately — in fact, the UI for the current project I’m working on is almost entirely done in Javascript (using the Dojo/Dijit/Dojox library).

In working on the project, I’ve been trying to follow some general “best practices” — not necessarily Javascript practices, but overall programming practices.  One of the main ones I’ve had some fun playing with is a basic destructor bastardization, and I figured what the hell: I’ll throw it out for people to take a look at.

Three notes I want to put out here first:

1) I’m using the Dojo library, but the pattern itself isn’t really library dependent.  The example code I’m giving should translate fairly well to Prototype, jQuery, or even just plain ‘ol vanilla Javascript.

2) Javascript doesn’t have an actual destructor implementation, like an “OnDelete” event or anything like that, so that’s why I say this is a “bastardization” of a destructor — you still need to manually call everything yourself in order for it to work.  But, setting that up to happen automatically when the page is unloaded is a part of the example code I’ll give out here.

3) This may or may not be good practice overall.  I’m not a JS guru by any stretch of the imagination.  I actually started doing this because of a misunderstanding — in FF, my project was leaking memory like a seive, and I thought cleaning stuff up would help.  It has, but most of the memory leaks were because of Firebug holding on to references.  However, I don’t think this code will hurt anything, other than spend a few cycles cleaning things up when the user navigates away from the current page.  If you find out otherwise, please don’t hesitate to let me know.

Anyways, on to the code…

The pattern is really simple.  To start with, we’ll create a very basic Javascript class (again, this is using the Dojo library; tweak to suit your own needs):

dojo.declare("Person", null, {
name: null,
address: null,

constructor: function() {
this.name = "Bob Jones";
this.address = "123 Test Dr.";
},

destroy: function() {
delete this.name;
delete this.address;
}
});

That last function is what this little article is about — “destroy”.  Yes, this is a contrived example, so in the real world you’d probably just let the JS garbage collector handle such a trivial object, but humor me.

Anyways, that’s half the fun right there.  The other half goes into the web page where you’re loading the object (again, using Dojo-specific code):

var thePerson;
function initPerson() {
thePerson = new Person();

dojo.addOnUnload(destroyPerson}

function destroyPerson{
thePerson.destroy();
delete thePerson;
}

dojo.addOnLoad(initPerson);

Of course, that goes in a script tag (I put it at the end of the page, but whatever).

Again, it's such a contrived example that it probably doesn't seem to be of much use -- even if a Person object did leak, so what?  Maybe it won't do a whole hell of a lot as far as overall memory consumption goes, but (IMO) it looks like a better attempt at good practices.

Please feel free to criticize and point out problems with the concept -- again, I don't claim to be any kind of expert on Javascript, so I may be missing the boat entirely here.  And I've been having some minor problems trying to get some good profiling set up -- even with Firebug -- so I couldn't really tell you whether it makes much of a difference in long-term memory consumption or not.

Anyways, I need to start getting ready for work.  Catch you on the flip side.

--Matt

  • Share/Bookmark

Tags: , , , ,

Quick Coding Tip: One Use for Extension Methods

January 21, 2009 · Posted in programming · Comment 

Okay, I’m probably out of the loop on the whole coding thing, and this is probably something that’s been discussed many times, but I “discovered” this yesterday and felt I just had to share it with the programming community.  As an FYI, this is dealing with C# 3.0 stuff — so you’ll need an appropriate compiler to work with it (i.e. VC# Express 2008).

First off, let me introduce the problem this is dealing with.  Personally, I love working with interfaces.  I probably overdo it, but it’s great to be able to write a unit test using interfaces (and mock objects), and know that your code will still work (in theory) regardless of how that interface is actually implemented.  This concept works great if you break your UI up into controls, and have the controls implement your interfaces, but that’s a story for another time.

One of the main problems with this though, is that a lot of your really simple methods — copying data, equals methods, etc. — can’t be implemented in an interface, of course.  Here’s how I used to get around this (and whether this is good design or not is definitely debateable):

First, a simple interface:

[codesyntax lang="csharp"]public interface INoteData {
string Title { get; set; }
string Text { get; set; }
}
[/codesyntax]

To implement a simple copy method, one that you know will work just on the interface and not on any particular implementation, you need to put that method in a different class:

[codesyntax lang="csharp"]public static class NoteManager {
public static void Copy(INoteData src, INoteData dest)
{
dest.Title = src.Title;
dest.Text = src.Text;
}
}
[/codesyntax]

And when you’re using your notes, and you want to copy it, you have to involve this extra class:

[codesyntax lang="csharp"]INoteData src = NoteFactory.CreateNote();
// do stuff with the src note
INoteData dest = NoteFactory.CreateNote();
NoteManager.Copy(src, dest);
[/codesyntax]

Wouldn’t it be cleaner to just do something like:

[codesyntax lang="csharp"]src.CopyTo(dest);[/codesyntax]

Of course, though, you can’t do that with interfaces.  At least, not without forcing every different implementation to re-write the code for that particular method.

Here’s where extension methods can help.  The code is really simple:

[codesyntax lang="csharp"]public static class NoteExtensions {
public static void CopyTo(this INoteData src, INoteData dest)
{
dest.Title = src.Title;
dest.Text = src.Text;
}
}
[/codesyntax]

Then, when you’re ready to use it, you just call it like above:

[codesyntax lang="csharp"]INoteData src = NoteFactory.CreateNote();
// do stuff with src.
INoteData dest = NoteFactory.CreateNote();
src.CopyTo(dest);
[/codesyntax]

And voila!  Instant copy method, that applies across the board to all implementations of the INoteData interface.

Now, this example was assuredly contrived, but I’m sure you can find uses for the overall concept in your project.

Reblog this post [with Zemanta]
  • Share/Bookmark

Tags: , , ,