Ernest Friedman-Hill wrote:Hi Debbie,
Welcome to JavaRanch!
Java web sites are ultimately built on servlets. We have a forum dedicated to the topic (see our front page). When you create a servlet, you extend a class and add your own code -- so that's OOP right there. It's hard to do much of anything in Java without at least some object-oriented practices.
Servlets can and do create web pages dynamically. Completely static HTML pages are pretty rare these days.
Almost no-one uses raw servlets to do everything, though: there are many different frameworks built on top on the servlet APIs, and people ususually use one. You can take your pick: Struts and Stripes and GWT and Spring and JSF and you name it, including one called FrontMan maintained by our own Bear Bibeault, a sheriff here at the Ranch. Frameworks at every level, from simple to complex, easy to difficult, are available. These frameworks are generally all about implementing interfaces and extending classes -- i.e., they're all based on creating classes to fit into inheritance hierarchies: more OOP.
But you have to crawl before you can walk. One place to start learning about servlets is Ben Souther's page.
David Newton wrote:Right off the bat, I'll tell you that PHP is *not* a great place to learn OOP.
And JiG isn't the right forum for general OO questions; you want OO, Patterns, UML and Refactoring, which is kind of a catch-all for all things OO. I'll move this post there.
My advice, if you're dead-set on using PHP,
...is to just start coding something in PHP, and see what happens: it's the easiest, most reliable way to learn. If you code yourself into a corner, back away slowly and figure out what went wrong, when it went wrong, and what makes you think it's wrong.
At *that* point you could post a question in OO, or in Other Languages, regarding specifics. There are *so* many ways to go about coding what you're doing that giving practical advice at this stage is tricky.
I will say that the idea to have a Registration class that has all the properties and methods needed to register a user sounds a lot like what people would call a "service" class, but it depends on what you really mean by "all the properties and methods"...
I mean, a "user" is a separate entity--it would have its own set of user-specific properties.
"Registration" is a concept involving a user, but is not a user.
So if I were going about it, I'd have a class that snarfs the data from the web page,
sends it to the registration service, which in turn creates a user and persists them somehow.
I tend to focus on "separation of concerns": each component should know as little as possible about the components around it. This makes things flexible.
I prefer small over large, composable over fixed.
Debbie Dawson wrote:A good OOD should basically transcend how it is implemented?!
Why code anything without a plan?
as well as general OOP questions.
It also stressed another key concept that I want to avoid... That classes have to be physical, tangible "nouns" and nothing else, and that all "verbs" are methods?!
I think "Registration" would make a good class because it is a thing.
The "Registration" class would have properties like... email, password, firstName, lastName, city, state, zip, country
- isEmailUnique()
- isEmailValid()
- isPasswordValid()
Would it be okay to write an HTML webpage that has my HTML Registration Form and when the User clicks "Register" send it to my "Registration" class?
Why code anything without a plan?
David Newton wrote:
Debbie Dawson wrote:A good OOD should basically transcend how it is implemented?!
OO*D*, sure. But not all OOPLs are created equal, and PHP does a disservice to OOPLs in general.
I don't *care* what you use, but out of all the choices available, PHP would be *really* low on my list.
Why code anything without a plan?
That's not what I said--I said just start. But the questions you're asking are too high-level to provide much specific help.
as well as general OOP questions.
Then ask them!
It also stressed another key concept that I want to avoid... That classes have to be physical, tangible "nouns" and nothing else, and that all "verbs" are methods?!
Why would you want to avoid that?
I think "Registration" would make a good class because it is a thing.
Perhaps, but I wouldn't call it "Registration". It's not *a* registration.
*A* registration has things like the associated user, the date registered, what extras were registered for, etc. It's a registration service. It allows one to register.
The "Registration" class would have properties like... email, password, firstName, lastName, city, state, zip, country
How are those not part of the member/user class?
- isEmailUnique()
- isEmailValid()
- isPasswordValid()
Why would those be part of a registration? Are they not general-purpose methods that might be used elsewhere in the system? Or in a completely different system? These are not (necessarily) specific to registration.
Would it be okay to write an HTML webpage that has my HTML Registration Form and when the User clicks "Register" send it to my "Registration" class?
Sure, with the caveat that I'm not convinced I like the registration class. But like I said--why not just start? Analysis paralysis. You're not at the point in OOP where over-thinking is going to help.
I think the "Registration" class I described above would do that part. And it would "persist" as you say because one of the methods (e.g. activateAccount() ) would write the "activated" User into the back-end "Member" table in my database...
The "Registration" class would have properties like...
- email*
- password*
- firstName*
- lastName
- city
- state
- zip
- country
- acceptTerms*
*required
and it could have methods like...
- requiredFieldsComplete()
- isEmailUnique()
- isEmailValid()
- isPasswordValid()
- sendActivationEmail()
- activateAccount()
Of course that is just my first best guess having never written OOP before?!![]()
I think "Registration" would make a good class because it is a thing
In that book - and other things I've seen and read - it seems that the more *advanced* OO programmer understands you want to abstract out behaviors and processes as classes also. So, in the Head First book they took what most junior OOP'ers would label as "verbs" (and thus want to make "methods") and instead treated then as "things" which could be seen as "classes").
I just finished reading the book "Head First: Design Patterns" - which by the way revolves around Java - and while it was a big chunk to bite off for a beginner, two patterns that I saw some use in for my website was the "Strategy Patterns" and the "State Pattern".
One key thing I want to avoid that seems to be common in Procedural Programming is dumping tons of unrelated code into on giant bucket!!
See, this is where I am hoping all of the gurus here can help me out?!
For instance, I have a strategy for how to build the registration portion, but am uncertain about some design considerations as well as general OOP questions.
I'm not following how PHP upsets my plans of creating a decent design BEFORE I dive into code.
Why do you make it sound so dirty? (Other than this *IS* a website for Java!!!)
![]()
Java has A LOT of implications (and costs) that PHP doesn't have.
You do design, then implementation.
Then that "Uniquenessvalidator" could extend (??) the "Registration" class?
(Help me out here...)
It is my strong belief that "Registration" is too complex to just lump 1,000 lines of code together and class it a Method!
and a "Registration" class. The latter creates a new "Member"
A "Member" would indeed have those same Properties, but...
1.) Would also likely have many more that transcend the "Registration" class
2.) Would not have the same Methods
3.) Is a concrete thing and completely separate from "Registration".
Semantics, but that is fine.
Not sure where you live, but what is the thingy you have that the county or state gives you with your car?
Because not all good Classes need be concrete, physical things... In fact, I would say they also don't always have to be "nouns"...
So how do you really feel?
![]()
When I become rich and an OO expert, then I can re-engineer my site using the latest and greatest Java.
Clearly you aren't a PHP fan.
All I know is that PHP makes much more financial and coding sense for someone in my shoes, and it clearly can produce enterprise-level websites.
David,
Geesh, you sounded angry.
Debbie Dawson wrote:Geesh, you sounded angry.
Okay, but I think my questions were pretty concise.
*A* registration has things like the associated user, the date registered, what extras were registered for, etc. It's a registration service. It allows one to register.
Semantics, but that is fine.
A "Member" would indeed have those same Properties, but...
It is my strong belief that "Registration" is too complex to just lump 1,000 lines of code together and class it a Method!
(I don't think I've hit "analysis-paralysis" in just one thread...)
David Newton wrote:You're in for a tough haul if you think semantics in programming are unimportant.
Debbie: Because not all good Classes need be concrete, physical things... In fact, I would say they also don't always have to be "nouns"...
I think "Registration" would make a good class because it is a thing.
David: Perhaps, but I wouldn't call it "Registration". It's not *a* registration.
Debbie: Not sure where you live, but what is the thingy you have that the county or state gives you with your car? (*hint* A Registration)
David: *A* registration has things like the associated user, the date registered, what extras were registered for, etc. It's a registration service. It allows one to register.
Debbie: Semantics, but that is fine.
David Newton wrote:Even for something this trivial, there are many, many ways it could be implemented, some good, some bad, some great, some horrible. Really--start. Pick a high-level way of doing it and go. Refactor mercilessly and eventually the design will emerge. Chip away at the stone until the form within is revealed.
Debbie Dawson wrote:Um, the context was...
Don't you do an ERD before you start writing SQL?
Often the most important part of the news is what they didn't tell.
The government thinks you are too stupid to make your own lightbulb choices. But this tiny ad thinks you are smart:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|