Sharing an instance of an object across classes

Hello.

I'm trying to find another way to share an instance of an object with other
classes.

I started by passing the instance to the other class's constructor, like this:

Friend Class clsData
Private m_objSQLClient As clsSQLClient
Private m_objUsers As clsUsers
Private m_sConnect As String

Friend Sub connect(ByVal bDebuggerAttached As Boolean)
Dim sServer As String
Dim sDB As String

If bDebuggerAttached Then
sServer = "test"
Else
sServer = "prod"
End If
sDB = "appdb"

m_sConnect = "Data Source=" & sServer & ";Database=" & sDB & ";Integrated
Security=true"
m_sConnect = m_sConnect & ";Application Name = " &
My.Application.Info.AssemblyName

m_objSQLClient = New clsSQLClient
m_objSQLClient.connect(m_sConnect)

m_objUsers = New clsUsers(m_objSQLClient)
End Sub
End Class

Friend Class clsUsers
Private m_objSQLClient As clsSQLClient
Private m_dtUser As DataTable

Friend Sub New(ByVal objSQLClient As clsSQLClient)
m_objSQLClient = objSQLClient
End Sub

Friend Function markEntry() As String
Try
m_dtUser = m_objSQLClient.tableForEdit("users")

This works, but I don't like it.  I want clsUsers to refer directly to the
instance variable in clsData instead of passing a parameter.

Then I saw an example using inheritance that I liked, so I added:

Protected Friend Function sqlClient() As clsSQLClient
Return m_objSQLClient
End Function

To clsData and I deleted the constructor in clsUsers and changed the code to:

Friend Class clsUsers
Inherits clsData
Private m_dtUser As DataTable

Friend Function markEntry() As String
Try
m_dtUser = MyBase.sqlClient.tableForEdit("users")

but it doesn't work- it raises an exception when clsUsers.markEntry
references mybase.sqlClient.

Is there another way I can do this, or do I need to stick with passing the
object instance as a parameter?

Thanks for any help,

-Beth

Sharing an instance of an object across classes

First of all, it is usually a bad idea to allow other classes, included sub
classes direct access to instance variables.  It should always be through
properties.  In fact, I try to never access field data even inside my own
class without going through properties :)  The main reason is that properties
provide a layer of abstraction, that allows the implmentation change without
having affecting client code...   For instance, what if a field needs to
become a calculated value?  If you went through the property, all is well, but
if you allowed client code to directly access the field then you are in
trouble.  Believe me, I have learned this lesson the hard way :)

That said...  Let's see if we can't come up with a good answer, to your
problem :)  Based off of what I'm seeing here, I don't see the problem with
your first example?  Why do you feel it is better not to pass the parameter to
the constructor - though, I would probably do it more like this:


Class clsData
Private _sqlClient As clsSqlClient
private _users As clsUsers

Public Sub New (....)
SqlClient = new clsSqlClient(....)

Users = New clsUsers (SqlClient)
End Sub

Private Property Users As clsUsers
Get
Return _users
End Get
Set (ByVal Value As clsUsers)
_users = Value
End Set
End Property
Private Property SqlClient As clsSqlClient
Get
Return _sqlClient
End Get
Set (ByVal Value As SqlClient)
_sqlClient = Value
End Set
End Property

End Class


Anyway, that's my oppinion, others may differ.  And it maybe another approach
my be better if you application has a different achitecture.  Like, do all
isntances of all classes use the same SqlClient instance, etc.


--
Tom Shelton

Hi, Tom.Thanks for your response.

Hi, Tom.
Thanks for your response.

Yes, multiple classes share a single instance of clsSQLClient connected to
the server.  Right now, I'm passing it as a parameter to each of the class's
constructors.

ClsData is intended to wrap all of the data access functions of the
application.
ClsSQLClient Imports System.Data.SqlClient, and is the only class to do so.
ClsUsers has a 'has-a' relationship with clsData: the data object includes a
representation of the users table in the database.

