What if there was a NEW vb6

[MikiSoft]

I think it all depends on how one see the problem. Not sure if this will add something useful to it, but here's my view
Attachment 129309

You're certainly right about that. I like clean and simple, so your code to me is perfect (although perfect code doesn't exist, because as we know - it all depends on the observer).

I don't understand so much the OOP concept so that's why I'm not mentioning Olaf, but I can see that he's trying hard to explain something and that he knows the matter. All I can say to him and others is to keep writing, because this is interesting and I surely know more than earlier after reading these posts.

Quack!

[Schmidt]

I don't understand so much the OOP concept so that's why I'm not mentioning Olaf, ...

I was trying to follow the requirements Funky established in his example -
where he didn't use Properties (State) to describe the behaviour of a specific
Instantiation, but "Action-Methods" instead (his original method-signatures being):
- void Fly()
- void Quack()
- void Swim()
- void Display()

Which were appropriately translated into "Subs" in my VB6-example.

Olaf

[Carlos Rocha]

That might serve as a good example for what was mentioned
whilst discussing the pattern-book, further above:

"write simple code, then worry about patterns"

It was possible to do it in that simplified way, because - so far - you
were using only simple Properties (different State) in your Duck-Class-Instantiations.

But what when you need to introduce a "Method that requires action"
into your current scenario - as e.g.:

Sub RenderLandingParable(SomeGraphicsContext)
'...
End Sub

And each different Duck-Type then requiring a little bit different implementations
of that Method. (that's what the 4 behaviour-classes are covering in my example).

Olaf

What I did is a very simple kind of inheritance, with only properties. Extending the logic to methods depends on the language used and their capabilities.
For what I know about VB6 (very little) changing/adapting methods functionality could be done with Implements, but using some kind of "case statement" (like you did) seems also a valid option.
In the end it depends on where we prefer to add complexity: more classes vs. bigger methods.

EDIT: I confess I didn't see Funky sample

[Schmidt]

In the end it depends on where we prefer to add complexity: more classes vs. bigger methods.

Yep - and the way my example is constructed, it will allow both ways.
1) one Class per each possible behaviour (avoiding any Select Case in those Classes, but then requiring one in the Factory)
2) one single Class per "behaviour-method of cDuck" (then needing the Select Case in the Class, but avoiding it in the Factory)

I've decided in my implementation, to start with #2 above -
but I can switch at any time (without breaking outside interfaces) to go for #1 -
or even a mix of #1 and #2.

Olaf

[JackB]

Ducks are always a good examble.

Having nothing to do what the real problem is.
Leave the ducks alone. Demos with ducks are easy , but they are for the ducks.

The way that vb6 was superior IMHO , had nothing to do with oop or classess, or whatever.
You had a problem to solve , and if you could it to communicate it to the “beast” the problem was solved.
And magically , if you were right , the duck would be in your plate.

And beeing on topic.
Vb6 was an Apex predador in its times.
Now , it isn’t anymore.
Its successor never , NEVER was an apex predador.

No need to say that never will be.
So , to the 20-+30 somehow .net users that are only here and never elsewere , you can go and dead peacefuly

[Carlos Rocha]

Yep - and the way my example is constructed, it will allow both ways.
1) one Class per each possible behaviour (avoiding any Select Case in those Classes, but then requiring one in the Factory)
2) one single Class per "behaviour-method of cDuck" (then needing the Select Case in the Class, but avoiding it in the Factory)

I've decided in my implementation, to start with #2 above -
but I can switch at any time (without breaking outside interfaces) to go for #1 -
or even a mix of #1 and #2.

Olaf

hum...yes, your approach is interesting. I see now that you can change a behaviour by just changing his class implementation, like switching from Polka to Swing for all ducks in bDuckDance.
Maybe I'm just too much stuck in the inheritance world, so when I find similarities between objects I tend to think in a common master class with everything needed, and sub-classes to override the base implementation.

[Schmidt]

... I see now that you can change a behaviour by just changing his class implementation, like switching from Polka to Swing for all ducks in bDuckDance.

DuckDance, how nice <g>

Ok - let's use your idea, to demonstrate how the Factory could be used alternatively,
to change behaviours as well.

Let's for the moment assume that in your original Implementation, you already had
a Dance-Method in your cDuck-Class - and an appropriate behaviour-Class bDuckDance.

Since all the ducks you were asking this (astonishingly even the LeadenDuck),
agreed that: "Swing is the DuckDance we prefer..."
you entirely left out the Select Case from your initial Implementation of bDuckDance,
simply writing:

Option Explicit

Public Sub Dance(ByVal DuckType As enmDuckType)
  Debug.Print "  Swing is the DuckDance we prefer"
End Sub

You then rolled out your DuckApplication - but soon got complaints from Ducks in the
Czech-Republic, that "Swing is an affront, and Czech-Polka the only true DuckDance".

This time you decide, to not handle that with a Select Case in bDuckDance
(because all the Czech-Ducks were of one opinion once again - and you wanted
to demonstrate the flexibility of your nice Factory-Class anyways...

Instead you will implement the Polka-behaviour in an additional Class, which
is polymorph to bDuckDance (implementing its interface) and you name it bDuckDancePolka:

Option Explicit

Implements bDuckDance

Private Sub bDuckDance_Dance(ByVal DuckType As enmDuckType)
  Debug.Print "  Nah, Czech-Polka is the only true DuckDance"
End Sub

That's perhaps another example for something, many VB6-users (and perhaps even
more of the "early movers from VB6") are not aware of.

You can implement the interface of an already existing "non-virtual-class"
(a class which already contains implementation-code and does something useful)
anytime in VB6, in the way as shown above with bDuckDance and bDuckDancePolka.

The Factory is now responsible, to do the Switching between the two bDuckDance-
behaviour-Classes, depending on the current SystemLCID which is found.

Private Sub Class_Initialize()
'  SystemLCID = GetSystemDefaultLCID
  SystemLCID = 1029 '<- Czech-LCID ... just for testing - the line above is the true implementation
End Sub

Public Function CreateDuck(DuckType As enmDuckType) As cDuck
  Set CreateDuck = New cDuck
  
  Select Case SystemLCID
    Case 1029: CreateDuck.Init DuckType, oDuckFly, oDuckQuack, oDuckSwim, oDuckDisplay, oDuckDancePolka
    Case Else: CreateDuck.Init DuckType, oDuckFly, oDuckQuack, oDuckSwim, oDuckDisplay, oDuckDance
  End Select
End Function

Here's the full Source (in a new Zip, not touching the original-implementation I've posted earlier).
DucksDancing.zip

Olaf

[Schmidt]

The way that vb6 was superior IMHO, had nothing to do with oop or classess, or whatever.

That VB6 is "superior" is not true ...
Maybe in its RADishness compared to non-RAD-languages - but
not compared to .NET.

Though the opposite-direction (.NET being superior to VB6) is wrong as well
(when we talk about Win-Desktop-Apps, then VB6 holds its own quite nicely).

