Best Practice - OO 
Author Message
 Best Practice - OO

Hi All,

I have a fundemental OO design question. In a typical 'shopping cart'
scenerio (ASP.NET), what is the best practice in terms or instance/static
members?
I have a class called AccountDB which contains all the functions to
add/remove/edit items.

Should I:

1)

- Set all methods as instance members in the AccountDB class
- Then Declare AccountDB in the declarations section of the calling class
- Create a new instance of AccountDB in the Page_Load
- Use this instance to perform any functions during the lifetime of the
page.

public class AccountDB
{
    public void DoSomething()

Quote:
}

public class CodeBehind
{
    AccountDB aAccountDBInstance
    public void Page_Load
    {
        aAccountDBInstance = new AccountDB()
    }
    public void SaveButtonClick()
    {
        aAccountDBInstance .DoSimething()
    }

Quote:
}

2)

- Set all methods as instance members in the AccountDB class
- Create a new instance of the AccountDB class when performing any of its
functions on the calling class

public class AccountDB
{
    public void DoSomething()

Quote:
}

public class CodeBehind
{
    public void SaveButtonClick()
    {
        AccountDB aAccountDBInstance = new AccountDB()
        aAccountDBInstance .DoSimething()
    }

Quote:
}

3)

- Set all methods as static members in the AccountDB class.
- Call these methods from the calling class

public class AccountDB
{
    public static void DoSomething()

Quote:
}

public class CodeBehind
{
    public void SaveButtonClick()
    {
           AccountDB.DoSimething()
    }

Quote:
}

Any thoughts appreciated.

Regards, Andrew



Sat, 25 Jun 2005 09:06:37 GMT  
 Best Practice - OO
Andrew, honestly, both are valid and workable designs.  If you want to be
the 'most OO' you should go with 1 or 2.  I would only go with #1 if you
knew the page was supposed to create a new account from scratch, why create
the object until you are sure you need it?  If it's an existing account load
you're going to need to load from a DB (probably based on some user
parameters).  Regardless, both #1 and #2 are good/similar object based
designs.

--
Greg Ewing [MVP]
http://www.claritycon.com


Quote:
> Hi All,

> I have a fundemental OO design question. In a typical 'shopping cart'
> scenerio (ASP.NET), what is the best practice in terms or instance/static
> members?
> I have a class called AccountDB which contains all the functions to
> add/remove/edit items.

> Should I:

> 1)

> - Set all methods as instance members in the AccountDB class
> - Then Declare AccountDB in the declarations section of the calling class
> - Create a new instance of AccountDB in the Page_Load
> - Use this instance to perform any functions during the lifetime of the
> page.

> public class AccountDB
> {
>     public void DoSomething()
> }
> public class CodeBehind
> {
>     AccountDB aAccountDBInstance
>     public void Page_Load
>     {
>         aAccountDBInstance = new AccountDB()
>     }
>     public void SaveButtonClick()
>     {
>         aAccountDBInstance .DoSimething()
>     }
> }

> 2)

> - Set all methods as instance members in the AccountDB class
> - Create a new instance of the AccountDB class when performing any of its
> functions on the calling class

> public class AccountDB
> {
>     public void DoSomething()
> }
> public class CodeBehind
> {
>     public void SaveButtonClick()
>     {
>         AccountDB aAccountDBInstance = new AccountDB()
>         aAccountDBInstance .DoSimething()
>     }
> }

> 3)

> - Set all methods as static members in the AccountDB class.
> - Call these methods from the calling class

> public class AccountDB
> {
>     public static void DoSomething()
> }
> public class CodeBehind
> {
>     public void SaveButtonClick()
>     {
>            AccountDB.DoSimething()
>     }
> }

> Any thoughts appreciated.

> Regards, Andrew



Sat, 25 Jun 2005 11:20:49 GMT  
 Best Practice - OO
Thanks for your reply Greg.

So, calling static methods is definitely not a good idea?
That seems to be the simplest to me, and it doesn't create any unnecessary
overhead by allocating space on the stack for each instance of the class
that gets created.
Or should I not worry to much about that?

BTW, .NET has a built in garbage collecter doesn't it, so I don't have to
destroy my class instances?

Cheers,

Andrew