I'm trying to figure out how to share an instance of a variable without
using inheritance.  For a 'has-a' relationship (composition,) I've read
you're supposed to use interfaces instead of inheritance, but interfaces
don't contain implementation, so you can't share instances of objects at
runtime.

Maybe what I'm doing is what I'm 'supposed' to be doing, but I don't like my
class diagram having all these other classes point to my clsSQLClient.
I only want clsData to point to it, and all the other classes to point to
clsData.

When I tried to use inheritance, I got a nicer diagram, but broke the app.

Also, I'm not sure what you're referring to when you say it's:
a bad idea to allow other classes, included sub classes direct access to
instance variables

I didn't think I was allowing direct access to the private instance
variables outside of the classes.  I agree, it's a bad idea, but I'm not
seeing where I'm doing it.

Thanks again for your response.  I'm sticking with the parameters for now.

-Beth

I think that whole bit of code is ... .. hurting.....

I think that whole bit of code is ... .. hurting.....

You're tied your clsUsers to always coming from the database.
Based on the notation (hungarian), this looks like leftover VB6 code, and no
one at your workplace has taken a VB.NET course yet.

Take a look here:

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

This is a layered application.

The business objects and collections are seperate from the code that creates
them.
The code that creates them can use database related calls, OR (better) the
business objects and collections can be created totally independant of a
database.
(One reason?  UnitTesting)

Your connection strings should be kept in a config file.  You've got
hardcoding all over the place.


I'm not trying to be mean...but youch....... I have no idea what that code
is doing.  I might have in 1999.



...............

Sharing an instance of an object across classes

Hmmm...  Sounds to me like you need something along the lines of a
singleton...

Class clsData
Private Shared _instance As New clsData
....

' your public instance methods here

Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class

Class User
...

Public Sub SomeSub()
clsData.Instance.DoCoolStuff()
End Sub
End Class




Your probably not :)  I didn't look that close, but I was just commenting on
your remark about allowing clsUsers direct access to the instance variable.


--
Tom Shelton

Sharing an instance of an object across classes

Yep... I have to agree.

--
Tom Shelton

Thanks, Tom.

Thanks, Tom.

It looks recursive, but I see where the new instance of the class is created
during the declaration instead of outside the class, enforcing the single
shared instance, as long as no caller decides to instantiate the class.

I got the instance reference to work without passing an instance of the
class as a parameter to other class's constructors, and that was what I
wanted.

I think what I was looking for before was some kind of 'functional'
inheritance, which doesn't seem to exist.

I was thinking when you instantiate a derived class, it 'latched on' to the
base class instance in memory, so you could call the base class's functions
at runtime and get the same results as if you'd called the base class's
functions directly, but it doesn't work that way.  The derived class has its
own instance of myBase separate from any other instance, which makes sense,
because you're not guaranteed to have any instance of the base class in
memory or you could have several instances, and then which one would the
derived class 'latch on' to?

Thanks again for your response.  I'd seen the 'shared' keyword before, but
not used on a new instance of itself.

I guess that's what they mean by 'singleton.'

-Beth

Sharing an instance of an object across classes

but you cannot listen for events from a singleton...

Sharing an instance of an object across classes

Actually, there is a mistake in that implementation...  clsData should have a
private constructor.  In other words, it should prevent any other classes from
instantiating it :)

Here is the correction...

Class clsData
Private Shared _instance As New clsData
....
Private Sub New ()
' this should probably read your connection
' information from the connectionstrings section
' of your config file
End Sub

' your public instance methods here

Public Shared ReadOnly Property Instance As clsData
Get
return _instance
End Get
End Property
End Class

Now, there is only on instance of this class.  I am not saying this is the
correct architecture.  The more I've read, it sounds like you are trying to
develop a n-teir type application.  You might want to do some reading on that
topic.

--
Tom Shelton

Thanks again, Tom.I like that better.

Thanks again, Tom.
I like that better.

I've read about n-tier development, but that's not really what I'm doing.
Everything is in one assembly for one project with one database.  It's not a
large-scale thing, just departmental.  It's not dependent on any modules
running on other servers, in other words.

