C#: The Problem with Properties

Properties Can't be Overloaded: And therefore lead to a verbose hybrid Property/Method design. Or require a future re-write that breaks the previous api.

For Example: Fields, other than strings, will generally have data come into a class as a string or the fields native datatype:

private string _StockNumber = null;
private decimal _Quantity = 0.00M;

// StockNumber
// string data is safe as a Property( assuming it doesn't enter your system as a number. )

public string StockNumber
{
    get { return _StockNumber; }
    set { _StockNumber = value; }
}

// Quantity
public decimal GetQuantity()
{
    return( _Quantity );
}

// Here's our standard method for sending decimal data to a decimal field
public void SetQuantity( decimal Quantity )
{
    _Quantity = Quantity;
}

// Here's our overloaded method to PARSE string data.
public void SetQuantity( string Quantity )
{
    try
    {
        decimal tempQuant = decimal.Parse( Quantity );
        _Quantity = tempQuant;
    }
    catch( ArgumentNullException ane )
    {   // caught Null value
        // build a decimal value of zero? and accept? Up to You.
        string sMsg = ane.Message;
        throw new xQuantityException( sMsg );
    }
    catch( FormatException fe )
    { // caught Non-Numeric data
        string sMsg = fe.Message;
        throw new xQuantityException( sMsg );
    }
    catch( OverflowException oe )
    { // number too large or too small
        string sMsg = oe.Message;
        throw new xQuantityException( sMsg );
    }
}

- Intellisense will show overloaded methods:

decimal SetQuantity( decimal )
decimal SetQuantity( string )

- Hybrid Coding Quantity as a property and a SetQuantity() method would lead to programmers MISSING the SetQuantity() method when viewing Intellisense.

 

The Problem:

A Hybrid method of coding Properties and SetField() methods leads to BAD object oriented design, especially worrisome would be Properties and SetMethods() coded for the Same Field!

- Will the user of the class SEE the SetQuantity() method?
If not, then code that should be in the class will be dispersed throughout the application, in ASP pages or pages that accept XML input data.
A user of the class might very well RE-WRITE the SetQuantity() code in the ASP page or the XML receiving class. Breaking a principle of good Object Oriented Design: The code for the class should be IN THE CLASS( Encapsulation ).

What have we learned today:

- Only string fields qualify for Property handling. Assuming string data never enters your system as another datatype.

- C# teaches once again the Java Designers had good reasons for their design decisions.
- A Microsoft "enhanced" version of Java 1.5 would have been better then C#.
- If Microsoft had a Java Community Process this "feature" wouldn't have been implemented.
- Design Decisions should be based upon practical experience.

TIP FOR MICROSOFT: Another bad design "feature" of C# to aid Programmers Who Don't Know How to TYPE.
Instead of building a fragile language model for non-typing programmers, it would be better if you bundled a typing program and game with every version of Visual Studio 2005.