Constructor style preference

Given the following auto generated code:-

VB Code:

'------------------------------------------------------------------------------
' <auto-generated>
'     This code was generated by a tool.
'     Runtime Version:4.0.30319.42000
'
'     Changes to this file may cause incorrect behavior and will be lost if
'     the code is regenerated.
' </auto-generated>
'------------------------------------------------------------------------------
 
Option Strict Off
Option Explicit On
 
 
Namespace test
    
    Partial Public Class Duncan_s_Class_Test
        
        #Region "Private members"
        Private _Email As String
        
        Private _Height__cm As Integer
        
        Private _Blood_Alcohol As Decimal
        #End Region
        
        Sub New(ByVal DuncansClassIn As IDuncansClass)
            MyBase.New
            _Email = DuncansClassIn.Email
            _Height__cm = DuncansClassIn.Height__cm
            _Blood_Alcohol = DuncansClassIn.Blood_Alcohol
        End Sub
        
        Sub New(ByVal Email_In As String, ByVal Height__cm_In As Integer, ByVal Blood_Alcohol_In As Decimal)
            MyBase.New
            _Email = Email_In
            _Height__cm = Height__cm_In
            _Blood_Alcohol = Blood_Alcohol_In
        End Sub
        
        '''<summary>
        '''Email address of the user
        '''</summary>
        Public ReadOnly Property Email() As String
            Get
                Return _Email
            End Get
        End Property
        
        '''<summary>
        '''Recorded height in cm
        '''</summary>
        Public ReadOnly Property Height__cm() As Integer
            Get
                Return _Height__cm
            End Get
        End Property
        
        '''<summary>
        '''Recorded blood/alcohol
        '''</summary>
        Public ReadOnly Property Blood_Alcohol() As Decimal
            Get
                Return _Blood_Alcohol
            End Get
        End Property
    End Class
End Namespace

Which constructor type do you prefer - individually explicitly named properties or instance of interface?

You mean the difference between _Email and Me.Email?

Traditionally I use the backing variable, _Email in this case... unless there is a reason to use the property (such as data dependance or logic that needs to be executed.)

-tg

Between:-

VB Code:

Sub New(ByVal DuncansClassIn As IDuncansClass)
            MyBase.New
            _Email = DuncansClassIn.Email
            _Height__cm = DuncansClassIn.Height__cm
            _Blood_Alcohol = DuncansClassIn.Blood_Alcohol
        End Sub

and

VB Code:

Sub New(ByVal Email_In As String, ByVal Height__cm_In As Integer, ByVal Blood_Alcohol_In As Decimal)
            MyBase.New
            _Email = Email_In
            _Height__cm = Height__cm_In
            _Blood_Alcohol = Blood_Alcohol_In
        End Sub

Neither. I wouldn't have individual members for email, height and blood alcohol but would simply have an IDuncansClass member. So my Duncan_s_class_test would receive in an IDuncansClass but it wouldn't be opening it up to get at the individual members.

I'm not sure why the individual members have been broken out at all. Surely that's just breaking encapsulation. Am I missing something here?

Blood Alcohol as decimal is a good call. If you could measure mine in ints, it would result in an overflow.

Actually... it depends... I might do both... depends on how I plan to call it... will I always have an IDuncansClass object I can pass in? It kind of depends on the context and what's expected as the minimum needed for the class.

I get what Funky suggested, I'm not sure I completely agree... I create classes that are often based on DataRows... but that doesn't mean I'm going to make a DataRow property and expose the data that way. Otherwise what's the point. However, given his example, it makes sense since then the data will remain in synh (what if the address of one instance is changed? it won't propogate the value to the other class.)

-tg

Quote:

---

I create classes that are often based on DataRows

---

That's a good point I hadn't considered. If this class is abstracting an iDuncansClass then I'd go with the second constructor (you'd have to because the first exposes an iDuncansClass).

I think I'd probably still be storing the values in a private iDuncansClass member though. Assuming iDuncansClass has some functionality (so it's more than just a collection of values) then, if I stored the values individually, I would need to construct a new iDuncansClass from the individual values each time I wanted to use that functionality.

If I don't want to expose iDuncansClass publically then I can still expose it's members publically through the properties of Duncan_s_Class_Test. E.g.

VB Code:

Public ReadOnly Property Email() As String
            Get
                Return myIDuncansClass._Email
            End Get
        End Property

I still can't help feeling I'm missing something on this one though.

IF taken in tandem with Merri's recent posts, he's working on a code generator. So my guess is that he's working out how to create the initial codebase to then work form.

-tg

Attachment 129601

Yeah - each of the entities in the diagram becomes an interface and partial class pair - the end goal being that the tool builds your CQRS framework and you can add in any custom functionality.

Since there is no functional difference between the styles I have added an option to choose which to use:

VB Code:

''' <summary>
    ''' What type of constructor to use in the generated classes
    ''' </summary>
    ''' <remarks>
    ''' This could be a per-model rather than per-user preference 
    ''' </remarks>
    Public Enum ConstructorPreferenceSetting
        ''' <summary>
        ''' (Default) Generate both an interface derived constructor and a parameters derived constructor
        ''' </summary>
        GenerateBoth = 0
        ''' <summary>
        ''' Only generate an interface derived constructor
        ''' </summary>
        InterfaceOnly = 1
        ''' <summary>
        ''' Only derive a parameters derived cosntructor
        ''' </summary>
        ParametersOnly = 2
    End Enum

On that note... sometimes I do both... as I mentioned I often will use a DataRow as my class source, but I may not always have a datarow. Borrowing form another thread, take the Duck example, if I'm loading ducks from a database I'll have a datarow... but when creating a new duck, I won't... so I'll have a base constructor (no params), one with a data row, and one with parameters - I don't expose ALL properties as parameters, but I'll expose the non-optional kind.

-tg