OOP: Best practice?

[Fredrik Melin]

I have a "Inventory" Object that contains the product and all its fields.

The problem is that I am getting soooooo many functions under main Inventory
class so it becames impossible to initalize a new programmer into this code.

For sample, I have Add_AllowAccess, Add_DisallowAccess, Remove_AllowAccess,
Remove_DisallowAccess, Get_AllowAccess, Get_DisallowAccess (this is only a
sample)

I would really like
Inventory.Access.Allow.Add
Or
Inventory.Access.Add(Enum.Allow...)
(sometimes however one simular function might need diffrent parameters then
the other...)
My questions are

1. Is the best practice to do it the way I described above
(Inventory.Access.Add etc)

2. Add_AllowAccess() needs access to Inventory Object, Should I create
subclasses only containing methods, and use a Parent object that points to
Main Inventory class?

3. Or is there another way to do this all together?

- Fredrik

[tomb]

Fredrik Melin wrote:

I have a "Inventory" Object that contains the product and all its fields.

For sample, I have Add_AllowAccess, Add_DisallowAccess, Remove_AllowAccess,
Remove_DisallowAccess, Get_AllowAccess, Get_DisallowAccess (this is only a
sample)
1. Is the best practice to do it the way I described above
(Inventory.Access.Add etc)
Since you are talking about permissions, and this seems to be a somewhat
large project, I prefer to use an actual permissions object, which may
or may not be combined with the user object. Then, if the user has
permission to do something with the Inventory object, then he does it.

Because I have been programming since the days of bit flags, that is
what I sometimes use, but that isn't necessary. The user or permissions
object can then be queried, in the form of a property, for a permission
which can return true, false, or some level ( some systems allow for a
lesser user to view, but not make changes ). The benefit of keeping
permissions as a class is that you can then just add more permissions to
it for other areas of the applicaiton, rather than writing permissions
aspects to each section.

As far as best practice, my experience is the method that makes for less
complication, ease of re-use, less bloated code, and faster execution is
what I adopt as the best practice.

Tom
2. Add_AllowAccess() needs access to Inventory Object, Should I create
subclasses only containing methods, and use a Parent object that points to
Main Inventory class?

3. Or is there another way to do this all together?

- Fredrik

[Fredrik Melin]

Yes, its a very large project.

This is just a sample of some of the functions, this access is actually
which customers has the access to see the product on the webserver.

But we have tons of other types of functions, like

Add_SalesStatistics
Remove_SalesStatistics
Update_SalesStatistics
.....
and so on, its functions that are used in a certain conditions, could be
when you call .Invoice on the Invoice object

but still, it cloggs up the code if you look at it as a "external"
programmer.

Sure I can rename it and use enum for Add/Remove/Update, but then what Shall
I name it?

"tomb" <to**@technetcenter.com> wrote in message
news:5P***************@bignews7.bellsouth.net...

Fredrik Melin wrote:

I have a "Inventory" Object that contains the product and all its fields.

For sample, I have Add_AllowAccess, Add_DisallowAccess,
Remove_AllowAccess, Remove_DisallowAccess, Get_AllowAccess,
Get_DisallowAccess (this is only a sample)
1. Is the best practice to do it the way I described above
(Inventory.Access.Add etc)

Since you are talking about permissions, and this seems to be a somewhat
large project, I prefer to use an actual permissions object, which may or
may not be combined with the user object. Then, if the user has
permission to do something with the Inventory object, then he does it.
Because I have been programming since the days of bit flags, that is what
I sometimes use, but that isn't necessary. The user or permissions object
can then be queried, in the form of a property, for a permission which can
return true, false, or some level ( some systems allow for a lesser user
to view, but not make changes ). The benefit of keeping permissions as a
class is that you can then just add more permissions to it for other areas
of the applicaiton, rather than writing permissions aspects to each
section.

As far as best practice, my experience is the method that makes for less
complication, ease of re-use, less bloated code, and faster execution is
what I adopt as the best practice.

Tom

2. Add_AllowAccess() needs access to Inventory Object, Should I create
subclasses only containing methods, and use a Parent object that points to
Main Inventory class?

3. Or is there another way to do this all together?

- Fredrik

[Fredrik Melin]

And to add on to this

I also have

Add_OrderStatistics
Remove_OrderStatistics
Update_OrderStatistics

So Inventory.Statistics.Order and Inventory.Statistics.Sales would have been
nice :)
"Fredrik Melin" <me*@no-spam.dacsa-remove-this.net> wrote in message
news:1p********************@giganews.com...

Yes, its a very large project.

