Author Archives: Tobint

Engineering for usability: Vending machines

Today, I used a vending machine. Anyone that has met me will surmise that this was obviously not my first attempt to purchase an unhealthy snack from such a contraption. In fact, not only have I excessively used of vending machines, I’ve written code for kiosks that use the same currency and coin accepting hardware as vending machines. Suffice it to say this long paragraph was meant to proclaim my self-appointed title of “Certified Vending Machine Professional” (CVMP).


However, with all of my years of experience, today’s experience was different. Today, I approached the vending machine, tired from lack of sleep the past month, distraught over having to get my cat a permanent tracheotomy, cranky from a back problem, and distracted by tons of work-related issues running through my head. I carefully stood in front of the machine contemplating what I would get this time — as though the product selection would have changed between now and the last time I looked. Well, I am supposed to be on a diet, but due to the massive amount of life-issues I’m having at the moment, I decide a “healthier” vending machine snack of pretzels will suffice this time. “D10, 65 cents, ok.” I think to myself as I begin to press the numbers out on the keypad “D, One, Zero — CRAP!”. As it turns out D-10 expected me to press D and then press a key they had specifically set to 10 — not 1 then 0 as I was thinking. I knew this. I’ve used enough vending machines in my life to know how they work. But today, I failed the test. I immediately began to blame the vending machine and started re-engineering a smart vending machine in my head.

Here were the problems I saw with the current design.


  • The keypad was placed at the bottom of the machine, forcing me to bend my already soar back over to press the numbers. I’m not exactly tall but these numbers were way the @#$* down there!

  • The vending machine made me bend down even further to retrieve my calorie-clad selection from a bin.

  • The numbering / item selection routes were flawed with that D10 vs D1 conundrum.

  • The selection sucked

  • They only accepted cash or coin which I often don’t carry.

The “lets design something cool” personality in me immediately started thinking about solutions to this problem.


  • Put a camera on the vending machine that recognized the height of the customer. The vending machine should immediately raise or lower the keypad based on the user’s height.

  • Place the items on a selection belt where the item is dispensed into a bin and procured to the user at a height that’s reasonable — again based on the height of the user requesting the product.

  • At the minimum, remove single-numbered selections and replace with all double digit numbers — force the user to press the number sequence out. At best, prompt the user to press “submit” when they are done selecting their item number. Don’t automatically dispense the product based on the first match of a selection.

  • Provide a digital feedback center where you could request the vending machine carry your favorite flavor of twinkie.

  • Place a credit card slot on the machine

But then the “practical architect” personality interjected with complaints to these solutions. First off, lets think about this. Who is the customer of a vending machine. Was it me? Surprisingly, no. The vending machine “customer” was the company who bought it with the intent to make a profit from it. Sure, I may use the vending machine, but ultimately, its the vendor that wants the mechanism that accepts payment and dispenses product. We unwittingly provide our services as testers of the product and give feedback on it (based on our use or non-use of the product). That whole argument is reserved for another post though. Blindly accepting my argument that the vendor is the customer of a vending machine, your next question is to ask, what are the vendor’s requirements for the machine.


Using a lose set of some of those spiffy PASS MADE criteria from the MSF exam (70-300) for your MCSD, lets take a look at those requirements.



  • Provide a fast transaction from which a user can request a product and get out. Quick response to user request for product.(Performance)

  • Provide a usable interface from which to conduct unmanned transactions. (Accessibility)

  • Provide a safe way to keep money received from the transactions. (Security)

  • Provide the ability to easily add more product to the machine — for those of you that don’t know this, they actually can add additional slots next to the vending machine without adding additional currency acceptors. (Scalability)

  • Provide a mechanism that works nearly every time with little intervention required by the vendor. (Maintainabilty)

  • Provide 24/7 access to any would-be customers. (Availability)

  • Allow these items to be shipped easily without fear of breaking during transit or movement from one location to another (Deployability)

  • Allow alternate methods of payment, exchange of hardware, and various types of product to be dispensed. (Extensibility)

So lets apply these characteristics to my “solutions” from above. We’ll find out these were not solutions at all, but fixes to perceived problems from a single-minded personality. My Architect (as I’ll refer to that voice in my head), says this.


