Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 266
  • Last Modified:

Variables Or KeyValuePairs

Hi all,

I am designing an app, and would like ot make it as scalable as possible, i have a number of objects, most corresponding to tables in a database.  At the moment i have the basic - Private Variables, Public Properties set up.

However someone at work told me it is better have a single hashtable per objects so you can store you variables Names/Values in there, that way you are not tied down.

I cant see the point, however is it really the best way to go about it?

Thanks in advance

Apresto
0
apresto
Asked:
apresto
  • 5
  • 5
1 Solution
 
Carl TawnSystems and Integration DeveloperCommented:
It depends on the situation, but its certainly an option. The downside is that the HashTable will store everything as an object (or string if you use the specialized version), so you will have to cast each value when you retrieve it from the HashTable and return it from your property.

So, unless you are only storing strings then its probably more trouble than its worth.
0
 
aprestoAuthor Commented:
Hi there, Thanks for the reply, I can see what you mean.

I personally don't like the idea, i find it much easier, and tidier to use members and properties, however i'm after scalability.

The argument the guys at work have is that if you were to add a field into your database you would need to change your code etc etc to suppose that field, so a hashtable is ideal.  I am in the frame of mind that if the database was right in the first place additional fields shouldnt be that frequent, but its always a possibility i suppose.

I'm torn between the 2 to be honest....i'll see what anyone else has to say before i close

Thanks again
0
 
Carl TawnSystems and Integration DeveloperCommented:
This is probably a situation where you should be using interfaces. You create an interface for the initial version of the class, then if you add new propeties at a later date you simply create a second interface with the new properties. That way you don't "break" any client that relies on the original version.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
aprestoAuthor Commented:
i see, so if i use an interface, do you mean to use it in conjunction with the hashtable so i can access everything via property. And if i create a second version, have the new interface have the same properties as the old one plus any additions?

Thats a good idea, i have implemented some interfaces at the moment - but i think that this suggestion could solve many problem!

Thanks very much
0
 
Carl TawnSystems and Integration DeveloperCommented:
I would go with the interfaces, but not the HashTable (unless you are using purely string data). Plus you are always going to take a slightly bigger performance hit using a HashTable than you would using built-in types.

>> And if i create a second version, have the new interface have the same properties as the old one plus any additions?

Even simpler, have the new one derive from the original, plus the new properties:

   public interface Shape
   {
        double Width
        {
            get {}
            set {}
        }

        double Height
        {
             get {}
             set {}
        }
   }

    // new interface, extends original
    public interface Shape2 : Shape
    {
        double Diameter
        {
            get { }
            set { }
        }
    }
0
 
aprestoAuthor Commented:
As i see, i do like the idea of using inteface, as i was always told this was good practise.

I agree that hashtable would prob hit performance, however the reason i was told to consider hashtables was because i could easily add variables to an object, simply by adding a key/value pair to the hashtable within that object, so its scalable in the sense that i would not need to bebuild the app and implement it every time i add a field. i would just add it to the hashtable and 'theoretically' that object now contains an assigned variable.

I aplolgise for naivety as i'm an not expert on interfaces, but if there a way i could use interfaces to implement a similar solution that hashtables provide above?

>>>Even simpler, have the new one derive from the original, plus the new properties

Genius! :o)
0
 
Carl TawnSystems and Integration DeveloperCommented:
How would you go about adding the new value to the HashTable without changing the code ? How would the rest of your code know it was there in order to retrieve it ? If you added it via some sort of config whats to stop anyone else adding rogue values ? How would you app be able to alter the value, and how would you prevent it being set to an invalid value ? Would your HashTable be read-only ?

If you added a new value to a HashTable dynamically without modifying the code you would have a hard time treating it as the correct type.
0
 
aprestoAuthor Commented:
I see what you mean, however the app in question is a data trafficing application.

it has a client on the application and server.

Data is retrieved from a stored procedure and it added to an object,
the object then converts its properties to xml and passes down to the app sitting on the clients machine
which then creates a summary report depending on the xml passed down to it.  
At the moment i use reflection to retrieve a list of variable names within the object and their values for the xml conversion, and i am happy with it. however i can imagine it would be easier with hashtable

However i ask this question, not only for this task, but also for future devewlopment "Do's and Dont's".

I am against using hashtable as variables and properties are there for a reason and i refuse to believe that it is better practise to use hashtable - which is why i ask question.  But i agree with the interface advise, i understand your point above, and was kind of expecting it :o)

As long as there is not something magical that interfaces can do, i think i have gained what i came here to gain from this thread. :o)

do you understand what i mean above?

Thanks you very much for your participation
0
 
Carl TawnSystems and Integration DeveloperCommented:
Good rule of thumb:  If it feels wrong then it probably is.

At the end of the day you have to go with what best suits your situtation, even if it isn't 100% good OO. As long as you are aware of the downsides to the design and can justify them then go with it.
0
 
aprestoAuthor Commented:
Thats a good Rule,

Thanks for your help, thats some good advise

Apresto

0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now