Quote:
> Andrew, honestly, both are valid and workable designs.  If you want to be
> the 'most OO' you should go with 1 or 2.  I would only go with #1 if you
> knew the page was supposed to create a new account from scratch, why
create
> the object until you are sure you need it?  If it's an existing account
load
> you're going to need to load from a DB (probably based on some user
> parameters).  Regardless, both #1 and #2 are good/similar object based
> designs.

> --
> Greg Ewing [MVP]
> http://www.claritycon.com



> > Hi All,

> > I have a fundemental OO design question. In a typical 'shopping cart'
> > scenerio (ASP.NET), what is the best practice in terms or
instance/static
> > members?
> > I have a class called AccountDB which contains all the functions to
> > add/remove/edit items.

> > Should I:

> > 1)

> > - Set all methods as instance members in the AccountDB class
> > - Then Declare AccountDB in the declarations section of the calling
class
> > - Create a new instance of AccountDB in the Page_Load
> > - Use this instance to perform any functions during the lifetime of the
> > page.

> > public class AccountDB
> > {
> >     public void DoSomething()
> > }
> > public class CodeBehind
> > {
> >     AccountDB aAccountDBInstance
> >     public void Page_Load
> >     {
> >         aAccountDBInstance = new AccountDB()
> >     }
> >     public void SaveButtonClick()
> >     {
> >         aAccountDBInstance .DoSimething()
> >     }
> > }

> > 2)

> > - Set all methods as instance members in the AccountDB class
> > - Create a new instance of the AccountDB class when performing any of
its
> > functions on the calling class

> > public class AccountDB
> > {
> >     public void DoSomething()
> > }
> > public class CodeBehind
> > {
> >     public void SaveButtonClick()
> >     {
> >         AccountDB aAccountDBInstance = new AccountDB()
> >         aAccountDBInstance .DoSimething()
> >     }
> > }

> > 3)

> > - Set all methods as static members in the AccountDB class.
> > - Call these methods from the calling class

> > public class AccountDB
> > {
> >     public static void DoSomething()
> > }
> > public class CodeBehind
> > {
> >     public void SaveButtonClick()
> >     {
> >            AccountDB.DoSimething()
> >     }
> > }

> > Any thoughts appreciated.

> > Regards, Andrew



Sat, 25 Jun 2005 11:49:51 GMT  
 Best Practice - OO

Andrew, static methods aren't bad but usually not strictly an OO design
pattern.  You asked about OO designs so that's what I recommended.  :-)
There are arguments all around about whether a strict OO design is really
worth the work.  Your account sample sounds like a good opportunity to go
OO, create an Account object and hang all of the necessary methods off of
that object.  Then once you create or load your account object you can just
call methods to update/save it.

Yea, .Net has GC so you don't have to clean up afteryourself (unless you are
using unmanaged resources (from API calls for instance))

--
Greg Ewing [MVP]
http://www.claritycon.com


Quote:
> Thanks for your reply Greg.

> So, calling static methods is definitely not a good idea?
> That seems to be the simplest to me, and it doesn't create any unnecessary
> overhead by allocating space on the stack for each instance of the class
> that gets created.
> Or should I not worry to much about that?

> BTW, .NET has a built in garbage collecter doesn't it, so I don't have to
> destroy my class instances?

> Cheers,

> Andrew



> > Andrew, honestly, both are valid and workable designs.  If you want to
be
> > the 'most OO' you should go with 1 or 2.  I would only go with #1 if you
> > knew the page was supposed to create a new account from scratch, why
> create
> > the object until you are sure you need it?  If it's an existing account
> load
> > you're going to need to load from a DB (probably based on some user
> > parameters).  Regardless, both #1 and #2 are good/similar object based
> > designs.

> > --
> > Greg Ewing [MVP]
> > http://www.claritycon.com



> > > Hi All,

> > > I have a fundemental OO design question. In a typical 'shopping cart'
> > > scenerio (ASP.NET), what is the best practice in terms or
> instance/static
> > > members?
> > > I have a class called AccountDB which contains all the functions to
> > > add/remove/edit items.

> > > Should I:

> > > 1)

> > > - Set all methods as instance members in the AccountDB class
> > > - Then Declare AccountDB in the declarations section of the calling
> class
> > > - Create a new instance of AccountDB in the Page_Load
> > > - Use this instance to perform any functions during the lifetime of
the
> > > page.