The product isn’t on a belt because the time spent between asking for the product and obtaining it could potentially take a lot longer (Performance). The keypads were not arbitrarily placed at waiste level to tick me off, they were blatantly placed there to provide easier accessibility to those who are height-challenged or otherwise requiring accessibility. The credit card reader isn’t placed on the machine because it would be too easy to intercept. These vending machines can be placed anywhere, and sometimes in really poor choices (rest areas, for instance). While having a vending machine broken into would be bad, having credit card data compromised from one of these locations would be worse. (Security) Placing the items on a belt would make it harder to provide additional items in the physical range of motion of the device. It would be harder to add more product to the machine this way — and much more expensive (Scalability). Those devices would also have a large amount of moving parts that could break. Putting the keypad on a moving device as well as the product would reduce the useful life of a vending machine while raising the cost of it — bad for any investment. It would also be susceptible to significant breaks and massive amounts of upkeep (Maintainability). Putting these items in a bad area would be an even worse move. They would be much more expensive to replace and fix if someone vandalized them — much more, that is, in relation to a simple spring delivered product dispenser that relies on gravity to get the product to its location. The parts would definitely have a much higher dead-on-delivery rate than normal vending machines — causing massive replacement shipping/delivery costs (Deployability). This is a stretch, but by placing additional overhead on these machines, you actually reduce the available room to provide additional hardware to the machine. You could be restricted to a smaller area and some additional hardware may interfere with other pieces of hardware causing more issues than it solved (Extensibility).


Availability, therefore, seems to be the only area that I wouldn’t have negatively impacted by my decisions for a vending machine. As software engineers, we need to make sure we aren’t over-engineering our products. Many times the “cool” solution isn’t the right solution. For instance, the delivery mechanism, while annoying for anyone that is tall or has a back problem, is fairly consistent. I mean, who has a better system than gravity? Last I saw it was a constant! Sure, occasionally product gets stuck in the machine before gravity can do its part, but I guarantee the mechanical delivery system would be much more prone to mistakes than the simple “twist and drop” method of most vending machines. While I may have potentially solved “my” problems, I’ve caused many more for my real customer — the vendor. In actuality the dependability of my vending machine would have cost more money to purchase and maintain, caused dependability problems due to mechanical failure, and most likely annoyed everyone more than “New Coke” ever did.


Yes, its great to solve your problems in cool ways, but make sure the problems you are solving are for the right person and actually advance your product design before adding more features than are necessary.

School Security:Blaim the kids & send them to jail

So now you can now send kids to prison and charge them with felonies when your security is so lax that they can waltz in. Here’s the long story.

Here’s the short story.

A school handed out Apple iBooks to 600 students in a school. These laptops had various “security” features on them to keep them from accessing parts of the internet, or installing anything. They also had monitoring software that allowed a school administrator to see what was being viewed on the student’s laptop. I appologize that I don’t know if the software was custom made or if it was a known package. In any case, the password used to bypass these features was foolishly taped to the back of the laptops.

Using this password, the kids bypassed the software so they could download iChat to talk to each other. They also reportedly turned the tables on their school by monitoring the administrator’s desktops instead of the other way around.

This is typical childhood behavior. Kids are currious and given the opportunity to explore, they are going to do so. Given a challenge that they “cannot do x”, they will do x, y and z to prove you wrong. As the kids pointed out, and I oddly enough agree with the kids for once — the punishment doesn’t fit the crime. I’ll go one step further to say the punishment doesn’t fit the right people. Those involved with the “security” of these systems need to be shot. We’ve had examples of disobience to simple rules that date back to Adam and Eve and a simple piece of fruit. What makes you think that history will somehow change itself and kids will simply obey an order? If they are curious, and you leave the door open enough to fit their fingers through, they will find a way in.

In my mind, the correct response to this would be to give them a slap on the wrist for the disobedience, put the kids in some sort of programming course , nurture their natural abilities, sack the programmers who wrote the systems to begin with, and charge the kids with designing a better system. To me, that’s education!

Charleston Code Camp: Saturday September 17th

OK guys and gals. Some pretty big names are rolling into Charleston on Saturday, September 17th to present, free of charge, all those fancy topics we love to yap about so much. This is Charleston’s first code camp. Chris Williams tells me that enrollment is low. What would it take to persuade a few more folks to take a nice weekend trip to a college/beach town, watch some cool technology in a demonstration and go have a few drinks?

Check out the sessions and the speakers. If you don’t find anything you are interested in, come anyway and enjoy the beach with your fellow geeks! Please register quickly!

Escape From Yesterworld!

