ianinspain
asked on
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
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
Please give more information about this class - what should it do, which information should it keep etc.
ASKER
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??
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??
ASKER
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
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
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.
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.
ASKER
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...
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...
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> 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.
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.
ASKER
Thanks AlexFM, as usually excellent helpful advice ... thanks again...