Sharing an instance of an object across classes

Sure you can.

I'm still not convined that this is the right path.  I think really, more
information is needed on what your trying to achieve.

If I understand, now that I've read more - it sounds like your trying to
create a data abstraction layer.  There are many ways to accomplish this, so
you might want to do a little more reading on n-tier achitectures.  There are
in fact whole applications that will generate this kind of stuff for you :)

But, for simple stuff, I tend to do stuff like this

Friend MustInherit Class DataAccess
Private _connectionString As String

Public Sub New(ByVal connectionString As String)
_connectionString = connectionString
End Sub

' generic data access stuff

Public Function GetList(Of T) (ByVal procedure) As List(Of T)
Dim l As New List(Of T)
' I use attributes and reflection to generate the objects here
' from the resulting recordset.  basically, i map the properties
' of type T to specific fields in the record set.
Return l
End Function
End Class

Friend Class UserDataAccess
Inherits DataAccess

Public Sub New (ByVal connectionString As String)
MyBase.New(connectionString)
End Sub

Public Function GetUsers() As List(Of User)
Return GetList(Of User)("getallusers")
End Function

Public Class

Public Class UserBuisnessLogic
Private _dataAccess As UserDataAccess

Public Sub New (string connectionString)
_dataAccess = new UserDataAccess
End Sub

Public Function GetUsers() As List(Of User)
return _dataAccess.GetUsers()
End Function
End Class

This of course Really, Really, basic.  I have a framework that I've been
evolving overtime :)  And to be real honest, it's all in C# - but many of the
concepts apply to VB.  But, you might want to take a look at some resources on
this topic.

--
Tom Shelton

Sharing an instance of an object across classes

N-Tier is more about a separation of layers then it is about multiple servers,
etc.  N-tier is about layering of you application into multiple independent
layers.  I often have one dll that contains all three layers - the point is
that I can easily separate them out, split them up or replace layers with
different pieces should the need arise.

--
Tom Shelton

Thanks, sloan.I think.Yes, I've been developing over 10 years now.

Thanks, sloan.
I think.

Yes, I've been developing over 10 years now.  I started with VB3, believe it
or not.
And yes, I have taken a couple of .NET courses.  Didn't get through to me, I
guess.

Actually, I used to think I could support anybody else's VB code, until I
saw some written by a guy experienced in COBOL.  Then I saw some code written
by engineers.  Then I saw some code written by a FoxPro developer.

I usually rewrite the old stuff instead of trying to figure out what they
were doing.

So I gather...
You don't like my naming convention.  Personally, I like being able to tell
the data type from the variable name.

You were thinking I was working on components that didn't access the
database directly?  That I was implementing some middle-tier components?  I'm
doing the whole thing, soup to nuts (actually, I've done the whole thing and
I'm revisiting it.)
I could have introduced additional layers of abstraction, but for this
project, it didn't make sense.  It would be introducing abstraction for
abstraction's sake, not reuse.

You want to see connection strings in a config file instead of code.  I'm
not a huge fan of config files, but I have seen them promoted.  It's an
internal application using integrated security, so all I'm concerned about is
keeping people from accessing the wrong back end.  I need to keep people in
prod from connecting to test, even though prod started out in the test
environment and they're structurally the same.  I'm even exposing the
connection in Help/About so we're all clear on where we're connecting at
runtime.

You want to see the use of lists instead of collections.  I think I can
accommodate you, there.

It's certainly not my intention to write code which pains you young
whipper-snappers, so if there's more I was supposed to pick up on, feel free
to share.

I need to take my nap now.

-Beth

You can write layers into one assembly....layers are a logical seperation.

You can write layers into one assembly....layers are a logical seperation.

I think its easier to put layers in different assembies (to avoid crossing
incorrect boundaries)......but you can do layers in one assembly.

I think of Tiers as different boundaries.

But you should be doing Layered development.

//which pains you youngHuh?

//which pains you young

Huh?
I've been developing code for 10 years also (as in being paid ... for a
living).
I started with VB4, 16Bit for Win3.1.