This is just a sample of some of the functions, this access is actually
which customers has the access to see the product on the webserver.

But we have tons of other types of functions, like

Add_SalesStatistics
Remove_SalesStatistics
Update_SalesStatistics
....
and so on, its functions that are used in a certain conditions, could be
when you call .Invoice on the Invoice object

but still, it cloggs up the code if you look at it as a "external"
programmer.

Sure I can rename it and use enum for Add/Remove/Update, but then what
Shall I name it?

"tomb" <to**@technetcenter.com> wrote in message
news:5P***************@bignews7.bellsouth.net...

Fredrik Melin wrote:

I have a "Inventory" Object that contains the product and all its fields.

For sample, I have Add_AllowAccess, Add_DisallowAccess,
Remove_AllowAccess, Remove_DisallowAccess, Get_AllowAccess,
Get_DisallowAccess (this is only a sample)
1. Is the best practice to do it the way I described above
(Inventory.Access.Add etc)

Since you are talking about permissions, and this seems to be a somewhat
large project, I prefer to use an actual permissions object, which may or
may not be combined with the user object. Then, if the user has
permission to do something with the Inventory object, then he does it.
Because I have been programming since the days of bit flags, that is what
I sometimes use, but that isn't necessary. The user or permissions
object can then be queried, in the form of a property, for a permission
which can return true, false, or some level ( some systems allow for a
lesser user to view, but not make changes ). The benefit of keeping
permissions as a class is that you can then just add more permissions to
it for other areas of the applicaiton, rather than writing permissions
aspects to each section.

As far as best practice, my experience is the method that makes for less
complication, ease of re-use, less bloated code, and faster execution is
what I adopt as the best practice.

Tom

2. Add_AllowAccess() needs access to Inventory Object, Should I create
subclasses only containing methods, and use a Parent object that points
to Main Inventory class?

3. Or is there another way to do this all together?

- Fredrik

[Cor Ligthert [MVP]]

Frederik,

We see off course only a part of your code, however don't you have a
SalesStatics or AllowAcces Class.

Than it could be as this.
\\\
Public Class AllowAccess
Public Sub New
mAllow = false 'only for the sample normal this is not necessary
End Sub
private boolean mAllow
public property Allow as Boolean
Get
mAllow = false
End Get
Set(ByVal Value As Boolean)
return mAllow
End Set
End Property
///
And than while in your whatever class is the same but than
public class Whatever
private mAllowAccess as AllowAcces
public property AllowAccess as AllowAccess
bla bla
end Class
.....
whatever.AllowAccess = New AllowAcces
whatever.AllowAccess.Allow = true
and to remove it
whatever.AllowAccess = nothing
I hope this helps,

Cor

[Fredrik Melin]

Here is some sample code of my Add_SalesStatistics

Public Function Add_SalesStatistics(ByVal quantity As Long, ByVal
invoiceRowID As Long, ByRef dbTrans As SqlClient.SqlTransaction) As Boolean
Dim dbConn As SqlClient.SqlConnection
Dim cmSQL As SqlClient.SqlCommand
Try

dbConn = dbTrans.Connection
cmSQL = New SqlClient.SqlCommand("", dbConn)
cmSQL.Connection = dbConn
cmSQL.Transaction = dbTrans

cmSQL.CommandText = "INSERT INTO INVENTORY_SALES_STATISTICS
(PRODUCT_ID, INVOICE_ROW_ID, QUANTITY, DATE_SOLD) VALUES (@PRODUCT_ID,
@INVOICE_ROW_ID, @QUANTITY, @DATE_SOLD)"
cmSQL.Parameters.Add("@PRODUCT_ID", SqlDbType.VarChar).Value =
sProduct_ID
cmSQL.Parameters.Add("@INVOICE_ROW_ID", SqlDbType.Decimal).Value
= invoiceRowID
cmSQL.Parameters.Add("@QUANTITY", SqlDbType.Decimal).Value =
quantity
cmSQL.Parameters.Add("@DATE_SOLD", SqlDbType.DateTime).Value =
DSO.Globals.SystemFunctions.SQLServerDate.Date
If cmSQL.ExecuteNonQuery() > 0 Then Return True

Catch ex As Exception
DSO.Globals.ErrReport.RegisterError(ex, , Me)
Finally
cmSQL.Dispose()
End Try
End Function
As you see, its a little more complex that I can solve in a property, It
also address code from Main inventory class (sProduct_ID)

So my idea is maybe to do

