0

while writing a new project in C# I created a public static list that contains all the dynamically created instances. Let me give u some code to clarify what i mean.

class myClass
{
    public static List<myClass> ListForGlobalUse = new List<myClass>();

    public myClass()
    {
        ListForGlobalUse.Add(this);
    }
}

I did this because I needed the instances in other classes and I think that it is more handy and easier to read than creating a List in each class.

Now I am curious if this is legit or if this could be (for any reason) a bad habit. Maybe someone could also explain how it influences the assembler code since static objects and the methods are allocated in a different place in memory than the dynamic objects.

Maybe i chose the wrong tag but I really don't know which fits the best.

lorenz albert
  • 1,385
  • 2
  • 11
  • 27

2 Answers2

1

It is legit, no lawyer can sue you for it.

However, it's really just a global object, and those are too easy to use everywhere, tangling up and cabling everything in your code together.

You save some writing work in the beginning, but in the longer term the probability gets higher and higher that you'll regret your super tight coupling.

You can always pass objects down the call-tree, as parameters to constructors or functions. And if some class is the only user of an object, then only that class should know about or own it.

Personal statement: I don't remember a single situation in at least the last 10 years where I needed a global object; the nice effect is I never had any of the problems related to this worst kind of coupling.

Example:

Let's say you have a database connection; call it mongoConnection:

global:
    MongoDB mongoConnection

You also have a getCustomers function in your business model:

business-module:
    getCustomers (arguments)
        ... mongoConnection.fetch("customers") ...

However, someone hasn't read how mongoConnection should be used, but because she/he/it is familiar with MongoDB, she/he/it considers it not a problem and now uses it everywhere:

// core.cs
mongoConnection.fetch("customers")

// misc.cs
mongoConnection.fetch("customers")

// foobar.cs
mongoConnection.fetch("cutsomers")

// api/web/authentication/local/core/foo/bar/core.cs
mongoConnection.fetch("customers")

So instead of using your clean Customers-API, you have now spread implementation details all over, just because someone knew MongoDB better than the Customers-API.

No problem for the moment.

But in three months you realise your definition of customers was bad. You rename it to users and change the names of all fields.

You do a global search-and-replace:

// core.cs
mongoConnection.fetch("users")

// misc.cs
mongoConnection.fetch("users")

// foobar.cs
mongoConnection.fetch("cutsomers")

// api/web/authentication/local/core/foo/bar/core.cs
mongoConnection.fetch("users")

And then you go manually through the code, adjusting all the queried fields. That's a crapton of work in a medium sized project. After your changes, you release your code.

Three months later, a customer complaints that the heavily advertised Foobar module isn't working; how can that be, it all compiled.

You debug, and fix ...

// foobar.cs
mongoConnection.fetch("users") // fix: not cutsomers, but users

... and release. The customer calls again, calling you a fraud and an idiot. He now wants his money back.

Hmm. Oh crap, you forgot to also adjust all the renamed fields in the foobar-module. You fix that. You sweet-talk to the customer for hours.

You then decide to add unit-testing so something like that does not happen again. It all works fine, you have nightly testing and everything.

Three months later, your application has grown to 100 KLoC with tests now running for hours, making them useless for manual programmer use. Also your testing database is full. You realise it would be better to run the tests on mock-database-connections that do just what is required by the tests.

Now remember you have direct database connections spread everywhere, in approximately 121 source files. Many of those source files are passing the database-connection through to some plugins written in a "special" style by a guy who has left the company.

Some of your customers are now demanding important features, and you haven't got the workforce required to improve your testing procedure.

Three months later.

You grow and grow, and once again realise that your Users datastructure should be modified, or else your application can't scale enough to serve some of your key-customers ...

Your application has grown to 269 files. Connections spread everywhere. Some plugins now use plugins on their own ... your connection is a virus and it feels like it begins living. Some modules modify the caching parameters and forget to reset them, other modules ask really nonperformant queries that should have never been asked ...

Customers want more features ... You hire more MongoDB experts, and all of them find your connection familiarohmygod.

The night before christmas, a customer call.

"You frantic burglar, your crappy module is buggy as shit and my most important campaign generating 94% of annual sales is just missing its peak I hope you die because my employees will now starve and ..."

And you question your decision to use globals.

Sebastian Mach
  • 38,570
  • 8
  • 95
  • 130
0

You can use the Object Pool pattern: http://sourcemaking.com/design_patterns/object_pool

This a good implementation in c#: https://stackoverflow.com/a/2572919/3437025

Community
  • 1
  • 1
josellm
  • 23
  • 7