So I don't think age has anything to do with it.


If you count the space invader knock-off game I wrote in the 6th grade on a
TRS80 using ascii characters, then I've been writing code for 24 years on
and off.
Wait, I took a Apple 2e course during my 5th grade summer.  Make that 25
years.

Beth,It sounds for me a bad idea to use VB6 style code where OOP can be used.

Beth,

It sounds for me a  bad idea to use VB6 style code where OOP can be used.

But as you want that, simple use modules instead of classes.

jmo

Cor

Sloan,Sorry, I did not completely read your reply before I wrote mine.

Sloan,

Sorry, I did not completely read your reply before I wrote mine.

I could have written, I agree with you Sloan.

Cor

Tom,I am glad you do.

Tom,

I am glad you do.

I was a little bit disapointed that you were helping with this, and because
it is in a newsgroup than certainly sombody will use this in future.

Something like the by my so hated phrase "It is best
practise.................. whatever"

Cor

Hello Beth,There is nothing wrong with passing an initialized class as a

Hello Beth,

There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )
object instances will only transfer the memory pointer  , so no new
instances are created , you still hold one instance of your class .

You can easiliy proove and confirm this yourself changes in the passed class
will be reflected in the original class , so in terms of memory footprint
and perfomance this is even a bether aproach as using inheritance  as this
would create a bigger footprint in the resulting code output ,


about your coding style ,,,, it would be a good idea for you to read this
book
http://astore.amazon.com/vbdotnetcoder-20/detail/0735621721/175-0134366-2373937

Although i must say i have seen worse coding styles from people honestly
believing that they comply to MSF
i am just mentioning above link because of the comments in this thread wich
are partially valid after reading and conforming to the styles in above book
you can slap 90% of the coders around for not complying to the official MSF
, Practical guidelines and best practices rules .

But ,,,, honestly said it wil sure make you a bether and more productive
programmer if you comply to the basic rules of naming conventions just for
the simple fact that a lot of tools ( devpartner profiler to just call one )
comply to these rules so in my code i just simply declare a private field
and with just a short keyborard shortcut i can convert it to a correctly
named property


Regards

Michel Posseth [MCP]

Sharing an instance of an object across classes

re: you should be doing Layered development

OK, I thought I was, but maybe not.

I have the presentation layer separated from the data access classes, which
are independent of the business content tables on the database.

I don't have any source code (classes) containing business content, like
customerID, name, and phone.  That's all business content I don't determine.
I don't hard code that stuff because it's outside of my control and too
volatile.

My classes are dependent on tables in the database I create for my
application's use which are stored in the same database alongside the
business content tables.  The content of the tables the source code is
dependent on describe how the application should display, validate, manage,
and/or exercise data in the business content tables.

I was thinking I 'should' be able to compile my data access classes into a
separate .dll so I could reuse it for a web front-end.  All the data access
requirements are the same from the presentation layer's point of view.

I don't see a lot of other developers taking this approach, and I see a lot
of class examples modeling business content, so I don't really expect many
people to understand what I'm trying to do, which is one reason why it's
harder for me to get help.

Thanks for trying, anyways.

Sharing an instance of an object across classes

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry

There is the 1.1 version of my other blog entry I gave you.
I would start there.  Move up to the 2.0 version.
(Just read it and step through the code).
The 1.1 version has more explanation than my 2.0 version.  So I would read
(slowly) my 1.1 notes.


My 1.1 article has some links at the bottom.

Both the 1.1 and 2.0 versions of my blog entries have downloadable code.  It
uses the Northwind database.

Heck, I think you could learn an awful lot by just taking a day and
translating the code to VB.NET.
But what do I know?  I'm a whipper snapper.


HERE IS THE MOST USEFUL LINK IN THAT COLLECTION:
And a reference to read from start to finish, aka, very informative for a
bird's eye view:
* http://msdn2.microsoft.com/en-us/library/ms978496.aspx
Bookmark it, read it, reread it tomorrow.  Reread a month from now.  Reread
it 3 months from now.  Reread it 6 months from now.
Reread it every 3 months for the next 2 years.

........

At the very least I would create strong(typed) DataSet objects....if you
don't want a full custom class/collection solution.


Good luck.

Hi again, sloan.

Hi again, sloan.

When I was in high school, we coded on Commodore Pets with a cassete tape
for storage.  I had a computer at home my dad bought for $99.  I think it was
a TRS-A.
Not sure, that was a long time ago.

Oddly enough, my first job was for the Apple//e platform in AppleSoft BASIC
for the public schools market.  When the GS came out, we coded in 6502
assembly.  It was a big deal because all of a sudden we had a lot more memory
and we didn't have to use the unsupported language card to do anything useful.

Of course, no one else was developing for that platform, so I switched to MS
and I've been there ever sense.

I guess I just haven't kept up as well as you have over the years, but I
haven't had a lot of support, either.

I figured maybe someone dumped on you for something similar 10 years ago and
you were paying it forward.

Hi, Cor.Thanks for your response.

Hi, Cor.
Thanks for your response.

I'm using a VB6 naming convention, yes, but not modules because you can't
instantiate one or more instances of a module, can't listen for events, and
can't associate the actions on a data structure with the data structure
itself.  Not to mention all the other OO stuff you can't do.

I can see why people are religious about using OO methods instead of
structured programming, but I haven't found a lot of instructor-led classes
focusing on those concepts outside of UML.  I had the material presented in
college, of course, but I don't remember that. Yes, there's tons of books and
info online, but I learn better from asking someone questions after they've
presented something and I need to make sure I understand them.

If you're aware of a 'OO for VB6-to-.NET programmers' forum somewhere,
please let me know.  Naming conventions I can change.

I'm not even sure if Microsoft has an OO forum somewhere, for those of us
trying to learn more.

Well, anyways, thanks for replying.

-Beth

Thanks for your response, Michael.

Thanks for your response, Michael.

I know you can create 'bad' code in any language reguardless of the amount
of reading you've done or training you've had, and dealing with other
people's code you don't like, agree with, or support is part of being a
developer.

I don't like C-style languages because they're too symbolic and can combine
too many operations in one line of code.  It's for a different level of geek
than me.

What I've noticed about the newer naming convention is it doesn't include
the data type of the variable and the module-level scope prefix (m_) was
dropped in favor of just the _.

I can see, though, that if you're using automated tools to generate your
code, you need to follow the tool's expected naming convention.  Obviously, I
haven't used any.  I write everything from scratch.

I'm assuming the .NET naming convention is published on MS's web site
somewhere, like the VB6 convention was, so I should be able to find it.

Thanks again for your response.  I usually work by myself or with people
with less experience than me so the rest of the world can just fly by me and
I'll never even notice.

-Beth

Thanks again for replying, sloan.

Thanks again for replying, sloan.

