I found this on ThinkGeek: The Cold Heat Soldering Tool.
The Cold Heat Soldering Tool is a cordless tool that heats quickly and cools down nearly as fast. It creates the heat right in the proprietary tip material, making the tool 20 times more efficient than the average conventional soldering iron. The tip reaches 500ºF in less than 1 second for many types of joints and cools to the touch in a few seconds so you can put it away – without any waiting.
All this for only $19 (R115 excluding shipping). Gotta get me one of those.
There has been a lot of discussion on the value of Interfaces lately. Justin feels that Interfaces are not worth the classes that they are written on [1, 2]. I disagree with that statement in general, although I do see (I think) where Justin is going with this, and his argument does have merit.
Firstly, I think that some clarification is in order. I think it's important that the Base Classes be abstract, since a design based on Concrete Class inheritance has bigger issues to contend with than interfaces.
I know this had been said before, but I think it is important enough that it bears repeating: Inheritance [using Abstract Base Classes (which I'll refer to as Base Classes for brevity)] means "is a", whereas using an Interface means "behaves as ". Both Base Classes and Interfaces define a class interface or a contract for the class/implementor. Please note that these approaches are not mutually exclusive; they can be used separately or together. What to use depends on where you intend to have the class used.
Interfaces provide a common (and relatively independent) abstraction to handle completely disparate implementations, whereas a base class approach effectively ties you to a single implementation, limits re-usability, and results in a more brittle design. As I stated, I favor a hybrid approach with an abstract base class providing a reference implementation of the interface in question.
It also pays to look at why we even have interfaces at all; what is the purpose behind them? In a language that supports multiple inheritance (like C++ or Eiffel), interfaces have diminished value. It makes sense to define behavioral contracts using abstract classes which also provide a generic implementation of the behavior. In these languages multiple inheritance allows you to simply plug in functionality to any class that requires it, rather than having to create explicit implementations of an interface; in fact, this is, according to [McConnell], the preferred (safer) way of using multiple inheritance.
In languages that only support single inheritance (like C# and Java), or only interface inheritance (like VB6 - yuck!), Interfaces take on a much more important role. Using interfaces together with object composition allows the developer a similar ability to simply plug in functionality, giving some of the flexibility of multiple inheritance, whilst ensuring that the object models are kept (relatively) simple.
Ultimately it boils down to OOP fundamentals; it's generally a good heuristic (rule of thumb) to keep your class interface as small and cohesive as possible. The biggest risk in using Base Classes comes from the tendency to move unrelated behavior into the base class, as the implementations evolve, resulting in a less cohesive "interface". And whats more, it is easy to do. Sure, you run the same risk using interfaces, but it's not nearly as convenient for the developer, so it's much less likely to occur.
It is also tempting to ignore that behavioral aspect of objects and treat them simply as containers of data (like an in- memory representation of a database row) with methods related to accessing and/or changing the data. This defeats the point of OOP. An intrinsic part of object design is the behavior, and one of the purposes of OOP is to encapsulate behavior and data. And taking this a step further; just as the schema of database table defines the form of the data, an interface defines the form (or contract) of the behavior.
A classic beginner mistake is to use inheritance to provide similar behavior in unrelated classes. Lets look at an example (adapted from Effective C# by Bill Wagner ); consider the three classes below.
They obviously share the common property Name, but conceptually they are not variants of a common theme. Each one is a distinct entity and it would be both naive and dangerous to derive Employee, Supplier, and Customer from the same base class.
A better approach would be to create an interface (say IContactInfo) that specifies the common properties and have each class implement the IContactInfo interface.
I said earlier that interfaces provide a common abstraction to handle completely disparate implementations. This enables us to create methods that will handle any implementation, same or different.
public void PrintWelcomeMessage(IContactInfo info) {
Console.WriteLine("Greetings {0}", info.Name);
}
You could argue that a base class would provide the same flexibility, and you'd be right, for now. The advantage of using an interface comes in the future. Let us suppose that in the previous example we had created a base class called BusinessEntity containing common functionality; we could then have defined the above method as follows.
public void PrintWelcomeMessage(BusinessEntity info) {
Console.WriteLine("Greetings {0}", info.Name);
}
However, what if six months later we have a requirement that Employee needs to support remoting and consequently needs to extend MarshalByRefObject. Now depending on how we've implemented our base class this might be very difficult to do (without affecting the other classes). If we do affect the other classes, by making the change on the base class, there might be repercussions (errors) down the line. Basically it introduces a potentially unknown variable into the equation. By using an interface we can create a completely divergent implementation without affecting any other classes. This is concept is known as the principle of Orthogonality.
I would say that, as a general rule, if the consumers of your class are internal to your system it is safe to use base classes and refactor to interfaces as your design evolves. This echos a comment by Rivaaj Jumna who stated: " I tend to favor the interface driven approach to design, if only because I end up refactoring to interfaces at various intervals." This is, incidentally, also the purpose behind the Bridge Pattern; to "decouple an abstraction from its implementation so that the two can vary independently. "
If your consumers are external, possibly clients using your API, then I think it's safer to use interfaces unless it's absolutely necessary to provide the functionality that an abstract base class would provide.
In summary, the use of Interfaces leads to flexible and reusable designs. While abstract base classes do have immense value within a system, they are not a replacement for interfaces.
powered by IMHO 1.2
This is a bit late, but I noticed that there is a new
version of Fiddler out (0.9.9
released on 1 Feb 2005). For those of you that don't know, Fidder is a HTTP
Debugging Proxy. It effectively catches all HTTP requests/responses on your
system. It's quite simple to use and extremely helpful when debugging web
applications.
I recently used it to inspect why IMHO wasn't functioning correctly at work
(tuned out to be due to an (unresolved) authentication error with ISA Server). I
have also used it in the past to inspect/debug remote scripting
issues.
It is implemented using .NET 1.1 and "includes a simple
but powerful JScript.NET event-based scripting subsystem" called FiddlerScript. FiddlerScript
even has a syntax-aware script editing environment. Plus it's extensible; you
can create your own custom Inspector Objects in any .NET language.
You can download it here. The Fiddler Script
Editor is available here.
powered by IMHO 1.2
For the last few months I have been facing a user input
irritation. I use my notebook
both at work and at home. At work I have a Microsoft
Wireless Optical Desktop Pro (which totally rocks), but at home I have to
resort to using the keyboard and trackpad on the notebook (which sucks). So
yesterday I went out and got myself a Microsoft
Wireless Notebook Optical Mouse.
This is uber cool. Not only is it both wireless and
optical (obviously), but it's extremely compact. Plus it has a very long battery
life (well at least according to the brochure) - 3+ months on a single AA
battery. The wireless receiver is USB and plugs into the bottom of the mouse
when not in use, thereby disabling the optical sensor and conserving battery
life.
All in all, I'm a much happier camper, plus it didn't break the bank. It cost
a mere R230 ex VAT, which is cheap at the price.
powered by IMHO 1.2
Warning: Rant about to commence.
At a recent daily status meeting the topic of our corporate firewall came up (one of the developers needed a port opened to replicate data to a remote server). A colleague of mine announces that he has a buddy at Redhat who can help since we are using an "Apache" firewall.
Apart from the obvious security issues (letting a stranger tinker with our firewall), and the fact that our own Systems Administrator is perfectly capable of getting this done; there is no such thing as an Apache firewall.
Since I know that we use a PIX firewall with ISA server as a proxy, I responded with: "Dude, Apache is a web server". To which I received an extremely frosty "No! It IS a firewall".
How to you argue with stupidity like this????
Yay! My most recent book order just arrived. This is the first time that I have ordered on Bookpool and I must say that I'm impressed. Not only were they cheaper than Amazon.com, but a mere 15 days after I placed my order the books where here.
These are the books that I ordered:
I've been extremely keen to read both of these, especially Applying UML and Patterns. Martin Fowler recommends it as "the best book to introduce ... the world of OO design". The 3rd edition also has a greater focus on agile methodologies (this book proposes using the Unified Process as a methodology) to be used in conjunction with UP. Like Fowler he also suggests using "UML as a sketch" with ties into the ideas presented in Scott Ambler's Agile Modeling.
As for Effective C#; it follows in the foot steps of Scott Meyer's excellent Effective C++ and More Effective C++. Both of which offer a multitude of insight into improving your C++ code. I hope this book adds the same value that those do.
I'll post some reviews (assuming I'm up to it) once I'm done.
Okay, now that I've got your attention with a snappy headline...
I found some interesting viewpoints on development using .NET (personally I'm sold, but it's always good to view both sides of the coin).
First off we have Mark Russinovich (Windows Internals expert of sysinternals.com fame) arguing that .Net is too bloated in The Coming .NET World – I’m scared.
In rebuttal Ken Henderson, (Sql Server Guru) reckons that .Net is the best thing to hit software since OOP.
Draw your own conclusions?
Just a quick reminder.
The next patterns session will be held on Wednesday, 6 April 2005 in the Conference Room at Marriott-at-Kingsmead, Kingsmead Office Park. The session will start at 17:30 sharp and will run for approximately 2 hours.
The patterns under discussion will: Iterator (p. 257) and Template Method (p. 325).
Please RSVP on this thread.
Reading an article, comparing the performance of the Enterprise Library Logging Block vs log4net, discovered the following gem: DevPartner Profiler Community Edition.
If you've ever used DevPartner Studio, you'd have seen the fully fledged version of this product, but as a free download this will do hey!
It is available here (42Mb).
Update: The article that I was reading was this one.
[via Martin Fowler]
(Here's an addition to your dictionary.)
Detestable (adjective): software that isn't testable. (from someone at the Sydney XP group, whose name I sadly forgot.)
I found this great post on Scott Hanselman's blog. I found it to be a real eye opener and a very valuable measure of how much and (in some areas) how little I know. I reckon its a must read for anyone whose serious about developing in .NET.
Just a quick reminder that the next patterns session is on Thursday (3 March 2005) evening at 5:30pm at in the conference room at Marriot-at-Kingsmead.
The Patterns under discussion are: Decorator and Composite.
See the our group for more details.
The Enterprise Library has finally been released. Sweet gorrilla from manilla. :-) I've been waiting for this for ages. You can get it here.
The first Durban Patterns Group meeting flopped due to lack of attendance (bad time of year I guess), so its time to try again.
It will be held on the Thursday the 20th of January 2005, in the conference room of Marriott-at-Kingsmead, Kingsmead Business Park. Start time is 17:30.
Everyone attending the first session is required to have read up on the Factory Method [1,2] pattern. I envisage roughly a 1 hour (2 hours max) session of discussion and whiteboarding. It might be useful if everyone attempts to implement an example of the pattern to be covered in the session to get a feel for it in application, other than just reading about it.
Please note: You will need a copy of [GoF] (print/electronic) in order to do the readings between meetings. If you require one, contact me and we will see what we can do.
Update: I have set up a group for news, events and discussion about the group. It is accessible at http://groups-beta.google.com/group/Durban-Patterns-Group
More Posts
Next page »