It's always developers and their knowledge *about* a certain tool,
which defines the final quality of a solution, not the tool itself
(when it's roughly comparable - as e.g. VB6 or VB.NET).

Postings like your last one (especially the last line you wrote) will do nothing
to increase the "level of positive recognition" for VB6 - just the opposite.

Olaf

[MikiSoft]

Tried to install today .NET Framework 3.5 on Windows Thin PC via default user account, and when I run setup it said that I must enable it thru "Turn Windows features on or off" option in Control Panel. I went there and I was greeted with a message that it is disabled by system administrator (which is reasonable since Thin PC is a limited Windows 7 edition). Great!

[szlamany]

Tried to install today .NET Framework 3.5 on Windows Thin PC via default user account, and when I run setup it said that I must enable it thru "Turn Windows features on or off" option in Control Panel. I went there and I was greeted with a message that it is disabled by system administrator (which is reasonable since Thin PC is a limited Windows 7 edition). Great!

Guess your IT department doesn't want people messing with the install configuration of their thin pc's.

[MikiSoft]

Guess your IT department doesn't want people messing with the install configuration of their thin pc's.

Unfortunately that's not the case - on Thin PC configuring Windows features is disabled by default.

[szlamany]

So then you can enable it right?

[MikiSoft]

Yeah but not via Control Panel: http://www.sevenforums.com/tutorials...e-disable.html
Tried with this hack and now it opens me a dialog for turning Windows features on/off, but it seems that it can't load them - it's currently stuck at "Please wait..." where Windows features should appear, so I'm still waiting...

[szlamany]

It has an intentionally small footprint and tied down access. When it was initially installed it should have asked what options and what not were to be allowed.

We use them in HIPAA scenario's where access to personal health information (making CD's and using in memory sticks) is government controlled.

[MikiSoft]

Maybe you're right, but personally I don't remember that it asked me when I was installing Thin PC whether that option will be enabled or not. And it displayed me now blank list in the dialog, so it's not working.

[Niya]

lol it was funny reading all that stuff about rubber duckies. People trying to fit a square peg in a round hole rofl. A full OO language will always solve the problem more cleanly that a partial OO language like VB6, no matter no much mental gymnastics you perform to prove otherwise.

[Tanner_H]

A full OO language will always solve the problem more cleanly that a partial OO language like VB6, no matter no much mental gymnastics you perform to prove otherwise.

I've been trying to avoid this thread, but I can't help it when garbage statements like this appear.

There are many programming paradigms. They all have purposes. OOP is a solution for some problems, not all.

For example, delegates, LINQ, lambdas, are all constructs of functional programming, not OOP. C# makes use of all of these to great effect, because it is a multi-paradigm language, just like VB6.

This is computer science 101, for hell's sake.

[FunkyDexter]

@KFCSmitty

While I'm not particularly a fan of the way Funky did it

Bear in mind that this wasn't meant to be a perfect implementation of a duck simulator, it was meant to be a demonstration of the Strategy Pattern. If I were writing a Duck Simulator the two obvious changes I'd have made would be to implement a factory pattern (and I'd have done it without coupling it to the concrete behaviours and ducks too... I'd probably have gone for a Factory Method pattern for the added flexibility but then I'd probably be accused of over-engineering) and I'd have exposed the behaviours as properties to allow for inversion of control and run time mutability.

I did mention that I'd recommend both these additions in my previous post but I think that may have been missed in some quarters.

I'd also have policed the addition of new behaviours (more on this below) but didn't think to mention that in my previous post.

@Olaf

Sorry, but it's an overengineered mess of too many Classes in a wrongly choosen Pattern.

Wow, blanket unsubstantiated insults and poor spelling all rolled into one groundless sentence. You go, girl.

I'm really sorry you were unable to understand the strategy pattern. I suspect that's because, as a VB6 user, you are unlikely to have encountered a heavily complex inheritance tree because, of course, VB6 wouldn't support it in the first place. None the less, here's a few links that might help you get there.

I predicted you'd end up using a big switch ("I'm willing to bet I'll see a pretty chunky Case or If statement appearing somewhere.") and I'm afraid KFC Smitty is 100% right about it's impact on maintainability. It's a well known anti pattern. It makes your code less maintainable and less testable. Here's a good thread on Stack Overflow that covers a lot of the issues and here are the recommendations Google gives to it's developers, read point 8.

The testability issue comes down to the fact that your individual behaviours cannot be tested in isolation. Neither can your ducks. Your ducks are tightly coupled to your behaviours because you coded to an implementation instead of coding to an interface and you duck behaviours are tightly coupled to your duck factory because they depend on the duck type enumeration.

The maintainability comes from the fact that your duck class is closed to extension. In other words, to add a new kind of duck you need to open the base duck class. That has a number of implications:-
1. A third party developer cannot take your compiled assembly and implement their own types of duck. They would need to amend your source code to do that.
2. Because you need to amend your base class to introduce a new duck you've introduced risk that they will destabilise your existing code.
3. The sorts of mistakes they're likely to make (i.e. adding a new duck and failing to update a switch in a behaviour class) will not manifest itself until run time and then it will manifest as incorrect behaviour rather than an error.

In all honesty, that code's going to get thrown out of any professional peer review it turns up in.

You did mention that you felt my approach would be less maintainable when adding new behaviours. As your approach requires that the factory and duck classes both need to be amended as well as the new behaviour class added I would argue that they're roughly equal, at least with my implementation as it currently stands.However, as I mentioned previously, my implementation was only ever meant to be a demonstration of the Strategy pattern, not a prefect Duck simulator. And were I implementing the perfect duck simulator I'd have policed the addition new behaviours. It's quite easy to do if you know your OO principles. Here's how:-
Add abstract setter methods to the abstract Duck Base Class. E.g:-

public abstract SetQuackBehaviour(iQuackBehaviour quackBehaviour)

Now the first thing you'll do when adding a new behaviour is add a new abstract setter to the base class and voila, the compiler will immediately highlight any derived concrete classes that have failed to set that new behaviour. No chance of shipping dodgy code because it's all policed at compile time and the ide will let you navigate to every change you need to make with a double click on the errors list.

And the reason I can police that so easily? Because I coded to an interface, not to an implementation. VB6 has interfaces so you'll know all about that.

So just to summarise, I said this:-
"I'm willing to bet you won't be able to without either violating the DRY principle or increasing the coupling between the classes. I'm willing to bet I'll see a pretty chunky Case or If statement appearing somewhere."

You've increased the coupling and introduced not one but many chunky case statements. 2 outa 3 aint bad


Edit> I see from post 767 that Olaf is also now veering toward a Factory Method Pattern too (albeit still strongly coupled to the factory which is a shame), so maybe I'd have got that through without being accused of over-engineering.

[dilettante]

Some people will never grasp the difference between the "short pants polymorphism" provided by inheritance and the "long pants" version provided by interfaces.

[FunkyDexter]

Some people will never grasp the difference between the "short pants polymorphism" provided by inheritance and the "long pants" version provided by interfaces.

To be fair they're both useful. And many of the techniques to favour composition (which is what I think you'd call "long pants polymorphism") do require implementation inheritance at some point to implement properly.