> > > public class AccountDB
> > > {
> > >     public void DoSomething()
> > > }
> > > public class CodeBehind
> > > {
> > >     AccountDB aAccountDBInstance
> > >     public void Page_Load
> > >     {
> > >         aAccountDBInstance = new AccountDB()
> > >     }
> > >     public void SaveButtonClick()
> > >     {
> > >         aAccountDBInstance .DoSimething()
> > >     }
> > > }

> > > 2)

> > > - Set all methods as instance members in the AccountDB class
> > > - Create a new instance of the AccountDB class when performing any of
> its
> > > functions on the calling class

> > > public class AccountDB
> > > {
> > >     public void DoSomething()
> > > }
> > > public class CodeBehind
> > > {
> > >     public void SaveButtonClick()
> > >     {
> > >         AccountDB aAccountDBInstance = new AccountDB()
> > >         aAccountDBInstance .DoSimething()
> > >     }
> > > }

> > > 3)

> > > - Set all methods as static members in the AccountDB class.
> > > - Call these methods from the calling class

> > > public class AccountDB
> > > {
> > >     public static void DoSomething()
> > > }
> > > public class CodeBehind
> > > {
> > >     public void SaveButtonClick()
> > >     {
> > >            AccountDB.DoSimething()
> > >     }
> > > }

> > > Any thoughts appreciated.

> > > Regards, Andrew



Sat, 25 Jun 2005 12:06:31 GMT  
 Best Practice - OO
Andrew,

1) Regarding your static vs. instance methods and members, it really depends
on the situation. In some cases, I use static members/methods, while in
other cases, I use instance member/methods. As a general rule, you should do
the following:

- Declare all members and methods relating to a single instance of the class
as instance members and methods.
- Declare all members and methods relating to all instances of the class as
static members and methods.

To these rules, I personally add the following one:

- Declare all members and methods relating to a collection of objects of the
class as static members and methods.

To take your Account class example, I can define a Balance property and a
LoadFromDB method. The balance represent the real-world dollar balance of
the account. It makes sense to me to declare this property as an instance
property, as I would assume that each account has its own balance. If my
LoadFromDB method is reading the values of the properties (in this case the
Balance) from the database and assigns these values to the properties, it
makes sense to me to declare this method as an instance method. Similarly,
if I want to implement a method that will add a specified amount to the
balance of the account, I will declare it as an instance method, because it
relates to an instance property of the class. The Balance property is
related to a specific account, not to all objects of type Account, unless
all your accounts share the same balance?

On the other hand, if I implement a GetAllAccounts method for my class, with
the purpose of returning a set of accounts from my database or other
persistence mechanism, I will declare that method as a static method and
return a dataset or an arraylist. Similarly, if all my objects share the
same connection string to access the database, I might choose to declare a
ConnectionString property as a static property.

Remember that static members are shared among all objects of the class. I
believe that the example of the Balance for an Account class is a good
example. Most real-world implementations of an Account would require that
each account has its own balance. If you declare the Balance property as
static, all accounts would have the same balance. If you need to transfer
money from one account to another one, for example, you will need to use two
Account objects. If they share the same balance, you cannot transfer the
amount between the 2 objects.

In addition to all this, there are some design patterns that require the use
of static members, such as the Singleton pattern (see the GoF patterns).
This pattern is very common and guarantees that each time you try to
instantiate an object of the class, you will always get the same object.
This is an excellent pattern for global classes such as those representing
the application's configuration settings for example.

2) Regarding the GC, it is true that normally, you should not have to clean
after yourself. However, in practice, this is not as black and white as it
seems. For example, if you open a database connection at some point in time
in your class, but you do not close it, then you let the GC dispose of the
class, your OledbConnection or SqlConnection object will certainly be
disposed by the GC, but the actual connection to the database will not be
closed, therefore using unnecessary resources indefinitely.

As the title of your message is "best practice", I can only remind you that
the best practice is to always dispose of the objects you instantiate. The
best way to do this is to assign Nothing to your objects when you do not
need them anymore. In some cases, as mentionned above for the database
connection classes provided by .NET, you need first to call another method
(the Close method in that case), before assign Nothing to the object.

Just my 2 cents worth.

Gilles


Quote:
> Thanks for your reply Greg.

