What if there was a NEW vb6

[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.