Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > Visual Basic > VB.NET 1.0 > Pro VB.NET 2002/2003
Password Reminder
Register
Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
Pro VB.NET 2002/2003 For advanced Visual Basic coders working .NET version 2002/2003. Beginning-level questions will be redirected to other forums, including Beginning VB.NET.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Pro VB.NET 2002/2003 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developersí questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old July 29th, 2004, 08:13 AM
Imar's Avatar
Wrox Author
Points: 71,164, Level: 100
Points: 71,164, Level: 100 Points: 71,164, Level: 100 Points: 71,164, Level: 100
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 16,948
Thanks: 79
Thanked 1,555 Times in 1,532 Posts
Default Returning Nothing from a constructor

Hi there,

What is the cleanest way to have a constructor return Nothing? Let's say I have a constructor for an Employee that expects the ID of the employee in the database. If the ID is found, I initialize fields like FirstName etc and return the Employee. However, if the ID is not found, I want to return Nothing, so I can use code like this:
Code:
Dim myEmployee As Employee = New Employee(123)
If Not myEmployee Is Nothing Then
  ' Valid Employee
Else
  ' Employee not found
End If
I could of course create Shared methods on the Employee class like CreateEmployee and have this method return Nothing or an Employee, but that looks clumsy. I think the constructor itself should be able to kill itself.

Should I implement IDisposable and call Me.Dispose()??

Thanks in advance for any answer.

Cheers,

Imar
__________________
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Follow me on Twitter

Author of Beginning ASP.NET 4.5 : in C# and VB, Beginning ASP.NET Web Pages with WebMatrix
and Beginning ASP.NET 4 : in C# and VB.
Did this post help you? Click the button below this post to show your appreciation!
Reply With Quote
  #2 (permalink)  
Old July 29th, 2004, 08:50 AM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,413
Thanks: 0
Thanked 16 Times in 16 Posts
Default

I don't know as you can... I mean, here we are instantiating a class instance, and yet we want to be able to null ourself out.

From my point of view, having a constructor do something more than simple initialization (setting default values of internals) is risky anyway. What happens if the object contains code that assumes something about the current configuration and that configuration is not ready yet?

I think the best solution may be the shared method.

Dim myEmployee As Employee = New Employee.Load(123)

I haven't worked with the IDisposable interface so I can't say whether or not you could dispose the class from within its own constructor.

Although it's a clumsy/kludgey, something I have started doing is this: In most cases where I have an object that is based on a data entity, my data identifiers are usually positive integers. So I default a new class' ID to -1 to essentially say "no data"/"not loaded", etc. From that you can test. I'm sure that OOP theorists would flunk me for poor design, but it works. :-/ So now we could do this:

Public Class Widget
   Public Const NO_ID As Integer = -1
End Class

Dim myWidget As New Widget(123)
If Not myWidget.ID=Widget.NO_ID Then
  ' Valid Widget
Else
  ' Widget not found
End If

Maybe a better approach I just thought of would be to follow the lead of the .NET String class: String.Empty.

Public Class Widget
   Public Empty As Boolean = True
End Class

Dim myWidget As New Widget(123)
If Not myWidget.Empty Then
  ' Valid Widget
Else
  ' Widget not found
End If

To me, one of these makes more sense. We have an valid instance of a class, but it's just empty. Particularly helpful if you then want to use that instance. You don't need to instantiate it again, you can just populate the empty one. Again, I'm sure that OOP theorists would lob off my fingers, but hey, I'm not a theorist, I'm a make-it-work..ist. :D
Reply With Quote
  #3 (permalink)  
Old July 29th, 2004, 09:01 AM
Imar's Avatar
Wrox Author
Points: 71,164, Level: 100
Points: 71,164, Level: 100 Points: 71,164, Level: 100 Points: 71,164, Level: 100
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 16,948
Thanks: 79
Thanked 1,555 Times in 1,532 Posts
Default

Ha, I think I am in the same boat on this ;)
Using -1 or IsValid (or Empty or whatever) has always worked for me and it's easy to implement.

However, I am designing a brand new system, so I get the opportunity to "do it by the book". I was hoping there was an OO way of doing this, that is also implementable in .NET.

Thanks for your input, Peter.

Anyone else have a different view on this matter?

Imar
Reply With Quote
  #4 (permalink)  
Old August 24th, 2004, 07:22 AM
Registered User
 
Join Date: Aug 2004
Location: , , .
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi there,

Maybe a better way to do this is to find out if the employee exists before you try create the employee object - you could use an shared method of the Employee class to determine this i.e.