I keep seeing people using classes to represent business content, like:
public class CustomerDALC
{ public CustomerDALC()
public string CreateCustomer(string name, string address, string city,
string state,
string zip)

which I don't think should be in code because it's outside the
responsibility of the IT department.  The business should be able to change
the structure of their content (by adding a phone field to the customer
table, for example) without affecting any source code, in my opinion.

When they change the structure of a business content table in my
application, the code doesn't change, but I change records in a couple of
tables I created for the purpose of interpreting data in their content tables.

For some projects, I can hand off the responsibility for maintaining
business content rules to business owners, and they can configure their app
to meet their business needs as they change over time.  I have no interest in
maintaining their content.

A different approach, I know.  Most examples I've seen code business content
instead of keeping it separate.

I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the code
to VB.NET

It's already in VB.NET.  By 'translating' I'm assuming you mean something
other than changing the naming convention, which I wouldn't learn a whole lot
from.

Please forgive my ignorance, I'm a little slow.

Oh, and I do intend to use Lists of class types instead of collections to
strengthen the data types.  I knew I could do that, just hadn't spent the
time to look up how.  Figured I'd meet the business need with collections
first.

Thanks again for your response,

-Beth

Beth,Don't mix up OO and OOP, OOP is to be able to use small memory with tons

Beth,

Don't mix up OO and OOP, OOP is to be able to use small memory with tons of
classes.

At the moment I am busy with doing some corrections on a VB6 program that
was made by others 8 years ago. It is nicely done and still it is a hell to
do as you are used to .Net programming languages.

In OOP you create small methods which can be seen on them self and as you
use them more by making classes of them.
Try it, add the end you will think, how could I ever do it on the classic
way.

I was in past a devoted follower of Dijkstra, but that was in the time that
there were no PC's, mobiles, Internet and more of that stuff.

Cor

Thanks for your response, Cor.You're right, OO is one big thing to me.

Thanks for your response, Cor.

You're right, OO is one big thing to me.  I don't know enough about it to
break it out into additional descriptive letters.

re: It is nicely done and still it is a hell to do as you are used to .Net
programming languages.
You mean converting an application following structured programming methods
to one following OO(x) methods is a pain because you have to do all of the
object analysis?
I thought people rewrote those things from scratch instead of trying to do a
conversion.

I'd like to understand when you say:
In OOP you create small methods which can be seen on them self and as you
use them more by making classes of them.

but I don't.  Can you say that in a different way?

Are you talking about methods written independently of classes which provide
functions independent of the type of their caller?

Thanks again,

-Beth

Tom,I tried to change it so that the new instance of clsData was created in

Tom,

I tried to change it so that the new instance of clsData was created in the
private constructor instead of the declaration, but that didn't work.

Guess declarations are evaluated before the constructor executes…

Thanks again for the help,

-Beth

Sharing an instance of an object across classes

//I'm not sure what you mean when you say:
you could learn an awful lot by just taking a day and translating the code
to VB.NET//

Take the code sample at the blog entry I provided..and translating it to
VB.NET.


http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
The downloadable c# code.  There is a "download here" link there.

You can do the "2.0" version ... however, timewise the 1.1 version will be
faster to translate.

Hi, again, sloan.Thanks for sharing your sample code.

Hi, again, sloan.

Thanks for sharing your sample code.
I see a lot of references in the code to business concepts like customers
and orders.

I avoid modeling business objects in source code, because the objects change
at whim.  They're owned by the business, after all, not by me.  If the
business needs to change something about the attributes or behavior of their
objects, ideally, I'd like them to do it with an administrative application
allowing them to configure the deployed application in a way that meets their
business needs.  If they're not up to that, I can make their changes on the
back end myself.  The source code doesn't have to change.

It's not that I don't get what you're saying, but the cost of implemeting
business objects in code is too high, in my opinion.

But a lot of other people seem to be doing it, so I guess I can't expect
most people to understand what I'm doing.

Thanks for taking a shot at it, anyways.

-Beth

The ~only~ tidbit / hint I can give you is the Profile object for the

The ~only~ tidbit / hint I can give you is the Profile object for the
MembershipProvider.

Somehow ( and I don't know how) they're able to tack on properties
dynamically to a User.

For instance, you could decide that you needed to track
height/weight/favorite color at your website.
They are able to pull off some dynamic property voodoo stuff .........

You are correct, I don't deal with this situation.

http://msdn.microsoft.com/en-us/library/d8b58y5d.aspx

I have zero idea whether that'll help you or not.

Beth,I can of course not give here a kind of course, however assume that this

Beth,

I can of course not give here a kind of course, however assume that this is

Public Class Sample
Private Sub Start()
Dim theSalaryMethod As New Salary
Dim PersonsSalary
PersonsSalary  =  theSalaryMethod.WeekSalary(1, 40)
End Sub
End Class
///
What you see above is instancing (creating) an object in your program which
has as template the class salary.

Somewhere else you have a class salary, by instance in your business layer
or as complete seperated project.
That Salary class uses again an object that is instanced (not showed) in by
instance a datalayer to get Employee information that contains his/here hour
rate.

\\\
End Class
Public Class Salary
Private ReadOnly Property HourRate() As Decimal
Get
Return 100 'Normal this will be something from another
'class which returns by instance employee.information
End Get
End Property

Public Function WeekSalary(ByVal EmployeeNumber As Integer, ByVal
TotalWeekHours As Integer) As Decimal
Return HourRate * TotalWeekHours
End Function
End Class
///

There are many advantages, you can create one method that you can use
everywhere to calculate however more important is that you can create small
parts that are easily to maintain by someone else as you do it well you see
direct what is done.

And beside that, the objects are automaticly cleaned up as they are not
needed anymore. You mostly don't have to do anything for that because that
is why .Net is called managed code.

I spare you the facts about dispose other wise some people think they have
to correct that. Simply look than at the samples at MSDN. You seldom see in
those the dispose used.

Cor

Hi again, sloan.

Hi again, sloan.

To me, that link looks like it's describing a place to store user preferences.
It wouldn't be appropriate to store business objects, in other words.

If you're curious, I can give you more information about how I do it.
It basically involves 2 tables, a bunch of views, stored procedures, and
functions, and code which builds SQL syntax dynamically.

Not for everyone, I'm sure, but I like it.

Keeps the back end separate from the code.

Thanks again for your help and interest,

-Beth

Hi, again, Michel.

Hi, again, Michel.

I probably should have asked this sooner, but when you say:
There is nothing wrong with passing an initialized class as a parameter to
another class even if you pass it as byvalue ( wich i would recomend )

I don't understand why you recommend passing objects ByValue if that and
ByRef only pass references to the objects.  What do you see as the advantage
of using ByVal over ByRef for object parameters?

I was taught a long time ago to pass variables containing large amounts of
data to routines by reference so the calling routine doesn't create a second
copy.

If there's no new copy created of an object variable parameter, I don't see
how it can matter which one you use.

Or is it more of a convention thing?  Pass ByVal whenever you can?

Thanks for helping me understand,

-Beth

Sharing an instance of an object across classes

Wandering OT, but see the section "Specifying a Profile Provider" in
http://aspnet.4guysfromrolla.com/articles/101106-1.aspx

Andrew

Hi, again, Cor.

Hi, again, Cor.

Thanks for the demonstration of coding with classes, creating instances, and
calling methods.
I thought I was doing that, but I must be doing something wrong.

I'm sure my error jumped right out at you- could you review my code below
and tell me which piece I should rewrite?  You don't have to tell me how,
just where. I don't really understand sloan's comments, either, and please
forgive the code's naming convention.

Thanks again for your help,

-Beth
--------


--------

You're tied your clsUsers to always coming from the database.

The business objects and collections are seperate from the code that creates
them.
The code that creates them can use database related calls, OR (better) the
business objects and collections can be created totally independant of a
database. (One reason?  UnitTesting)
---------

Hello Beth ,A reference type is always manipulated using pointers , if you pas

Hello Beth ,


A reference type is always manipulated using pointers , if you pas a
reference by value  what you are really doing is passing the pointer by
value not the variable itself , this means you can , in fact make changes to
the data and those changes are reflected back in the calling routine .

What happens if you pass a reference type By Ref ?   , Well it does exactly
what it says it makes a new reference variabel  that points to the reference
variabel that points to the data . so you get a pointer to a pointer ! :-)
Lucky for us VB.Net handles all the complicated stuff behind the scenes ,
but if you toss the thing around in your program things can get pretty nasty
.

Although you would probably never notice annything ,  typically you should
always pass reference variables by value just be aware that they can get
modified


For value types it behaves as you would have expected it to behave ,,
Although i never use it in my coding as it is a pain to debug in complex
code i encapsulate everything in objects and read the values through
properties
but okay that is a whole different story :-)


