• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

OO Concepts

Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I posted a message in the OO forum asking if anyone had any pointers on a book or a website that covers OO concepts in a little more detail than Just Java 2, but I haven't had many responses there.
What I am struggling with is how do I take a problem, break it into classes, and from there into methods?
The classic example I have run in to is the bicycle example, where the bicycle has a state and behavior. Where the behavior would be the methods (ie. turn left, break, go faster). I understand the example, but I can't seem to apply that to a problem, such as how do I create a user logon screen that would validate a users id and password.
Might anyone have some ideas or some resources that might help me to clarify how to break a problem down using OO methodologies?
Thanks for the help!
Brian Burke
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great topic Brian! I hope this generates a lot of discussion. As a structured programmer, I too have trouble grasping these basic kinds of OOP ideas. I'm going to give this question a shot and hopefully garner some knowledge from the responses.
I would have the driving class for the logon screen itself. This class would probably have methods for initial display, user validation, errors/exceptions, and maybe a successful logon display.
The user validation method would instantiate a 'user' object defined by another class. *{In my procedural world, the user object would be 'built' by accessing a database and populating the instance variables with all the pertinent data.} This would include calling a password verification method and possibly creating a session object (a variable of the user object, maybe?) which would probably be another class.
If there was an error of somekind, the error/exception method would take over and report back to the screen, otherwise the successful logon method would take control and guide the rest of the process, probably calling subsequent classes by passing off the 'user' object.
So, if this were feasible, you would have:
3 classes - driver, user, and session. Password verification could also conceivably be its own class.
5 methods - main, initialDisplay, getUser, HandleErrors, successfulLogin in the driver class and numerous other methods in the other classes.
At least from my limited point of view this seems reasonable. 'Nits' anyone?

I'm a soldier in the NetScape Wars...
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I'm a real OO beginner, but here goes:
- The screen
- User ID
- User Password
- get information (ID and password)
- validate information (ID and password)
- handle invalid information
- Exception and Error methods (for example, if no info is entered in a field)
- allow valid user to proceed to next screen
- keep invalid user from proceeding, and give them 'error' messages so they know what information didn't "pass".
Also, you'd need to use something to keep multiple users from stepping all over one another. Threads maybe???
Ah, this is tough, isn't it? I don't think OO'ishly.
I look forward to seeing what the experts say!
Posts: 1843
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For OO concepts, the first couple chapters of Bruce Eckel's Thinking in Java is good.
This id/passwords question intrigued me, so I sketched out some code as I started to think about which objects should provide which services. Maybe my code will get a discussion going. I'm a relative newbie, so I'd appreciate all comments, nitpicks, etc.
I decided not to worry about the GUI and just get some working business objects. The hooks are there for a GUI, though. Whatever launches the program would be responsible for calling "ProfilePool profilePool = ProfilePool.getInstance() ;" and the combination of the getUserProfile() method on ProfilePool and validatePassword() on UserProfile is the key to the whole thing -- you send an Id String to getUserProfile to get a handle to a UserProfile, then use validatePassword to compare a potentially matching password string to the stored string for that UserProfile.
(1) I know close to nothing about security.
(2) I'd bet serialized objects in a file are a pretty unsecure way to store passwords. It's just the easiest way to test this out without firing up a database. (I guess I could've done a flat file, but that's even uglier.)
(3) This is the first time I've used a HashSet, so all the stuff overriding equals() and hashCode() is pretty shaky.
(4) Of course in production code you're not going to have a public UserProfile.toString() that prints out the password!
(5) The fact that setPassword() on UserProfile doesn't trigger save() on ProfilePool is a major flaw in this (you don't see the bug until the second time you run the test). I guess I'd fix this with some sort of listener technique, but that's a project for another day.

What? What, what, what? What what tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic