Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

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

500pts: Class designing?

Hi there,

I wanted to check on something, i have the idea that classes should never be coupled i.e. depend on another class etc..

i.e. should never create a class with a method where you pass  in another class for example... as if this changes... that it can cause a ripple effect on all classes... this i understand...

Does this also go for passing in things like listboxes etc? I presume it does, it that case if i need to populate a listbox and 1 of my classes knows how to do this... what is the best/correct way of doing this..

returning a hashtable or something and filling it in code ?????

Any comments really appreciated...

Thanks in advance

Ian
0
ianinspain
Asked:
ianinspain
  • 4
  • 4
1 Solution
 
AlexFMCommented:
Please give more information about this class - what should it do, which information should it keep etc.
0
 
ianinspainAuthor Commented:
For example.. I have a listbox in the UI ... and a class is called ... passing in a listbox... the listbox fills with the status of loggin in i.e Initialising, setting up abc, etc etc..  The class basically does a login....

Of course it works but i believe that i have now coupled this with a Listbox... is this ok? ... hence it depends on a listbox being passed in... just a little confused...

Like i say i know that to pass a class to another class makes it coupled hence changes to one can make a ripple effect and cause code to break everywhere...

I really wanted to know if i am doing this the right way, i should i look at an altenative.. i..e. raising an event for each stage of login and get the event to load the listbox via the UI??

0
 
ianinspainAuthor Commented:
I have learnt so so much over the past 6 months but i am trying to get rid of my bad habits and start putting some best practices into practice :-)...

I want to ensure i am doing things the correct way

I tried searching google but couldn't find any sort of best practices class design sutff.. i..e why not couple etc etc

Ian
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
AlexFMCommented:
I understand that you don't like that class works with Listbox. Other client possibly has other control, or wants to print information to Console window.
If class has methods which accepts ListBox, replace ListBox parameter with other types like string, string[] or any other types appropriate to pass your information.
If class has ListBox member which is set by client, and periodically adds lines to this ListBox, remove this class member. Use events instead. For example, when something happens, class raises event passing all required information as event parameters. Client creates instance of your class and subscribes to its events. In event handler client adds information to Listbox or does anything else.
Events help to isolate class from its clients. Event source does its own work and raises events when necessary, without any knowledge about clients.
0
 
ianinspainAuthor Commented:
Hi AlexFM,

yes.. so you can confirm that this is the way to go.... you should never accept things like listboxes, etc as input variables on methods of a class because it because coupled... is this correct?

Instead should use simple types i.e. strings, ints, and the good old fashioned hashtables and eventargs etc??

This is what i was thinking but wanted some confirmation on the matter....

Thanks again...
0
 
mjmarlowCommented:
Hi ian,

In order to be completely decoupled, you would have to define methods that take "Object" as parameter(s).  This technique has a lot of problems.  

1.  Performance.  Functions will need to convert input arg at runtime.
2.  Lack of contract.  Defining class as input parameters automatically defines (documents to a certain degree) a public "contract" on how to invoke method.

Use objects as parameters when ever you can!  There is nothing wrong with using a ListBox or any other class as an input parameter.  

Of course there are situations where late binding makes sense.  But these are exceptions not the rule.  

0
 
AlexFMCommented:
>> You should never accept things like listboxes, etc as input variables on methods of a class because it because coupled... is this correct?

Generally, this is right. But there are some situations when this is necessary. For example, you write function which does something with ListBox control. In this case it should have ListBox parameter. Like function which moves selected item from one listbox to another. It should look like:
void MoveSelectedItem(ListBox from, ListBox to)

In your case, if ListBox is not important, use only parameters which pass information between client and server. Class should not now anything (or have minimal knowledge) about its clients.
0
 
AlexFMCommented:
>> Use objects as parameters when ever you can!

Sorry, I don't agree with this. Never use objects unless there is no other way.
Microsoft made a lot of work to remove using of Object parameters, replacing old containers with generic containers. Using Objects is not type-safe, and slower than using specific types. For reference types, there is slight performance loss for casting. For value types, there is significant performance loss for boxing.
0
 
ianinspainAuthor Commented:
Thanks AlexFM, as usually excellent helpful advice ... thanks again...

0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

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