HTH

Michel Posseth [MCP]
http://www.vbdotnetcoder.com

Beth,Adding something to the correct reply from Michel (with the exception

Beth,

Adding something to the correct reply from Michel (with the exception what I
understand of his boxing, but he tells that this is his own method, so not
discussa ble) :-)

The ByRef is for when the referenced object is immutable. Like a string or
an original array

Have a look at this sample code

dim a = "Michel"
myMethod(a)

Private Sub myMethod(byXXX a as string)
'Asume this method contains only
a = "Beth"

This creates a new object with a new reference.

'As the referenence is byVal to object "Michel",  then that will not change
the reference to Michel, the reference stays the same
'As you do this ByRef, then the reference which was pointing to "Michel"
will be changed to new reference to "Beth"

And the object to Michel will automaticly be removed as the Garbage
Collector starts working by instance as your video controler does some
screen refreshing while the available memory is low.

Cor.

Sharing an instance of an object across classes

On Oct 29, 11:04=A0pm, "Cor Ligthert[MVP]" <Notmyfirstn...@planet.nl>
se

I try to help anyone.  I knew that the code she was presenting was not
on a deadline.  I try to point out things that I don't feel are best
practice, but in a careful way.  For many people, they just need to
get the job done.


--
Tom Shelton

Thanks, Michel.I think I get it now.