[szlamany]

@funky - great read - thanks! Also - good links - good stuff!

[Niya]

I've been trying to avoid this thread, but I can't help it when garbage statements like this appear.

There are many programming paradigms. They all have purposes. OOP is a solution for some problems, not all.

For example, delegates, LINQ, lambdas, are all constructs of functional programming, not OOP. C# makes use of all of these to great effect, because it is a multi-paradigm language, just like VB6.

This is computer science 101, for hell's sake.

Yes you can avoid OO entirely and come up with something clean using only functions if you wanted. But its futile to pretend that VB6 can solve this with some jerry rigged wannabe OO mess better than a language with more powerful OO implementations like JavaScript, or C++. If I were doing this in VB6, I wouldn't even be thinking in OO terms to solve this rubber ducky business. I'd probably use bit fields and a single class with all of the implementation for all the types of ducks. The bit field would specify what the duck can and cannot do. I wouldn't go with all that over engineered mess with class factories and all that nonsense in VB6. That's just asking for a world of hurt.

VB6 is not a proper OO language.

[Tanner_H]

VB6 is not a proper OO language.

Neither is C, Go, Haskell, MATLAB, or about a thousand other languages.

I guess none of them can solve problems "cleanly", because according to you, "a full OO language will always solve the problem more cleanly than a partial OO language."

[kfcSmitty]

Nope, my example is better maintainable - I mean, we have two "original Zips" out there, right?
- the one I've posted: http://www.vbforums.com/attachment.p...9&d=1439745837
- the one Funky posted: http://www.vbforums.com/attachment.p...7&d=1439717133

So, the needed maintenance-efforts can be measured quite nicely: -> please extend Funkys example about:
- the DuckType 'RedHead'
- introduce the new Property 'NursesYoung'
Then post the Diff to his original example-Zip - and I will happily post the Diff to my own implementation.

Funky's won't open for me, but a few more lines does not make it less maintainable. We could do the opposite: have a bunch of ducks already in the system and properties set, and then modify which ones fly. Instead of modifying the ducks themselves, you're again, going into core code and there then comes the possibility of screwing up your if statement. God forbid you have the property specified twice in the large if statement you could have and you only changed one instance of it. Especially if you have more than an "if/else". I don't care if you want to put your fingers in your ears and go "No I'm not!," it is a simple fact you are. If you wrote a web form handling user input, would you have

if first_name then
else if last_name then
else if email then
else if address then
else
end if

? Of course not, that is absolutely ridiculous, yet with what you've said, that is a "behaviour class" because it is handling the behaviour of the form.

You're wrong also on that account...
Again the task:
- enhance Funkys example, to do "categorizations of 100 additional DuckTypes"
(god, what a mess that would make, defining all these new "specific Classes" in a Dll)
but do so, and I will post the differences, my example would require, as well).

Wow, you're 100% focused on the amount of lines of code, eh? Maintainability != # of lines of code. If everyone thought like you, there would be no such this as dependency injection. I would much rather write an interface for every service I implement so I can fake it out for my unit tests and write proper integration tests, than have one class and have to override everything for testing. A million times so if DI is involved!

Having individual classes for each duck and having one place to modify these is a lot more intuitive than having to go into x number of classes to set the properties of the duck. If doing the opposite was more intuitive, why would properties on a class even exist? Everything could just be a method that calls a method from one of your behaviour classes.

<Cleaned up by mod>

PS: Sorry to any mod who may need to clean this up... I tried to tame it down as to not violate any conditions.

[FunkyDexter]

I guess none of them can solve problems "cleanly", because according to you, "a full OO language will always solve the problem more cleanly than a partial OO language."

I don't think Niya's saying VB6 cannot solve the problem cleanly. Rather he's saying that it won't be clean if you try an solve it in an OO way. If you stick to a procedural approach VB6 would do a just fine.

[FunkyDexter]

Sorry to any mod who may need to clean this up

I have cleaned up some of it but I can fully appreciate your frustration. Olaf has been extremely condescending in this thread but, to be fair, so have I. And as a mod I really ought to know better.

So here's the deal. Olaf, I won't condescend to you but you, in turn, need to stop condescending to others. If I see a problem with your approach I'll point it out but will do so as politely as possible. I expect you to extend the same courtesy to others.

And it's not just Olaf and I that this applies to, we're just the worst recent culprits. We should all be talking to each other civilly and trying to learn from each other. Learning requires admitting your own ignorance and that is near impossible to do if your pretty sure someone just going to try and humiliate you for it.

And may I apologise to everyone if I've shown a lack of grace.

[Tanner_H]

I don't think Niya's saying VB6 cannot solve the problem cleanly. Rather he's saying that it won't be clean if you try an solve it in an OO way. If you stick to a procedural approach VB6 would do a just fine.

That would make a lot more sense! Niya, my apologies if I misunderstood.

I was just hoping to make the point that OOP is not the only way to approach all programming problems. Imperative programming has been used to solve a lot of insanely complex programs (e.g. the Linux kernel), while other paradigms like functional programming nicely tackle a whole other set of problems.

Multi-paradigm languages all have trade-offs. (If they didn't, we'd have "one master language to rule them all".) At the risk of incurring Olaf's wrath, I too find Funky's solution more elegant, but that could just be because I find OOP very intuitive for the "problem" he originally described.

I think one of the interesting things about this thread (which has gotten markedly better over the past 30 posts - thanks to Funky in particular for kickstarting a great discussion!) is that the "cleanest" approach to a problem is going to vary based on your familiarity with a given tool/paradigm.

This happens to me all the time with functional programming. I look at something like Haskell code, which can do so much with so little, but wow, it is really hard for me to wrap my head around that problem-solving approach. 10x more lines of an OOP or imperative solution is easier for me, and even though it's less terse, I agree with kfcSmitty's great point that Maintainability != # LoC.

[Sitten Spynne]

I'm pleased as punch with the direction we're taking now, real knock-down drag-out fights over how to implement a problem! It's a shame I don't have a copy of VB6 to read most of the code, but I can kind of follow along because this particular problem's familiar. But first, some comments.

Was VB6 taught in colleges 20 years ago?

I learned squat about writing *good* code in college. College taught me how to write functional code. It was only after I left and started mingling with other professionals that I started figuring out there were reliable practices that led to better code overall. I found more professionals with that focus outside of the VB community than inside. Inside of the VB community I encountered more people who resisted those ideas. IMO, everyone is self-taught because I've yet to see a college with something I'd call a true software engineering program. 4 years is barely enough to scratch the surface.

But its not symmetrical. I don’t see any vb6er comment about what the “others” have to do...

This is something I can work with way better than the earlier sarcasm.

VB6ers don't comment on where the .NET devs should go (well, they do, but the destination's not polite...) because if you're a VB6 dev and VB6 is the only language you use, you're going to suggest VB6. And we know where that ends up.