Since I ended up on the INETA Community Launch Team, I guess I should start promoting a few things about Visual Studio .NET 2005 and SQL Server 2005. After all, it can’t ALL be about JAXASS (Javascript And XML Accessing Services Simply) , can it? Let me start by pointing you to this new tidbit from Microsoft. Its an awesome play on some well known comic movies of the past called Escape From Yesterworld. Prepare to spend a little time there, but be prepared to laugh int he process. Someone sunk a LOT of time into this promotion video/site, so the least you can do is click on the main page and check it out.

Does standardizing technology stifle creativity?

I’ve been talking with a few people recently about COmega, C# 3.0, C# 4.0 and the like. On top of that, I try to get my hands on anything “new” that I can well before it becomes of interest to the general public. I keep getting asked why I like to sit on the razors edge (or at least pretend to). I usually tell them its because its the only way that I can continue to remain creative in this field. The rest of this post articulates my rationale behind this idea.


I’m definitely a child of the PC computing industry. I’ve grown up around computers. I’ve seen one innovation after another. I have to say the most amazing times in my programming life have been spent hunched over a computer all night hacking out a new way to solve a problem. Even later in my professional career, during the “high-tech late 90’s” I had a blast playing with xml data islands before example one hit the list server (wow, does anyone remember learning new concepts on list servers? yikes I feel old). Whatever the case, what was interesting was that everyone was learning something new because everyone was solving technology problems on their own; sometimes for better and sometimes for worse. But every programmer had to learn to be creative to solve problems.


In recent years, the big push is to standardize technologies at the earliest possible moment — locking most programmers into one way to solve a problem. Failing to follow the standard usually lands a host of glaring architect eyes on you. You can bet if you do come up with a new way to do something, someone is already trying to create a standard to the contrary; again, most times for the better and sometimes not. Sometimes those standards, at least initially, fall far short of being a good solution for more than a handful of people (i.e. WSE). But as more people jump on board, those standards morph into something more usable by others (i.e WS-* added to WSE-n). Sooner or later, design-time components are emassed by third-party companies like a bad mildew stain around these standards. We are all sort-of stuck using those tools and those standards until Microsoft decides to devour that component industry and write their own wrappers around the standard.


There are only a handful of people who then have any say on the standard and the self-proclaimed “right way” to do things. Sure, these standards do let us focus more on solving the business problems instead of technology problems, but who wants to do that? We can sit back in our spare time and “play” with our own solutions, but when you get back to work in the morning, its back to WSE-2, RSS, AJAX, and other various paterns and practices.


I do understand the benefits, so don’t get me wrong. I’m so much happier to have a tool generate my WSDL , at least from a starting point, than for me to do it myself. I do get to look at some other cool technologies because I can look past some of those questions that the standards answer for us. However, with all the real benefits that standardizing brings to us, there are times when I miss having the freedom to innovate on my own without looking how everyone else does it first.


That is the treaty that the business folks have signed with us geeks — we get to play with their expensive toys and data centers but only if they get to make us “more productive” with standards bodies.

The house of pain is in effect ya’ll

I’m still sitting here with my back in agony but working on some very cool projects. As you’ll notice my post count has dropped each month, slowly but surely. I hope you don’t hold that too much against me. Forgive the dorky analogy, but I have too many threads executing in my life right now and not enough time slices in the day to handle everything and blogging without reaching my saturation point — the point where context switching takes up more time than is effective to execute my processes. Unfortunately, I’m running under more of a cooperative model and these project schedules don’t neccessarily play nice-nice with one another. Between work at TiBA, projects for Microsoft, book writing, investigating features of CO and SXM, learning some lower-level programming to keep up with the Jones’, putting together a new presentation for Code Camp in Charleston, and presentations for multiple guild meetings (October, November, December), posting a few answers here and there on the forums, I don’t have much time to myself. Blogging, therefore has had its thread priority set to below normal.

Speaking of cooperative threading, I’m proud to say that my recent eBay addiction landed me a brand-spanking new copy of Windows 3.1, MS-DOS 6.2 and a MS-DOS 6.22 upgrade (no Windows 3.11 upgrade yet). These copies are sealed and even still have a part number sticker on them from the large computer manufacturer these were sold by (OEM). They will go in my museum of artifacts. I am having a bit of buyer’s remorse though. I’ve spent too much money on useless things like my ATARI 800XL which I fully expect to be here a couple of days after the July 4th holiday. This too was a brand new system (appears new and unused).

Anyway, enough babbling for the night.

Sleepless in Greenville