Thanks, Michel.

I think I get it now.

When passing a variable created by instantiating a class, there's never
another copy made, so passing it ByRef just introduces an additional layer of
indirection.
Passing the same instance of a variable to multiple routines just creates
multiple pointers to the same variable in memory, so everyone sees everyone
else's changes.

When you say:
For value types it behaves as you would have expected it to behave ,,
Although i never use it in my coding
are you saying you only pass objects as parameters?

If so, that's interesting, but we don't have to go into the details of why
today.

Thanks again,

-Beth

OK, Cor, pardon my considerable ignorance, but I thought the whole question

OK, Cor, pardon my considerable ignorance, but I thought the whole question
was what is the value of 'a' AFTER myMethod is called.

If you have:
dim a = "Michel"
myMethod(a)
msgbox("a is " & a)

and myMethod is:
Private Sub myMethod(byVal a as string)
a = "Beth"

then the message says 'a is Michel'.  If 'a' is passed byRef, the message
says 'a is Beth'.  When 'a' is passed byVal, then a second copy of 'a' is
created in memory, instead of a pointer to the existing variable declared by
the caller when it's passed byRef.

Both variables would be marked (or whatever) for garbage collection when
they fell out of scope, although the ByRef variable can't be marked as trash
when it falls out of scope in myMethod because the caller still has a
reference to it, so it will fall out of scope within the calling routine.
The 'a' passed byVal will fall out of scope within myMethod, along with all
the other variables declared in myMethod.

So you use byVal when you want the variable to remain immutable (unchanged,
or not mutating,) and byRef when you want the variable used as an output
parameter.
But I think you know that, so when you say:
ByRef is for when the referenced object is immutable

you're referring to the pointer being immutable, not the value.  Although I
thought pointers were always immutable, and it was just a question of whether
or not another one gets created.

That's my understanding, anyways, but if I'm off somewhere, feel free to let
me know.

Thanks again for your response,

-Beth

The object is immutable, everytime a simple change is made in a string, a new

The object is immutable, everytime a simple change is made in a string, a
new string is created with in fact a new reference.

That is the reason that changing a string can cost more in time and memory
than a string builder.

You are mixing up the ByVal and the ByRef from the time there were no
objects.

Cor

OK, I thought when you said 'referenced object,' you were referring to an

OK, I thought when you said 'referenced object,' you were referring to an
instance of a class, not any variable in memory.

I could very well be mixing up the byVal/byRef functions from when there
were no objects, I just know if I want an output parameter, for a string or
not, I need to use byRef instead of byVal.

So your 'immutable' comment threw me, but that's ok.  There's a bunch of
stuff going on under the hood I try to remain blissfully ignorant about.

Thanks again for your replies,

-Beth