In 2008 or so, if you knew C# and did WinForms, you got a lot of pressure to move to WPF. If you moved to WPF, you got a lot of pressure to give Silverlight a try. Then WinPhone. And so on. I saw a ton of people jump ship to Ruby/Obj-C, and code meetups that used to have a lot of discussion about Windows turned into me sitting by myself while everyone else talked about iOS and Rails. It stunk. I bet this is what being a VB6 dev felt like, and still feels like.

But as I survey the world right now, I see C# everywhere. It's on Mac, Linux, iOS, Android, Windows... If you know a little WinForms and a little XAML, there's no UI platform that's alien to you. I don't write Windows clients anymore, I write iOS/Android apps with C#. It was an easy transition, because all the skills built on one another.

VB6 is much harder to jump fences from. It runs... on Windows. The easiest move is "writing WinForms clients", but why invest so much effort to do the same thing it already does? The only benefit is you get more familiar with .NET concepts, but ultimately the route is to learn C#, touch some XAML, then find what looks exciting to you. That implies that you want to shift your career at some point. I'm starting to realize a lot of people don't. Personally, I think VB6 is a bad bet over the next 10 years, but I'm pretty sure the current crop of VB6 devs is well aware of that and quite happy with the risks. There's more productive uses of my time than hassling them, and I wish more .NET developers held that opinion.

Post #753

I'm on board, if I find time to devote to it I'd love to have more discussions like this, very much so. It's a heck of a lot more productive than writing posts like this one. Lately I find I enjoy writing that kind of thing in C# more than VB and that makes me a bit of a leper to some people

Maybe I'll start with a series on SOLID, it segues real nice into the stuff Head-First Design Patterns did.

(continuing ducks problem)
I think it's getting kind of muddled. This example in terms of Head-First Design Patterns was a zoo, which included penguins, flying fish, and peacocks to have every possible combination of bird/not-bird, swimming/sinking, and flying/earthbound in addition to "every creature makes a different noise". Being limited to just ducks makes the prospects of using more complex patterns less desirable. It also feels like maybe each person's adding/modifying requirements, this kind of discussion's best if it starts with a formal problem definition and you lose points for solving problems that aren't present in the definition. "YAGNI" is a valid pattern

Discussion advice via storytime: One time, long ago, I made the mistake of leaving a bad review on a book I had to read in high school that I felt failed at most of the things it tried to do. I attracted the ire of a ton of bibliophiles, but one stood out. After several ad hominems, he closed with a statement like, "I want you to write a five thousand word essay about post-modernism, and how <author> was influenced by <her childhood or something> and where this book fits in the context of <some other literary movement.>" He probably felt really smart, as if he were backing me into a corner in which I'd have to admit I had no literary analysis skills. Instead, I replied, "I'm not going to do your homework for you, I've got my own essay to write." I think I won, I owed him nothing. Had I wrote the essay, he'd have either ignored it or picked it apart for any tiny subjective opinion I injected. It wasn't worth my time.

No one ever owes you a demonstration. The argument form "Please <implement a complex project> showing this." is not an argument, it's a request for free work. I wouldn't answer a newbie question that made zero efforts, and I certainly won't spend time dealing with a complex OO topic if I think my efforts will be met with a hearty criticism. Here's an idea: you implement the technique you're sure is wrong, then criticize your own work and invite the other person to show you your flaws. Since trying this technique, I've found plenty of scenarios where halfway through my rebuttal I realize I actually started agreeing with the person's suggestion, or at least I could see some benefits. Get out of the habit of thinking there's a "right" answer to design topics. See them as difficult comparisons between several solutions, all with pros and cons. We don't get points for proving other people are wrong, we get points for helping each other learn new things.

In conclusion, here's a library I propose every developer should read through/strive to possess. You're going to have to learn some C# to read most of these, and occasionally Java. It won't kill you, and it's very rare to find a book that uses VB for these topics. It will make you stronger to apply these techniques to your VB.

• The Art of Unit Testing (Roy Osherove) - If you aren't writing automated tests for your code, you may as well not be bothering with any of the other resources. Most of the reason you want to modularize your code and use patterns is to facilitate tests. This is the only entry-level testing book I know, and it's likely the only one you need.
• The SOLID principles are the basis of testable design. It takes a long time for them to sink in. Just read them, and come back to them every now and then, re-reading the articles as you learn more tricks. When I first read them, I only agreed with a few points. Now, I ask why they were never obvious before.
• Working Effectively with Legacy Code (Michael Feathers) - "Legacy Code" in this case is "anything without unit tests" or, more appropriately, "any code without a provable definition of its behavior". This book is about safe techniques for isolating legacy code and slowly refactoring it so that it can be tested. As such, it's the only resource that shows you "bad" functional code and how it is expressed as "good" testable code. I bet 90% of you only have "legacy" code to work with, so it's a gem for you.
• Head-First Design Patterns (Freeman & Bates) - After you read TAoUT, this is a great way to learn more tricks for isolating chunks of code from each other to facilitate testing. It's far more approachable than the denser pattern texts, but definitely nowhere near as complete.
• Clean Code (Bob Martin) - This is short, sweet, and will feel very familiar after the previous two. Uncle Bob narrowed in on the fundamentals of testable design before anyone realized what it was.
• Code Complete [really long title] (McConnell) - This book is language-agnostic enough to contain some examples in VB. It is a nuts-and-bolts guide to trying to write more readable code, less focused on project architecture than it is on statements at the level of while loops. It's still incredibly valuable, and discusses readability tricks that'll make you smile.

Add to that list anything by the authors in that list. Fowler & Martin are particularly well-known and have written many books. They're also associated with agile circles, which may or may not turn your stomach, but we can cut big bits of "agile" out of that methodology and still be left with a great process for writing maintainable code that proves it operates correctly. You don't have to be getting a paycheck for that to make your life happier.

Where's the reference texts like Gang of Four? They don't make good reads. It's a lot faster to describe your problem to others and ask how they'd solve it, then look up any patterns they mention. I want them on my shelf, but most of the information's somewhere online as well.

Also I'm still kind of mad to see people bickering about whether having OO features makes the language good or not. It's not a discussion. If you think a language is generally better or worse based solely on having OO features, you are wrong. We can narrow the context to, "Well by not having THIS implementation, it can't solve some problems well..." but it is very rare to find a language that is just all-around bad for all solutions outside of esoteric languages like lolcats. If you want to have that discussion, I'm going to be the guy who tells you nothing is ever as elegant as LISP.

And the last thing we want is to attract the attention of a LISP evangelist.

[Niya]

I don't think Niya's saying VB6 cannot solve the problem cleanly. Rather he's saying that it won't be clean if you try an solve it in an OO way. If you stick to a procedural approach VB6 would do a just fine.

Yep...that's exactly what I'm saying. Doing otherwise is like I said, trying to fit a square peg in a round hole.

[szlamany]

Was VB6 taught in colleges 20 years ago?

I learned squat about writing *good* code in college. College taught me how to write functional code. It was only after I left and started mingling with other professionals that I started figuring out there were reliable practices that led to better code overall. I found more professionals with that focus outside of the VB community than inside. Inside of the VB community I encountered more people who resisted those ideas. IMO, everyone is self-taught because I've yet to see a college with something I'd call a true software engineering program. 4 years is barely enough to scratch the surface.