> So, calling static methods is definitely not a good idea?
> That seems to be the simplest to me, and it doesn't create any unnecessary
> overhead by allocating space on the stack for each instance of the class
> that gets created.
> Or should I not worry to much about that?

> BTW, .NET has a built in garbage collecter doesn't it, so I don't have to
> destroy my class instances?

> Cheers,

> Andrew



> > Andrew, honestly, both are valid and workable designs.  If you want to
be
> > the 'most OO' you should go with 1 or 2.  I would only go with #1 if you
> > knew the page was supposed to create a new account from scratch, why
> create
> > the object until you are sure you need it?  If it's an existing account
> load
> > you're going to need to load from a DB (probably based on some user
> > parameters).  Regardless, both #1 and #2 are good/similar object based
> > designs.

> > --
> > Greg Ewing [MVP]
> > http://www.claritycon.com



> > > Hi All,

> > > I have a fundemental OO design question. In a typical 'shopping cart'
> > > scenerio (ASP.NET), what is the best practice in terms or
> instance/static
> > > members?
> > > I have a class called AccountDB which contains all the functions to
> > > add/remove/edit items.

> > > Should I:

> > > 1)

> > > - Set all methods as instance members in the AccountDB class
> > > - Then Declare AccountDB in the declarations section of the calling
> class
> > > - Create a new instance of AccountDB in the Page_Load
> > > - Use this instance to perform any functions during the lifetime of
the
> > > page.

> > > public class AccountDB
> > > {
> > >     public void DoSomething()
> > > }
> > > public class CodeBehind
> > > {
> > >     AccountDB aAccountDBInstance
> > >     public void Page_Load
> > >     {
> > >         aAccountDBInstance = new AccountDB()
> > >     }
> > >     public void SaveButtonClick()
> > >     {
> > >         aAccountDBInstance .DoSimething()
> > >     }
> > > }

> > > 2)

> > > - Set all methods as instance members in the AccountDB class
> > > - Create a new instance of the AccountDB class when performing any of
> its
> > > functions on the calling class

> > > public class AccountDB
> > > {
> > >     public void DoSomething()
> > > }
> > > public class CodeBehind
> > > {
> > >     public void SaveButtonClick()
> > >     {
> > >         AccountDB aAccountDBInstance = new AccountDB()
> > >         aAccountDBInstance .DoSimething()
> > >     }
> > > }

> > > 3)

> > > - Set all methods as static members in the AccountDB class.
> > > - Call these methods from the calling class

> > > public class AccountDB
> > > {
> > >     public static void DoSomething()
> > > }
> > > public class CodeBehind
> > > {
> > >     public void SaveButtonClick()
> > >     {
> > >            AccountDB.DoSimething()
> > >     }
> > > }

> > > Any thoughts appreciated.

> > > Regards, Andrew



Sat, 25 Jun 2005 12:43:37 GMT  
 Best Practice - OO

Quote:
> Any thoughts appreciated.

Hi Andrew,

Another thought is that, if you go with static members, all your sessions
may share the same object, which can be dangerous. If you have any static
data on the class then this will be available through all sessions.

Also, by using static members you lose the future ability to subclass your
AccountDb class. My personal preference is to use a factory method, or a
factory to facilitate creation of the Db. So you might have somehting
like...

public class AccountDbFactory{
    public static AccountDb CreateAccountDb(){
      return new AccountDb();
    }

Quote:
}

public class AccountDb{
  ...

Quote:
}

client code...

AccountDb db = AccountDbFactory.CreateAccountDb();

This gives added flexibilty in that you can have the factory create or
configure AccountDb's for your application. For example, it might configure
it to use a test database during development, but you could then have it
switch to live later on.

HTH

Tobin Harris

Quote:
> Regards, Andrew



Sat, 25 Jun 2005 18:52:24 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Free OO seminar in Denver, CO on best new OO design and reengineering tool in 97

2. Best practice in Windows Forms?

3. Data access 'BEST' practice

4. Best Practices Question - Interacting with VB, C#, C++

5. Advice on best practice for header file organization?

6. Best Practices

7. Software Metrics Best Practices

8. finalizers: best practice

9. Best practices for object serialization?

10. C# Naming Conventions Best Practice?

11. Good practice

12. best practice MDIparent

 

 
Powered by phpBB® Forum Software