I spend about 95% of my time, when coding, in C#. So, recently rolled onto a project that had built a framework using VB.NET (that's the first indication of trouble).
So, I see something like the following when trolling through the code:
Public Class PoorClass
Public ReadOnly Property BadProperty(ByVal aParm As String, ByVal bParm As String) As String
Get
Return "This isn't really a property anymore"
End Get
End Property
I had no idea you could add parameters to a property. Turns out, it's only possible in VB.NET that I've seen. You can't do this in C# - and with good reason.
The problem with the above code (other than the total verbosity of VB.NET itselft) is it violates a core concept of what an object is: something described by "state" and "behavior" - or for .NET we can use Properties (and fields) and methods. So, a property is supposed to be an object's state. But if we're passing in parameters, it now has become a "method".
From Wikipedia (Object (conputer science))
In the case of most objects, one can access the data members only through the method members, making it easy to guarantee that the data will always remain in a well-defined state (class invariants will be enforced). Some languages do not make distinctions between data members and methods.
Three properties characterize objects:
- Identity: the property of an object that distinguishes it from other objects
- State: describes the data stored in the object
- Behavior: describes the methods in the object's interface by which the object can be used
So, this to me violates the core concepts of objects.
The Java world has had Javabeans that provide designer support for interpreting method names such as get_, set_, Is_. Ultimately, they all boild down to methods in the bytecode, and in .NET methods, but it's about "object thinking". And the framework that I'm looking at violates that principle. And a misuse of a capability that probably should be prevented in the first place by the compiler - but that's when you get a bunch of VB.NET programmers, with VBA & VB6 as their heritage, building an OO based framework that should be re-usable across any .NET language.
In fact, if I try to consume this from C# it looks more like magled IL, but nonetheless, consumable:
BadLibrary.PoorClass c = new BadLibrary.PoorClass();
c.get_BadProperty2( "test" );
We see the property looks like a method with the "accessor" verb (get_) prefixed. This is what the IL looks like that's emitted from the VB.NET compiler.
.property string BadProperty {
.get instance string BadLibrary.PoorClass::get_BadProperty(string, string)
}
So, it's a property. Just doesn't act like on, nor does it appear as such to C#. Here's the real method in the IL that's consumed from C#:
.method public specialname instance string get_BadProperty(string aParm, string bParm) cil managed {
.maxstack 1
.locals init (
[0] string text1)
L_0000: nop
L_0001: ldstr "This isn\'t really a property anymore"
L_0006: stloc.0
L_0007: br.s L_0009
L_0009: ldloc.0
L_000a: ret
}
This is just a single example of numerous issues that I've seen. The framework is ripe with magic numbers, hungarian notation, type name abbreviations that are more cryptic than valuable, overly complex nesting of interface implementations. And that's just the code.