Category Archives: Software Development

Adventures at Google

If you’re in Boston next week and can spare a couple hours on Valentine’s Day, then check out this seminar at MIT:

“Adventures at Google
Speaker: Martin Farach-Colton
Speaker Affiliation: Rutgers University
Host: Erik Demaine, Frans Kaashoek, David Karger
Host Affiliation: LCS

Date: 02-14-2003
Time: 3:00 PM – 4:00 PM
Refreshments: 2:45 PM
Location: NE43-518

SYSTEMS, SOFTWARE, AND NETWORKS SEMINAR

Google has changed the way search engines are built. I’ll discuss some of the changes, as well as some experiences from my two years in the Google Research Department and the nature of research at a startup.”

More information here: http://www.lcs.mit.edu/calendar/eventView.phtml?Event_ID=243

On object-oriented design

On object-oriented design: “… Should I derive the class Polyline from the class Point? This has fairly obvious answer. A Polyline is clearly not a kind of point, so it is not logical to derive the class Polyline from the Point class. This is an elementary demonstration of what is often referred to as the ‘is a‘ test. If you can say that one kind of object ‘is a’ specialized form of another kind of object you may have a good case for a derived class…. The complement to the ‘is a’ test is a ‘has a‘ test. If one object ‘has a’ component that is an object of another class, you have a case for a class member. A House object ‘has a’ door, so a Door variable is likely to be a member of the class House.” [pg 254 of Beginning Java 2]

Exploring the Factory Design Pattern

Exploring the Factory Design Pattern: “Since most object-oriented languages and runtimes provide object instantiation (e.g. new, newobj, etc.) and initialization (e.g. constructors) mechanisms, there may be a tendency to simply use these facilities directly without forethought to future consequences. The overuse of this functionality often introduces a great deal of the inflexibility in the system, as the direct use of a language/run-time object instantiation function creates an explicit association between the creator and created classes. While associations are a necessary type of relationship in an object-oriented system, the coupling introduced between classes is extremely difficult to overcome should requirements change (as they always do).”

Recommendations for Abstract Classes vs. Interfaces: Visual Basic and Visual C# Concepts

Recommendations for Abstract Classes vs. Interfaces: Visual Basic and Visual C# Concepts [source: MSDN]

On abstract classes: “An abstract class is a class that cannot be instantiated, but must be inherited from. An abstract class may be fully implemented, but is more usually partially implemented or not implemented at all, thereby encapsulating common functionality for inherited classes.”

On interfaces: “An interface, by contrast, is a totally abstract set of members that can be thought of as defining a contract for conduct. The implementation of an interface is left completely to the developer.”