You paraphrased me a bit - I said this

I assumed that lots of the VB6 crowd was self taught - hasn't that been a point in these past few posts?

Was VB6 taught in colleges 20 years ago?

and it was in response to Schmidt going off on self-taught and/or self-employed people.

I've been coding since the 1970's (both employed, self-employed and partnered with others) - I have no idea what is taught in colleges today. I would hope it's C-syntax and Java and Ruby and all the other languages I get emails from head hunters about.

If I was going to hire a college coder today I would be more interested in what they have done with maybe C++ or some other way to see the real problem solver / logical thinker they are.

If I had any time I would have worked up some JavaScript duckie classes

[Schmidt]

Sorry, but it's an overengineered mess of too many Classes in a wrongly choosen Pattern.

@Olaf
Wow, blanket unsubstantiated insults and poor spelling all rolled into one groundless sentence. You go, girl.

As for poor spelling - I'm always interested to better my english - and wouldn't mind
(although pointing out spelling-mistakes is considered quite rude under the rules of
general netiquette) when you'd just point out the mistakes I made in my sentence...

As for "unsubstantiated insults" - what if I'm right?

If you think I'm wrong, then I'll ask you basically the same as I've asked kfcSmitty already:
Please extend your original-example:
- about the DuckTypes 'Redhead', 'Canvasback', 'Hardhead' and 'LeadenDuck' (the latter one sinking instead of swimming)
- change your Display-handling to be able to read the Description of the DuckType in question from a Resource-table
Then post the resulting differences in code.

I will post my VB6-code-differences after applying the same enhancements to my implementation.

Then let's compare notes, which of the two versions is "a mess" and which one was
easier to maintain.

To the VB6er and .NETers who might be wondering why I'm asking for this so adamantly...
The outcome will be in favour of the VB6-version (by miles and bounds) - that's why
any such request was (so far) ignored.

My guess is, that we will see more of the same - which is kind of sad -
since "in code is truth".

I'm really sorry you were unable to understand the strategy pattern.

That's an assumption (and an insult by the way) - and I see that you claimed in further
postings of yours, that my behaviour is "condescending" towards others.

I'll ask you this (again) - what if I'm correct? What if the diffs you will
produce clearly show, that I was right all along? Is telling the truth in
a forum for technicians (where NewComers could be easily misled, when stuff
remains uncorrected and unwithspoken) now considerd "condescending"?

Consider this Funky. Patterns are there to be applied to a certain scenario, which
when applied *correctly*, will offer advantages over the alternatives, right?

If only *one single example exists*, which implements the same scenario better,
then either the pattern was a useless one - or it was wrongly applied.

For the sake of the OO-Purists I will state, that the strategy-pattern is
*not* a useless one - but now, who was it exactly, who applied it wrongly?
Not me (I've applied a different, more efficient pattern to the scenario).

So, how would *you* characterize somebody who couldn't come up with an ideally matching
example-scenario, to demonstrate the advantages of a given pattern *very* convincingly?

Could it be, that this person didn't really understand the *pattern* (and where
to apply with an ideal outcome) in the first place?

...you are unlikely to have encountered a heavily complex inheritance tree

Absolutely, because I actively *avoid* "heavily complex Class-hierarchies"
(they are considered "bad OO", you know).

I predicted you'd end up using a big switch ("I'm willing to bet I'll see a pretty chunky Case or If statement appearing somewhere.") and I'm afraid KFC Smitty is 100% right about it's impact on maintainability. It's a well known anti pattern. It makes your code less maintainable and less testable. Here's a good thread on Stack Overflow that covers a lot of the issues and here are the recommendations Google gives to it's developers, read point 8.

A Select Case has its place in programming (otherwise switch-constructs would not exist).
To apply the proper mix is the key - besides - if my Case-Switching would have become
a truly unmanagable one (which it so far definitely isn't) - my design allows also for
behaviour-Classes which are dedicated to a single case - but I've explained that already.

The testability issue comes down to the fact that your individual behaviours cannot be tested in isolation. Neither can your ducks.

Not sure how you do *your* tests, but I would test *all* of my Ducks for the correct behaviour.
I could do that for each behaviour separately - or for all behaviours at once (the Form-Code I've
provided in my Demo, did that already - listing all behaviours "visually" for all current ducks) -
but if you want, I can show you dedicated TDD-sequences, implemented in a cTestBehaviours-Class -
there's TDD-HelperTools for VB6 which ease the formulation of these a great deal).

Your ducks are tightly coupled to your behaviours because you coded to an implementation instead of coding to an interface

Coding to an implementation in VB6 is the same as coding against an interface.

I've explained the mechanism already whilst showing dedicated single behaviours
(without any Select Case) - in the DuckDance-scenario a few posts above.

and you duck behaviours are tightly coupled to your duck factory because they depend on the duck type enumeration.

Nope, they are not.

In VB6 I can produce a TypeLib (in case the Duck-Classes and Duck-behaviours were sitting in
a COM-Dll-Project) with a single MouseClick on one of the CompileDialog-Options of that Dll.

And then - in case I'm interested in outsourcing the implementation of the "standard-swim-
behaviour" of my ducks, (currently implemented in the default-swim-behaviour-Class bDuckSwim)
to a chinese facility, where the discovery of a "quite large QuickSilver-Puddle" was reported -
I could send that TypeLib to somebody "on-site" - along with the request, to check this Typelib
into a new VB6-Dll-Project - and implement the interface of Class bDuckSwim in a new
bDuckSwimOnQuickSilver-Class of that "Plugin-Dll" - then testing (isolated) the behaviour
of all Ducks (espacially the leaden one) against this new implementation in the
bDuckSwimOnQuickSilver-Class.

And back the Dll is sent to me - and I can use it from within my Factory-Class
without the need to break any existing interface of my DuckBase.dll.

The maintainability comes from the fact that your duck class is closed to extension.

You are wrong.
Please give an example for such an extension as a clearly formulated change-request.
After that let the both of us implement that request and compare notes - it really is that simple.

In other words, to add a new kind of duck you need to open the base duck class.

No, I will not have to do that - formulate what you mean as a concrete change-request
to *both* our base-implementations - and then we compare notes.

In all honesty, that code's going to get thrown out of any professional peer review it turns up in.

No, any *professional* developer would disagree with you.

It would be your design which would be dismissed outright by a truly experienced authority
(who really knows what VB6 allows and what not).

You did mention that you felt my approach would be less maintainable when adding new behaviours.
As your approach requires that the factory and duck classes both need to be amended as well as the
new behaviour class added I would argue that they're roughly equal, ...

Just post the code-differences for the change-requests, I've nicely asked you to apply
at the top of this posting - and then let's compare that.

And the reason I can police that so easily? Because I coded to an interface,
not to an implementation. VB6 has interfaces so you'll know all about that.

Sure, I know all about that - but what you still don't really grasp is, that
any "non-virtual-base-class" in VB6 can serve as the interface-provider to
future implementations of polymorphic derivates which implement that thing.

I was following KISS in my first throw - and even *whilst* doing so, my example
is the more flexible one for the scenario by miles and bounds - it is in no
way "tightly coupled" as you claim - since it allows plugin-like and outsourced
behaviour-development from the start (in two different ways - standalone
behaviour-classes or Select Case based ones which allow easy "grouping").

Your turn again - and please provide the Diffs I asked you for, so that everyone
can draw his own conclusions from the results.

Olaf

[Schmidt]

The argument form "Please <implement a complex project> showing this." is not an argument, it's a request for free work.

Well, that's not a one-sided thing - it's "requests for free work" for all developers who'd participate
(for the sake of the community, which would surely benefit from the different code-bases and approaches -
when all try to implement the very same thing).

It's a well-known approach nobody who really cares about "the increase of knowledge"
in a given community would advice against.

One of the most wellknown sites for that kind of thing is:
http://rosettacode.org/wiki/Rosetta_Code

Here a comparison of different js-Frameworks, all offering implementations for the same project-task.
http://todomvc.com/

We don't get points for proving other people are wrong, we get points for helping each other learn new things.

How is it helping other people to learn new things, when claims are made which don't
hold up to reality - and one leaves them unwithspoken?

As an example might serve: "Creationism".

When this stuff is taught at schools (I mean, the kids will surely get "great help to learn wondrous
new things") - how can this be considered a thing to "give points for", when those kids later
realize that most of these new things they learned, were a waste of time and for the most part
just plain wrong?

Olaf

[Schmidt]

Funky's won't open for me, but a few more lines does not make it less maintainable. We could do the opposite: have a bunch of ducks already in the system and properties set, and then modify which ones fly. Instead of modifying the ducks themselves, you're again, going into core code and there then comes the possibility of screwing up your if statement.

How is that different from "screwing up the things you write into the core-code of the specific-duck-class")
But I'm repeating myself here.

God forbid you have the property specified twice in the large

You didn't even read or understand my example, when you write about "the property".

As it is implemented in my behaviour-classes currently, each of the 4 behaviour-classes
is directly representing, what you call "a property" (which is not really a property,
but a function BTW, which is a very different thing in the given scenario). Each of the
current Methods of the cDuck-Class maps to a single behaviour-class.

And what finally comes in over a parameter into these behaviour-classes, is again -
*not a property* - it's the DuckType itself (think: DuckID As Int if you want,
meaning: my example could be easily enhanced without changing the outside interface,
to work in conjunction with a "Ducks-Table" in a DB, where thousands of different Ducks
might be hosted, each having a unique ID - an ID which I could easily introduce in favour
of to the Enum-Value, which I preferred to work with to keep the example simple in my first throw).

