Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Ask first

A long time ago, somewhere around 1987, I worked for a company who was going to enter a new field of opportunity. MS DOS 3, dBase III+ and IBM PC Lan would give the opportunity to build multi user business applications for Personal Computers. For those of you who are lucky enough to be unfamiliar with dBase: it is a VB/LINQ like language combined with storage for tabular data. Every table in a separate file, every column or expression on which you want to sort or search requires another file. By default MS-DOS did not allow for more than 20 open files open simultaneously. You can imagine getting an app up and running did take some effort. Anyway, the company had organized a course ending with a test. The examiner handed pages torn out of the phone directory. A clear list of entries, name, address, phone number and the like. We started working on selecting indexes, deciding about input picture’s, configuring the PC’s and things likewise. Except one of us. All he did was asking the examiner “What do you want to do with this ?”. He was the only one who passed the test.

Something similar happened with my last post. I tried to explain a problem in our application with the typing of a specific ID. Loads and loads of you started commenting heavenly about bad design and loads of suggestions on a better design. First I took the bait and started trying to defend and explain our design and trying to make clear why the suggestions did not fit our needs. With not to much success. Until I realized that there was no design described at all. Just two snippets of (over-)rsimplified code, no more. The rest in the imagination of the reader. An update silenced comments. My fault not writing clear enough from start, your fault not asking what I really wanted to do.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/members/pvanooijen/default.aspx pvanooijen

    Thanks for your constructive comment.
    But still you’re not asking how we are actualy using this Id.
    As your example is pretty close to our situation, you’re welcome on our next team meeting :)
    No kidding..

  • http://py-sty.blogspot.com/ Steve Py

    I don’t think the shelling stopped so much as people had said their mind about it, and others lost interest as most blog comments die off after a couple days…

    In any case most blog posts like this are generally along the lines of:
    “Here’s an interesting problem, and this is a novel way to approach it.”

    The trouble with your Enum example is that regardless of what your intention is, relying on conditional code logic like that is the problem, not the fact the code has run into a snag with Enum.

    Enums are best used as flags if and when a flag state (other than yes/no/true/false) is needed. For example:
    public enum CompanyType
    None = 0,

    Provided that this flag is just that, something that is pulled out of data, inspected for minor behaviour rules, etc. If business logic is more dependent on the type of company then Company should be subclassed and strongly typed objects or methods can work against each applicable sub-class. (The business logic doesn’t need to polute Company & its sub-classes.) Generally if you’ve got more than 1 switch statement operating against that flag, it probably should be subclassed. (Though I’m sure many purists would argue against using any switch statements. :)

    In fact, even for flag states, public constants are a potentially more buggy solution than enum since any dependent assemblies will have the injected constant values embedded in them. (making updating the assembly hosting the constants a potential bugbear) public static readonly fields would be a preferable replacement for enums.