dim validEmployee as Boolean = Employees.IsValid(123)

If validEmployee is true, then go ahead and create the employee object.

This also has the benefit of giving you the ability to check for a valid employee elsewhere in your code - what i mean is that somewhere along the line there may come a point where you need to quickly see if a employee is valid. If you have to create an instance of the Employee object just to check that there is such an employee, then that is very wasteful - chances are you'll simply destroy the newly created Employee object anyway, without actually using it!

Reply With Quote
  #5 (permalink)  
Old August 24th, 2004, 12:45 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: Hudson, MA, USA.
Posts: 839
Thanks: 0
Thanked 1 Time in 1 Post
Default

Why do you think the shared method "...looks clumsy..."? It would be an example of a factory method, and that is a familiar OO design pattern...

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com
Reply With Quote
  #6 (permalink)  
Old August 25th, 2004, 01:17 AM
Imar's Avatar
Wrox Author
Points: 71,164, Level: 100
Points: 71,164, Level: 100 Points: 71,164, Level: 100 Points: 71,164, Level: 100
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 16,948
Thanks: 79
Thanked 1,555 Times in 1,532 Posts
Default

Yeah, I realize that now. It doesn't look as clumsy as I thought it would.

I had my butt kicked by a couple of OO guys over at www.asp.net when I asked the same question some time ago. Obviously, I got the same answers: nothing wrong with this method, this is a factory pattern and even "back to the books" ;)

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
Reply With Quote
  #7 (permalink)  
Old August 25th, 2004, 08:11 AM
Friend of Wrox
 
Join Date: Jun 2003
Location: Hudson, MA, USA.
Posts: 839
Thanks: 0
Thanked 1 Time in 1 Post
Default

We've pretty much standardized on using shared factory methods exlusively to instantiate all our business objects. All object constructors are marked private, so the only way to create the objects is via the factory method(s). We find this gives us substantially more flexibility and control over the conditions and parameters for object creation including even which objects actually get created.

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com
Reply With Quote
  #8 (permalink)  
Old August 25th, 2004, 01:33 PM
Imar's Avatar
Wrox Author
Points: 71,164, Level: 100
Points: 71,164, Level: 100 Points: 71,164, Level: 100 Points: 71,164, Level: 100
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 16,948
Thanks: 79
Thanked 1,555 Times in 1,532 Posts
Default

Yeah, I must say that the more I am using this method, the more natural it looks, and the better it seems to work.....

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
Reply With Quote
  #9 (permalink)  
Old June 29th, 2012, 02:00 PM
Registered User
Points: 3, Level: 1
Points: 3, Level: 1 Points: 3, Level: 1 Points: 3, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2012
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default Prefer Public Variable / Property

Forcing Object Construction via a Factory Method or allowing use of a Shared validation Method is fine if all you care about is whether it was / can be created or not. However, what if, in cases when it was not created, you also want to know to know the reason(s) why?

1. You could have a Parameter on the Factory Method that tells you why but: a) you'd need to declare a separate Variable to hold the results of that Parameter and b) to follow good practices, do so in every place you're trying to create the Object vs. sharing a Global one.

2. You could Throw a custom Exception but that would require use of the Try Statement, which: a) is cumbersome, b) IMHO, should be reserved for unexpected errors where you just want to display and / or log an error(s) and exit vs. recover and continue processing and c) cannot be enforced to exist (via a Base Class or a more generic Interface) to exist like a Public Variable / Property of the Class.

3. You could have a Shared validation Method but: a) it would have the same disadvantage as option 1 above, plus b) it would have to duplicate the Parameters needed by the Constructor and the appreciating human cost of that duplication is usually much more significant than the depreciating machine costs of Constructing an Object only to Destruct it shortly after.

For commonly expected errors (like the User typed in an invalid value(s) needed to create the Object), it's much easier to just check one or more Public Variable(s) / Property(ies) of the Class.
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Constructor nayeem69 .NET Framework 2.0 1 July 17th, 2007 12:33 AM
Constructor ramess C++ Programming 1 March 18th, 2006 06:23 PM
constructor in servlets bondalapati98 Servlets 5 January 15th, 2006 11:27 PM
Problem with a constructor Mishkina General .NET 0 September 23rd, 2005 08:26 AM
Constructor problem yengzhai C++ Programming 6 May 18th, 2005 11:05 AM



All times are GMT -4. The time now is 03:54 AM.


Powered by vBulletin®
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.