For two weeks solid, I’ve been stuck in some sort of zombie mode. I’ve been unable to sleep for more than an hour at a time, or not at all some nights. I have had some major back pain in the past week and a half too so that may have something to do with it. But as I sit her ein my computer nook at my baren apartment, I find myself wide awake but unable to concentrate enough to do anything constructive. I try doing my work and I cannot. I try taking a couple unisome and laying in bed, instead I feel like I’m on some sort of acid trip. The type of sleep that unisome attempts to induce is something very strange to me. Its like the drugs are trying to “trick” me into falling asleep. It may sound slightly crazy, but I’ve somehow conditioned myself to get wide awake when I feel I’m being tricked. So taking unisome just makes me feel very strange, but even more awake. I’m not anxious about anything. I’m not taking on more or less work than I usually do. I’m just, awake and in pain from my back.

I’ve tried everying I can think of and its getting worse. Does anyone else get this way?

Throw-away projects in .NET

There are tons of new features in Whidbey. Enough so that I feel that the learning curve going from 1.1 to 2.0 can be easily 50% that of the effort going from to 2.0 (if not more). You can spend your time learning generics and predicates and partial classes and reliability contracts for threading and , well, you name it. However, sometimes its the little features that mean so much. VS.NET 2005 provides a little known feature that allows you to create projects, run them, test them, etc. However, unlike you might be currently used to, when you close the project, you can make the whole thing go away. In other words, you can open VS.NET to test a theory, run the project, do your debugging, and then dump the project so it isn’t wasting file space of virus scanner time. To impliment this feature, go to Tools | Options to display the options dialog. Under this dialog, choose the Projects and Solutions tree node.Uncheck this “save new projects when created” checkbox. Apply the changes.


Now, when you close VS.NET with an open/active project, it will ask you if you want to save it. If you click no, the folders are complete gone. Isn’t that awesome!?


Well, I liked it anyway.

Atari 800XL – Old school fun

The other day, I posted an article about not having any gadgets to play with anymore.  So as I was sitting here debating what to buy, I started searching ebay and somehow came across an old Atari 800XL – Still in the box! This was the first computer I ever owned. My parents gave mine away several years and I haven’t been the same since. I wrote some of my first text-based games in 5th grade on that computer. In any case, I purchased the Atari and won it at a very hefty sum for what it was. I then went a little nuts and bought the assembler editor for it, Atari BASIC (my old programming language), and a few other extras. In case you are wondering, yes, those cartridges will fit into an Atari 2600. They wont do much though in the game console. I have to see if I can get a 1010 casette drive or a 1050 disk drive. I wouldn’t mind the 1030 printer either. I started surfing for some information on how to program these things, because its been 20 years since I’ve seen them. Low and behold, I hit the jackpot at www.atariarchives.org. This site is unbelievable. Tons of books on Atari programming online at no charge! They even had one of the books I had as a kid: Atari Player-Missle Graphics in BASIC. I don’t remember what the other book was, but I’ll continue digging when I’m more coherant. 
This is great stuff to play with, particularly if you are trying to learn the internals of a computer and how to program at machine, assembler, or high level language levels. Because this is an 8 bit primitive system, its much easier to learn how to manipulate the machine to do what you want. You can then scale that knowledge out to 16, 32 or 64 bit systems. I cannot wait to get this item shipped to me, and I’m dying to get it on my desk at work. 
So maybe this isn’t the high-tech I imagined myself buying as a first swat against the scurge of gadgetlessness, but it sure is going to be a very nice one for me. I promise to buy something more meaningful soon.

Overrides vs Shadows keywords in VB.NET

When most folks come from a VB 6 background (and only VB6) they tend not to quite grasp object oriented programming right off the bat. Its one of the reasons why inheritance topics are fairly common on the Visual Basic .NET forums and newsgroups. Today was no different. I woke up and browsed the MSDN forums to find another such question. The user was asking what the difference between an Overridable method being overriden with the “Overrides” keyword, or an ordinary method being overriden by the “Shadows” keyword.

I decided to write a quick article about this and post it for future reference.

First off, lets define the similarities between these two keywords. Both Shadows and Overrides define a means to decorate our methods so we can redefine the functionality provided by a base class. So if I create a BaseClass, and then create a SubClass that inherits from BaseClass, its possible that I might want to redefine how the base and sub classes behave and interact with one another. While I can use either of these keywords, they are completely different in their orientation.

Let’s jump right into it by writing ourselves a base class. This class will have two methods — one that has an overridable method, and one that uses an ordinary method.