Public Class Inventory
Private mclsStatistics as clsStatistics
Public Reaonly Property Statistics as clsStatistics
Get
If mclsStatistics Is Nothing Then mclsStatistics = New
clsStatistics(Me)
End Get
Return mclsStatistics
End Property
Public Class clsStatistics
Private mParent as Inventory

Public Sub New (ParentObject as Inventory)
mParent = ParentObject
End Sub

Public Function Add(enum SalesOrOrder, invoiceRowID......) as
Boolean
... code
End Function

End Class
....
End Class

Which would get me Inventory.Statistics.Add

but is that the correct way to do it?

- Fredrik
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Frederik,

We see off course only a part of your code, however don't you have a
SalesStatics or AllowAcces Class.

Than it could be as this.
\\\
Public Class AllowAccess
Public Sub New
mAllow = false 'only for the sample normal this is not necessary
End Sub
private boolean mAllow
public property Allow as Boolean
Get
mAllow = false
End Get
Set(ByVal Value As Boolean)
return mAllow
End Set
End Property
///
And than while in your whatever class is the same but than
public class Whatever
private mAllowAccess as AllowAcces
public property AllowAccess as AllowAccess
bla bla
end Class
....
whatever.AllowAccess = New AllowAcces
whatever.AllowAccess.Allow = true
and to remove it
whatever.AllowAccess = nothing
I hope this helps,

Cor

[Cor Ligthert [MVP]]

Frederik,

Did you had a look at the standard generated code. Maybe is a problem that
it is in version 2.0 more logical and completely different done.

However, with 1.1 if you just try this to do. (Probably you know all however
when not)

Open a project and add an item component
Use for that the a dataadapterwizard from the toolbox
After doing all what there is needed (everything standard, change nothing
Right click on than on the icon dataadapter and click on generate dataset

In the component you see than all code generated when you open the plus.

If you in solution explorer open tell "show all files in top" than you see a
completly strongly typed class generated with the name dataset1.vb

You can open it and look to it, it are just all kind of OOP stronly typed
classes generated.

Not to use it however to get the idea how it is done.

I hope this helps,

Cor

[Fredrik Melin]

Thanks, very nice tip!
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:O1*************@TK2MSFTNGP10.phx.gbl...

Frederik,

Did you had a look at the standard generated code. Maybe is a problem that
it is in version 2.0 more logical and completely different done.

However, with 1.1 if you just try this to do. (Probably you know all
however when not)

Open a project and add an item component
Use for that the a dataadapterwizard from the toolbox
After doing all what there is needed (everything standard, change nothing
Right click on than on the icon dataadapter and click on generate dataset

In the component you see than all code generated when you open the plus.

If you in solution explorer open tell "show all files in top" than you see
a completly strongly typed class generated with the name dataset1.vb

You can open it and look to it, it are just all kind of OOP stronly typed
classes generated.

Not to use it however to get the idea how it is done.

I hope this helps,

Cor

[TrtnJohn]

You are missing the basic rules of encapsulation. There are 2 guidelines
that I like to follow. They are:

1) Low Coupling:
Coupling is a measure of how strongly one class is connected to, has
knowledge of, or relies on other classes in the system. You should try and
minimize this.

High Cohesion:
Cohesion is a measure of how strongly related and focused the responsibility
of a class is. You want to make sure your the methods you add remain
cohesive to what the class is supposed to encapsulate.

Picking the right classes that follow these rules and solve your problems is
the hard part. There are numerous books out there describing multiple
techniques to actually do this. These processes can get highly involved.
You typically can't just start coding and get to a good object oriented
design. Instead you need to plan ahead. UML and case tools are designed to
help you do this. Think of the analogy of building a house. You typically
don't just grab wood, hammer, and nails and have at it. Instead, you need to
draw and plan the entire structure first. Start building and then re-adjust
your plans when issues arise. Software is the same.

"Fredrik Melin" wrote:

I have a "Inventory" Object that contains the product and all its fields.

The problem is that I am getting soooooo many functions under main Inventory
class so it becames impossible to initalize a new programmer into this code.

For sample, I have Add_AllowAccess, Add_DisallowAccess, Remove_AllowAccess,
Remove_DisallowAccess, Get_AllowAccess, Get_DisallowAccess (this is only a
sample)

I would really like
Inventory.Access.Allow.Add
Or
Inventory.Access.Add(Enum.Allow...)
(sometimes however one simular function might need diffrent parameters then
the other...)
My questions are

1. Is the best practice to do it the way I described above
(Inventory.Access.Add etc)

2. Add_AllowAccess() needs access to Inventory Object, Should I create
subclasses only containing methods, and use a Parent object that points to
Main Inventory class?

3. Or is there another way to do this all together?

- Fredrik