Funkys example does *not* offer this possibility - and you cannot seriously tell me, that
you would implement thousands of specific duck-classes, when my next change-request
asks, to extend the example to this amount of ducks.

But also *that* was already mentioned in a previous post - though is still not recognized.

if statement you could have and you only changed one instance of it. Especially if you have more than an "if/else". I don't care if you want to put your fingers in your ears and go "No I'm not!," it is a simple fact you are. If you wrote a web form handling user input, would you have

if first_name then
else if last_name then
else if email then
else if address then
else
end if

Again, pure ignorance, not even seriously looking at what I did in my implementation.
I repeat: I was *not* checking any Properties in my behaviour-classes (as you try to suggest
here with your little if-construct).

Wow, you're 100% focused on the amount of lines of code, eh? Maintainability != # of lines of code.
If everyone thought like you, there would be no such this as dependency injection.

Give an example for a concrete dependency-injection for Funkys example - and I will show you that
I can do so as well (if not easier) in my example. It's really tiring - the solution to all that endless
bickering could be so damn easy, when we would concentrate on the "give-proof-by-code"-
pattern for a change.


Olaf

[Schmidt]

At the risk of incurring Olaf's wrath, I too find Funky's solution more elegant,
but that could just be because I find OOP very intuitive for the "problem" he originally described.

Well, not sure why my responses always seem to be recognized as "coming-out-of-the-wrath-corner" -
I'm just passionate in defending my position - with good arguments I think - and with reasonable
and logic requests - or simple questions, when points of disagreement were reached.

So, what's your opinion on demanding difference-code from Funky and me as well of course,
to some change-requests we would both have to apply on our initial examples?

I'm quite sure, that only a few have understood my example fully so far - and those
diffs would simply prove how flexible it really is.

And to write it up again:
When sombody explains the advantages of a certain pattern - especially when mentioning this kind
of pattern as "impossible to do in VB6" - is it not reasonable for me to assume, that the example which
is then used to demonstrate this allegedly superior pattern, was a well choosen one - demonstrating
the best of the pattern?

But when this pattern "gets a beating" by a simple combination of Composition and Factory -
why does Funky not say: "Sorry my example was not well thought out to demonstrate Strategy -
here's a better example - now beat that!"

Maybe he will do so still - but his line of reasoning was - please remember:
You will not be able to ever achieve the maintainability "true OOP" has to offer.

If that's true - why was he not able to offer an example which *decisively* proves that?

As for Maintainability != LOC ... that's true - but LOC is at least a good indicator (for starters)...
another indicator is, how extensible something was designed, without the need to break
interfaces - another one being - how many different classes were affected to cover a single
change-request.

Olaf

[Sitten Spynne]

It's OK to say "prove it", but more fun to try proving it yourself. Try it sometime. I find it much more satisfying to implement the "problem" and talk it out. Half the time I realize it's either not as bad as I thought, or that I was wrong. But folding your arms and putting all the burden of proof on the other person is a good way to make them not want to reply. The "winner" of this kind of argument is the one that stops posting first.

I've lost track of the original projects, or I'd dig them up and try to comment on them myself. It's dangerous work, because I don't have a lot of technical knowledge surrounding VB6 and how people implemented extensibility in it.

But the ducks example, like the zoo example on which it is based, is a trap for newbie OO developers. It is a situation that quickly escalates into one that creates the kind of mess that inheritance solves poorly. But to believe that, you have to be of the school of thought that this kind of method implementation is a sin:

Public Overrides Sub Fly()
    Throw New NotSupportedException("This kind of duck doesn't fly, it's a decoy.")
End Sub

I subscribe to this school. I'm shedding the VB syntax so I can be freeer in this non-code editor. If we have a base class Duck:

class Duck
    virtual void Quack()
    virtual void Fly()

Then all ducks must do something reasonable when I ask them to quack or fly. This has to hold because I want to be able to write code like this:

foreach duck in ducks:
    duck.Fly()

But if I decide some ducks can't fly, then I have to change my implementations to be ready for NotSupportedException:

foreach duck in ducks:
    try:
        duck.Fly()
    catch NotSupportedException ex
        ' do nothing

I don't like this. Exceptions are for exceptional cases, and there's nothing exceptional about some ducks not flying. That implies that Duck, as a base class, should not have a Fly() method. If we take that logic further, it turns out the same argument says we shouldn't have Quack(), either. So what's the point of a Duck base class with no methods? Good question. Maybe we don't need one. So how do we get a list of all ducks AND call their Quack() or Fly() methods if we don't have a common base class? You ought to be able to think of quite a few ways.