' BaseClass impliments an overridable and ordinary method
Public Class BaseClass
  Public Overridable Sub OverridableSub()
    Console.WriteLine(" BaseClass.OverridableSub() called")
  End Sub
  Public Sub OrdinarySub()
    Console.WriteLine(" BaseClass.OrdinarySub() called")
  End Sub
End Class

When you see the overridable keyword in a piece of Visual Basic code, it is an indicator that the designer of this class intended or expected that this class would be Subclassed (overridden) at some point and that “OverridableSub” was a likely candidate for functionality redefnition. You can also deduce that the designer didn’t intend for OrdinarySub to be overriden.

For a bit of advanced education, lets look at the IL produced by these methods.First off, the OrdinarySub looks like any other subroutine we’ve seen in IL before.

.method public instance void OrdinarySub() cil managed

We have a public instance method. Look what happens, however, with our OverridableSub method signature.

.method public newslot virtual instance void OverridableSub() cil managed

Notice we have two additional method characteristics added : virtual and newslot. The virtual characteristic should be familiar to most C# developers. It indicates that the item can be overridden. With that definition, it should now be obvious to VB.NET developers that this means the method has the Overridable modifier. The second characteristic is newslot which indicates that the method will always get a new slot on the object’s vtable. We’ll get into this more later.

So if we want to test our BaseClass, we might write a piece of code something like this in our Main method:

Module Module1
    Sub Main()
        ' Create an instance of the base class and call it directly
        Console.WriteLine("+ Calling BaseClass Methods")
        Console.WriteLine("--------------------------------------------------")
        Dim bc As New BaseClass
        bc.OverridableSub()
        bc.OrdinarySub()
        Console.ReadLine()
    End Sub
End Module

And of course executing this code we would get our exepcted results as follows:

+ Calling BaseClass Methods
--------------------------------------------------
   BaseClass.OverridableSub() called
   BaseClass.OrdinarySub() called
As you'll notice it states that we executed both of our methods against the BaseClass instance. Sounds great, now let's say we now want to create a class that inherits from BaseClass:

' SubClass impliments an overriden BaseClass with overrides and shadows modifiers
Public Class SubClass
    Inherits BaseClass

    Public Overrides Sub OverridableSub()
        Console.WriteLine("   SubClass.OverridableSub() called")
    End Sub
    Public Shadows Sub OrdinarySub()
        Console.WriteLine("   SubClass.OrdinarySub() called")
    End Sub
End Class

To be able to override both of these methods, and stop the compiler from barking at us, we needed to use the overrides keyword on our OverridableSub and the Shadows keyword on our OrdinarySub. This is obviously because of the way we have implemented these methods in the base class. Shadows is a fairly appropriate word because what we are doing is putting the original method (OrdinarySub) in the proverbial shadow of our new method. Our new method stands over top of the old method and executes any time we call against a direct instance of SubClass. Let’s exand our Main method to execute both our SubClass and our BaseClass to see what the difference is:

Module Module1
    Sub Main()
        ' Create an instance of the base class and call it directly
        Console.WriteLine("+ Calling BaseClass Methods")
        Console.WriteLine("--------------------------------------------------")
        Dim bc As New BaseClass
        bc.OverridableSub()
        bc.OrdinarySub()
        Console.WriteLine()

        ' Create an instance of the sub class and call it directly
        Console.WriteLine("+ Calling SubClass Methods ")
        Console.WriteLine("--------------------------------------------------")
        Dim sc As New SubClass
        sc.OverridableSub()
        sc.OrdinarySub()
        Console.WriteLine()
        Console.ReadLine()
    End Sub
End Module 

It follows that because we’ve overridden both of our methods our output would look as follows:

+ Calling BaseClass Methods
--------------------------------------------------
   BaseClass.OverridableSub() called
   BaseClass.OrdinarySub() called

+ Calling SubClass Methods
--------------------------------------------------
   SubClass.OverridableSub() called
   SubClass.OrdinarySub() called

