Sharing an instance of an object across classes

[sloan]

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.

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.

 

[Beth]

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.

 

[Beth]

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

 

[Beth]

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

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]

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

 

[Tom Shelton]

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.

I try to help anyone. I knew that the code she was presenting was not
"best practice" material, but many people have jobs and have to work
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.

 

[Beth]

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

 

[Cor Ligthert[MVP]]

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

 

[Beth]

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

 

[Beth]

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

 

[sloan]

//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.

 

[Beth]

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

 

[sloan]

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.

 

[Cor Ligthert[MVP]]

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

 

[Beth]

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

 

[Beth]

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

 

[Andrew Morton]

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.

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

Andrew

 

[Beth]

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
--------

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

--------

:
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)
---------

 

[Michel Posseth]

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

 

[Cor Ligthert[MVP]]

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.

 

[Beth]

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

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

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