For this problem I favor extensibility by composition and interfaces. I can make an Animal base class with the scant few behaviors that are common for all animals, which depending on the way the example goes might just be properties for name, size, weight, etc. Now, I do want to differentiate by species and maybe other things, so we can have a Species enumeration. If we expect to have thousands of species, that's very impractical for extensibility, so in that case I'd just use string names set up in a configuration file. We'll use an enumeration, because we've got Ducks and Kangaroos in our zoo and a 2-item enum is quite manageable.

enum Species:
  Kangaroo,
  Duck

class Animal:
  int Weight;
  string Name;
  Species Species;

Right. So you're rolling your eyes and wondering how we make an Animal fly. Well. It starts with an interface:

interface ICanFly
  void Fly();

Now, we could make a Duck base class that implements ICanFly, but then we've just added a layer of indirection to the inheritance solution. We can't have a Duck base class. But we can make some derived Animals:

class GreenheadDuck
  inherits Animal
  implements ICanFly

  void Fly():
    Console.WriteLine("{0} is flying!", Name);

class DecoyDuck
  inherits Animal ' Questionable, but required

Now I fully support Liskov Substitution Principle: every Animal has the same behavior. That makes it inherently safe for me to make something like this method definition to load all my animals from the complex zoo simulator database, or a test method that just spits out a few:

Public Function LoadAnimals() As Animal()

So what if I want all ducks? Or what if I want to make just all ducks fly? I don't feel like going into all the details, but given some array of all animals, VB .NET's got facilities to let me write helper methods like the following without modifying the Animal or Duck classes:

ducks As Animal() = allAnimals.WithSpecies(Species.Duck)
flyingDucks As ICanFly = ducks.ThatCanFly()
flyingDucks.ForEach(duck => duck.Fly())

"Fine", you say, "but what if you want a default duck flying behavior?" That's composition, friend.

class DuckFlyingBehavior
  void Fly(Animal duck):
    Console.Writeline("{0} is flying!", duck.Name);

class GreenheadDuck
  inherits Animal
  implements ICanFly

  new():
    _flyBehavior = new DuckFlyingBehavior(Me)

  void Fly():
    _flyBehavior.Fly()

Now, if I want to add new behaviors, I don't have to go checking every base class. I do have to go checking every animal implementation. That can be a pain. VS has a cool code generator that'd let me write a quick parser that generates all that code from a text file, and if I had more than 5 or 6 species and 4 or 5 behaviors I'd definitely consider it. It'd have lines like this:

CreateAnimal("Sparrow").WithSpecies("Bird").ThatCanFly().ThatCanChirpWithSpecialBehavior()

It could easily be smart enough to look for a class named "SparrowChirpBehavior" and wire it up in Sparrow's generated class. Fancy. I've done this once or twice. No examples because I've already run long and the syntax is something I can never quite commit to memory, but it's a fun form of dark arts.

Now, OK, what if you don't think that method implementation is a sin? Then you get to use inheritance. You can sort of address this with the "Optional Feature Pattern":

class Duck
  inherits Animal
  
  public virtual bool CanFly { get { return true; } }
  public virtual void Fly() { Console.WriteLine(...) }

It's a little bit messier, but you can still write code that does fun things like:

airShow = allAnimals.OfSpecies("Bird").ThatCanFly()
airShow.ForEach(bird => bird.Fly())

It doesn't handle cases like flying fish or flying squirrels well, though. You have to remember that there's some non-birds that fly. If you have ICanFly, that's a lot easier.

I don't think either's better, but some lead to more trouble down the road depending on just how big your zoo gets. You should do what's easiest and solves the problem now, then when it gets unmanageable do the next most complicated thing that solves the new problems elegantly.

You can call it overengineered, but I'd like to see a version of "all animals that can fly should fly" with inheritance alone that can respect squirrels and flying fish. Multiple inheritance can do it, but it comes with its own concerns and you can't convince me VB6 has multiple inheritance. Here's my implementation of "all animals that can fly should fly" because it's already implemented in my language of choice, here's a call:

foreach (var flyingAnimal in allAnimals.OfType<ICanFly>()) {
  flyingAnimal.Fly()
}

First class functions are cute. It could be done on one line, but I like my foreach statements like I like my loud music: explicit. That loop will extract all ducks, birds (but not penguins or peacocks!), flying squirrels, and flying fish and make them fly. When I implement a new animal, I don't have to think about anything but what it can do, and I only have to implement the behaviors it needs. If it happens to share a behavior, I can extract that to classes and use composition. No one outside of that class will ever know, unless I choose to go the full-tilt Inversion of Control route, which is a testability consideration and a ridiculous boon for extensibility.

So yeah, that's how I think you ask for an implementation. Welcome to programming, where I'll tell you "never test in production" until the moment I reach a process so convoluted I can deploy a new version days faster than firing up a test instance. We have schedules to meet, and deliveries to make. Sometimes we bend our own rules and hope we have time to clean up the messes.

I'm sure you can come up with something, it's never impossible. I don't know enough VB6 to pull it off, and I think any inheritance-based solution will have to resort to dirty tricks if it wants to implement this feature. I sure as heck don't want to try a C# version with class inheritance. But this is just me being mean: no one's proposed that feature yet, we don't know if it's really needed. But it makes a heck of a case for interface-based inheritance instead of class-based inheritance as a tool for managing what would otherwise be extremely gnarly.

That is why the zoo problem is one you give green developers. To teach them why inheritance is but one tool on the belt. It is much like the "change" problem, which teaches them to fear floating-point math. You don't really have to defend your approach. This problem was crafted to be one that inheritance can't deal with. I'd use your approach on a small project with a well-defined set of critters that don't have problems like flying squirrels to deal with. And if I happen to know peacocks are the only birds in my zoo that don't fly, I might just live with a single special case. But when flying squirrels show up, I'll frown. And when penguins show up, that's when I will abandon inheritance. Use the tool that best solves your problem, and toss aside tools that don't. That's the /real/ lesson.

And if you even MENTION the ghost zoo, where no animals have weight, I'm going to get quite sour.

[Niya]

I agree with Sitten that inheritance solves this problem poorly....however, with a combination of inheritance, interfaces and polymorphism, you can do such wonders. I actually just realized that I faced this exact same problem relatively recently. The Demon Arena project(you can find a link to it in my signature) had me working with this rubber duckie problem. At first, I tried to solve it with only inheritance only to run into a wall as I started adding more stuff to it. For those of you who don't know, Demon Arena is a basic 2D engine where I put various creatures to fight against each other by mostly throwing projectiles.