We now are executing code that executes against a BaseClass instance, and we can tell by the output that we are calling the base class methods. We are also executing code against a SubClass instance and we can tell that this is executing our new functionality because the method states its executing SubClass.OverridableSub() and SubClass.OrdinarySub(), not BaseClass.OverridableSub() and BaseClass.OrdinarySub().OK, so we still haven’t seen a difference. Both of these methods really accomplished the same thing didn’t they? We had a base class behavior and both methods overrode that behavior with our newly created methods, right? True enough, but lets look at the consequential differences when we pass our reference around in different ways. We can see example after example in the framework where a method will take a parameter as a general type, but it really expects us to pass in a more specific type. For instance, if a parameter is typed as an XmlNode, we can pass in XmlElements, XmlAttributes, XmlConfigurationElement etc. The list goes on. Why can we do this? Because generally speaking, if I’m an XmlElement, I am also an XmlNode. An XmlElement is a more specific implementation of an XmlNode, so while the XmlElement has more functionality, it still has the base functionality provided by its inherited type XmlNode. So what happens if we create methods that takes BaseClass as a parameter and we pass in an instance of a SubClass as follows?

' Calls the OverridableSub method of the instance passed to it
Public Sub CallOverridableSub(ByVal instance As BaseClass)
    instance.OverridableSub()
End Sub

' Calls the OrdinarySub method of the instance passed to it
Public Sub CallOrdinarySub(ByVal instance As BaseClass)
    instance.OrdinarySub()
End Sub

Notice that we have too methods that both take an instance of BaseClass, not the more specific SubClass. Additionally, we are calling the OverridableSub() method in one of these methods, and OrdinarySub() in the other. Let’s add more code to our Main method to execute these methods passing in an instance of a SubClass. The full code for our example should look like this:

Module Module1
    Sub Main()
        ' Create an instance of the base class and call it directly
        Console.WriteLine("+ Calling BaseClass Methods")
        Console.WriteLine("--------------------------------------------------")
        Dim bc As New BaseClass
        bc.OverridableSub()
        bc.OrdinarySub()
        Console.WriteLine()

        ' Create an instance of the sub class and call it directly
        Console.WriteLine("+ Calling SubClass Methods ")
        Console.WriteLine("--------------------------------------------------")
        Dim sc As New SubClass
        sc.OverridableSub()
        sc.OrdinarySub()
        Console.WriteLine()

        ' Pass the SubClass instance to a method passed as a BaseClass reference
        Console.WriteLine("+ Calling SubClass Methods passed as BaseClass")
        Console.WriteLine("--------------------------------------------------")
        CallOverridableSub(sc)
        CallOrdinarySub(sc)
        Console.WriteLine()
        Console.ReadLine()
    End Sub

    ' Calls the OverridableSub method of the instance passed to it
    Public Sub CallOverridableSub(ByVal instance As BaseClass)
        instance.OverridableSub()
    End Sub

    ' Calls the OrdinarySub method of the instance passed to it
    Public Sub CallOrdinarySub(ByVal instance As BaseClass)
        instance.OrdinarySub()
    End Sub
End Module


' BaseClass impliments an overridable and ordinary method
Public Class BaseClass
    Public Overridable Sub OverridableSub()
        Console.WriteLine("   BaseClass.OverridableSub() called")
    End Sub
    Public Sub OrdinarySub()
        Console.WriteLine("   BaseClass.OrdinarySub() called")
    End Sub
End Class

' SubClass impliments an overriden BaseClass with overrides and shadows modifiers
Public Class SubClass
    Inherits BaseClass

    Public Overrides Sub OverridableSub()
        Console.WriteLine("   SubClass.OverridableSub() called")
    End Sub
    Public Shadows Sub OrdinarySub()
        Console.WriteLine("   SubClass.OrdinarySub() called")
    End Sub
End Class

What happens when we execute our code now?

+ Calling BaseClass Methods
--------------------------------------------------
   BaseClass.OverridableSub() called
   BaseClass.OrdinarySub() called

+ Calling SubClass Methods
--------------------------------------------------
   SubClass.OverridableSub() called
   SubClass.OrdinarySub() called

+ Calling SubClass Methods passed as BaseClass
--------------------------------------------------
   SubClass.OverridableSub() called
   BaseClass.OrdinarySub() called

Notice that we are passing the same instance into both methods. Both methods are accepting “BaseClass”, not “SubClass” as a parameter. Our results are completely different. For our OverridableSub, our SubClass method is still called even though we passed this in as a BaseClass instance. However, for our OrdinarySub that used the Shadows modifier, we are getting results from our BaseClass. That is because of some fundamentals in Object Oriented programming. When we override behavior, its overriden no matter how we pass the class to a parameter (with some exceptions made during type casting). However, when we override using the Shadows modifier, our old functionality is only “lurking in the shadows” — not completely overriden. Remember this when trying to override functionality that wasn’t designed to be overriden as such. Your Shadows modifier may help you out when calling against your SubClass, but not when executing against a BaseClass instance.