Thread: to use or not to use... (a separate class)

  1. #1
    Registered User
    Join Date
    Aug 2005
    Posts
    6

    to use or not to use... (a separate class)

    I am wondering into the vast realms of learning to program... or at least trying to anyway. Actually I did a little way back when I was a student but most of the stuff I learnt each day... was drunk away each night at the SU bar.

    Anyway back to the questions. I have two forms. One is the main form and the other is a login dialogue box. Now I have a bit of a quandry. On the click of a button in the login form, I either need to somehow pass the username and password back to the main form for validation or else I need to create a third class to pass the username and password into in order to retrieve the login information. Firstly I am not so sure if thats a great way to go about it since it seems a bit convoluted but I suppose I could create a login class and do a bunch of other stuff in there anyway. Anyway if I were to do it this way, it brings up another question. I realise that I would need to put a call from the original main form class to a login_details method or two somewhere in the new login class in order to get a return value from the login class. How would I trigger this event to happen from the main form after the login_dialogue form has completed and passed over the details to the login class without needing some kind of user prompted event (button click etc) in the main form to trigger it. The reason I need info returned to the main form is that after the validation and stuff, the main form changes depending on what permissions are given to the logged in user.

    Hopefully that all makes sense. but you know how it is... hehe

  2. #2
    Registered User
    Join Date
    Jan 2004
    Posts
    37
    I had a very hard time following that question, so let me try to take a stab at what I heard.

    First, make sure that you create a separation between the controlling code and the UI code. For example, a dialogue box should never call into a database when the user clicks the login button. The UI should simply harvest the data and present it to the controlling code. The UI can do input validation for required fields being filled out, input format, etc.

    I believe that your login dialog box should simply expose some properties that will allow access to the user name and password entered in the login dialog box. The code that creates and shows the login dialog box can then harvest that data from the login dialog box and use it to attempt to log in the user.

    I don't know if that answers your question, but it is a start.

    LT

  3. #3
    Registered User
    Join Date
    Aug 2005
    Posts
    6
    Sorry about that, I just re-read it and your right, that was a terrible first post from me. Anyway, thanks for taking the time to try to decypher it, you did a pretty good job by all accounts and it has put me on a much better train of thought. I am fairly confident that I now know how to go about it.

    While I am here, lets say I get a successful login. Just to keep it simple lets say I just store a value of 1 which represents a logged in user which becomes 0 when that user logs out. What would be a good way of keeping that value available globally. Would I be better off just making this variable globally accessable by everyone and everything within the program? I was under the impression that this was bad form in OO programming so are there any other alternatives for storing values like that that may be used all over the program? Out of interest, would this be a good candidate for something that could be temporarily stored in the registry?

    Realistically I would be storing more than one value for logged in users but the above should give you an idea of what I mean

  4. #4
    Registered User
    Join Date
    Jan 2004
    Posts
    37
    I would create a User class that has a property called LoggedIn. This propery would be an accessor to a bool type variable.

    Code:
    public class User
    {
    	//Hidden field to hold if the user is logged in or not
    	protected bool mLoggedIn = false;
    
    	//Gets/Sets the logged in field
    	public bool LoggedIn
    	{
    		get
    		{
    			return mLoggedIn;
    		}
    
    		set
    		{
    			mLoggedIn = value;
    		}
    	}
    
    }
    You could then keep a list of users in either an ArrayList or a Hashtable if you need quick user lookups.

    Personally, keeping a list of logged in users in memory of a single process doesn't really get you much unless you are writing a server that is accepting login requests. Obviously, I don't know what your requirements are or the purpose of the application so I may be completely off base. Usually, a client application doesn't need to know if more than one user is logged in because it only provides the interface for one user at a time.

    If you need to make the data globally accessible to your application then you may want to investigate a design pattern called the "Singleton". It basically uses static members of a class to make data global across the process.

    Does that make sense to you?

    LT

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Class design problem
    By h3ro in forum C++ Programming
    Replies: 10
    Last Post: 12-19-2008, 09:10 AM
  2. Specializing class
    By Elysia in forum C++ Programming
    Replies: 6
    Last Post: 09-28-2008, 04:30 AM
  3. Creating a database
    By Shamino in forum Game Programming
    Replies: 19
    Last Post: 06-10-2007, 01:09 PM
  4. Need help to build network class
    By weeb0 in forum C++ Programming
    Replies: 0
    Last Post: 02-01-2006, 11:33 AM