Here's where OO actually made this such a pleasure to work on. You see there is a lot of stuff happening on the screen when its running. Creatures roaming about throwing stuff, explosions, move blurs etc. OO was able to model this environment very perfectly. Because no matter what, everything you see on the screen has an x and y and a current frame in the form of a Bitmap(or a cached DirectX texture if you want better performance). Right there you got your first and most basic interface, lets call it IEntity(its actually called this in the project). Every thing you see on the screen would implement this interface. I can then implement a simple base class for non moving special effects such as movement blurs and explosions. Different types of effects would inherit this base class and implement their own effect.

Ok, so what about creatures and projectiles ? Well this is why this approach was so beautiful. I created two separate base classes, one for projectiles and one for the creatures and both implement IEntity. The beauty about this is that when its time to render, I don't have to care what kind of entity I'm rendering or its implementation. Polymorphism allows me to treat each object to be drawn as IEntity objects and that interface provides only what I need for rendering, its position and its current frame.

It gets even more interesting than that. For example, certain creatures throw explosive projectiles and I wanted those projectiles to have an effect on creatures that are near the explosion, so I created an IThrustable interface and implemented it on the creature base class. Now, I want to point something out here, that is that this is can be a trap when doing this for the 1st time because your first instinct would be to implement this behavior on the creature base class itself. It makes sense. All creatures should be affected by explosions from their enemies. Here's where the trap lies. Remember the other base classes for special effects or you might event want different types of entities later down the line that you may want to be affected by explosions the same way. By creating IThrustable and implementing it on the creature class ensures that all creatures can respond to explosions and it also leaves me with the ability make other types of entities capable of responding to explosions.

I should also mention one of the greatest things I've discovered about using interfaces in scenarios like this. It reduces the amount of mistakes I can make when I have the discipline to code only against the interfaces. For instance, the code in the projectile class that deals with explosions don't have to care one lick about what its affecting other than the IThrustable interface is implemented and the compiler would enforce this. You can't mistakenly try to thrust something that isn't meant to be thrusted. All I need to be concerned with is calculating the correct values to pass through the interface. Each entity implementing the interface only has to worry about how its going to respond to the values passed through the interface.

The point I am making is that the trick to using OO is knowing when to use what. I did fall for the trap I mention above but fortunately I was able to correct it before I became too committed to using inheritance instead of interfaces. It took a while but I've developed an instinct for knowing when to use what.

BTW, I also did this same project in VB6 before and while I managed to make it work, it was no where near as clean or elegant, no matter how much I tried to make it so and I remember quite well trying a number of different patterns in the hopeless attempt to make the project manageable. I never found a clean way to model it in VB6 and it quickly became a huge mess and seeing how cleanly others implemented similar ideas in C++ using inheritance and function pointers, etc(I was looking at the Doom source at the time) only frustrated me even more that I couldn't do it like that. I finally gave up and stopped working on it. At the time I concluded that VB6 was never the language for this kind of thing. I was thinking that I should have used C++ instead. Of course that was long before I knew anything about what VB.Net or C# had to offer.

Now, this is not to say VB6 is bad, its just for these particular type of problems, VB6 was far less suitable as far as maintainability goes. I'm sure that with my current experience I can implement a far cleaner solution in VB6 but I'm also sure it would not be as clean as the VB.Net, a C# or even a Java solution. OO deals with this type of problem too well.

[Carlos Rocha]

Well, the problem has changed a bit, didn't it?

Originally there was 4 different ducks which could Quack, Swim, Fly and, possibly, have a picture. A base class defined with defaults (Don't fly, Can Swim, Can Quack, No Picture), and changing "only" what doesn't fit for "not regular" ducks seems to solve the problem. What each property means is easily adaptable (call a function, instantiate an object, write a letter,... whatever). This is a simple way of inheritance: use a base class and change what needs to be changed for sub-classes. This is what Olaf did for the given problem. Simple and effective, even for a few more ducks with a few more properties.

Now, making this for every animal on earth would be insane. It would require a few days studying the problem, eventually defining Groups, Classes, Families, Species,... (or whatever zoologists use to classify animals).
But a Class named Animal would only make sense it there was a class named NotAnimal.

EDIT: I imagine that VB6 is able to call a function by name? if so a given property could be simply a string with a function name, or a class name...

[Tanner_H]

BTW, I also did this same project in VB6 before and while I managed to make it work, it was no where near as clean or elegant, no matter how much I tried to make it so and I remember quite well trying a number of different patterns in the hopeless attempt to make the project manageable. I never found a clean way to model it in VB6 and it quickly became a huge mess and seeing how cleanly others implemented similar ideas in C++ using inheritance and function pointers, etc(I was looking at the Doom source at the time) only frustrated me even more that I couldn't do it like that. I finally gave up and stopped working on it. At the time I concluded that VB6 was never the language for this kind of thing. I was thinking that I should have used C++ instead. Of course that was long before I knew anything about what VB.Net or C# had to offer.

This reminds of a fun (brief!) diversion.

Doom was actually written in C. So were Quake, Quake II, and Quake III Arena. iD didn't move to C++ until Doom 3, and even then, Carmack had concerns about his ability to use it well. This analysis of Doom 3's source code is one of my favorites - and I think relevant to this discussion - and if you scroll down you can see Carmack's response in the comments. Here's the bulk of it:

In some ways, I still think the Quake 3 code is cleaner, as a final evolution of my C style, rather than the first iteration of my C++ style, but it may be more of a factor of the smaller total line count, or the fact that I haven’t really looked at it in a decade. I do think “good C++” is better than “good C” from a readability standpoint, all other things being equal.

I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set.

I mistrusted templates for many years, and still use them with restraint, but I eventually decided I liked strong typing more than I disliked weird code in headers. The debate on STL is still ongoing here at Id, and gets a little spirited. Back when Doom 3 was started, using STL was almost certainly not a good call, but reasonable arguments can be made for it today, even in games.

I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.

The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions.

I like that opening quote a lot, "I still think the Quake 3 code is cleaner, as a final evolution of my C style, rather than the first iteration of my C++ style." A language you know and wield well is always going to result in clearer code than a language you don't know as well.

It also makes me feel better that the greatest coder of all-time (yep, I went there) is also working at un-learning old OOP habits in favor of functional programming, where appropriate.

Well, not sure why my responses always seem to be recognized as "coming-out-of-the-wrath-corner" - I'm just passionate in defending my position - with good arguments I think - and with reasonable
and logic requests - or simple questions, when points of disagreement were reached.

Like JackB before (whose sarcasm was quite funny, I thought), I think you need to read our comments with a little less literalism. I was just teasing you; I enjoy the passion on display. (However, I'm less fond of your use of hard line breaks, which cause your posts to flow very poorly on certain screen resolutions! )

[Tanner_H]

EDIT: I imagine that VB6 is able to call a function by name? if so a given property could be simply a string with a function name, or a class name...

Call CallByName(Object, "NameOfFunction", vbMethod, Arguments)

It's not generally advisable to use CallByName(), but like GOTO, it sometimes provides a more elegant solution within VB6's unique constraints.

[techgnome]

Huh... I noticed the conversation has moved away from VB6-v-VB.NET to a more broader subject of Battle of the Design Patterns. Perhaps that's really the crux of the issue, not one of actual languages but the patterns and habits we use.

-tg