figuring out a class

[Fred Schauer]

I'm new to java and object oriented programming/analysis. I've previously written programs to access/maintain relational databases. I would like to write an application in Java to access/maintain an MySql database for our snowmobile club. This will be free for my club and I'll get to learn something here. My problem is what I believe should be the main class, I want to call it member(s), but I also need to track: businesses that give donations and aren't members, individuals that help but aren't members, and some members from another club we merged with that are lifetime members(dues), but our club doesn't offer a lifetime membership. We also have primary members, members that get an e-mail newsletter and members that get postal newsletter, single memberships, family memberships, etc.

I'm having a hard time figuring this out and I think this will be the main piece that I need to start from? Apparently I'm thinking wrong about this as it isn't working out for me. Any suggestions on how to work through this? We also will want to track raffles and other club activities, but that can be added later.

Thanks

Fred57

[Jacob Anawalt]

Welcome,

Your question, while basic, is more on theory of object oriented design than it is specifically about how to code in Java.

How are you tracking all of these entities in the database? If these relationships already exist, they should provide models for the several objects you or some Object Relation Mapping (ORM) will be creating.

What languages have you used so far to interact with databases?

A Java specific issue jumps out to me in your reference to a main class. I would avoid calling any of my classes main, because it is likely to be confused with the Java main method which is used as an entry point into a program. Perhaps you mean the root of some object hierarchy, although you may find your design simpler using a bunch of related classes implementing some interfaces than using some complicated inheritance tree.

I don't want to have you bite off more than you can chew, but where and how is this program going to run? Is it a single or multiple instances on end-user computers or a web service?

[Fred Schauer]

I'm still trying to figure out the database(s), I want to keep that compatible with the Java style, but am struggling. I used to program in clipper, visual basic and visual fox pro, using a database similar to dbase. And yes I guess the question I'm asking is more about design. But I've decided to use Java and it seems things slant different ways with different languages.
I was just referring to the top class, I wanted to call it members and I'm having a hard time with that as we are tracking non-members also. I want to do this correctly and know more about it before I start.

Initially this will be an application that runs on 1 computer with 1 user and will access/maintain about 300 members & non-member volunteers of a snowmobile club. This will be a non-browser application and eventually I would like to have it run on a network, but it will probably never need to have more than 2-5 concurrent users. I've done some research and it seems JavaFX is one option I like to build the user interface. But I was already told, keep the business logic separate from the user interface, so I'm just trying to get my initial class(es) defined.

I currently use a microsoft works database and its not doing or displaying everything we want to nicely and there are some issues. I would like a nice interface to just add, edit, delete members, non-members, and print mailing labels, etc. I want to use MySql as the database.

Thanks for any help.

Fred57

P.S. What forum would be a better forum to post this question?

[Winston Gutkowski]

Fred Schauer wrote:P.S. What forum would be a better forum to post this question?

I think this one is fine for the moment. If it starts to drift, someone may move for you.

A few possibilities to think about:
1. If you're familiar with FoxPro, then you might be better off using it - assuming it supports SQL and has a decent JDBC module. That'll save you having to learn two things at once.
2. Start out simple. What is the main purpose of this app? It sounds to me like a membership system, so concentrate on that, and don't get too bogged down in the minutiae of donators, volunteers and the like. Get the membership part of it working first, and I suspect you'll find that these other things can be plugged in later on - although it's certainly not a bad idea to be aware that they'll be needed and maybe make some notes about how they relate (for example: does a Volunteer HAVE to be a Member?).

Member (singular) certainly sounds like a good place to start; and I suspect that Club (your collection of Members) may well be another; but the best place to trawl for objects and classes (and methods) is generally the requirements themselves.

Do you have a single cohesive document that describes those requirements? If not, I suggest you compile one - in English; NOT in Java, or techno-babble - and run it by your club admins to see if they agree with it and think it's complete. And keep refining it until they're happy.

Once you have that, you can then do something I call "lexical analysis". Sound complex, but it really isn't:
Read through that document, several times if needed, and compile lists of verbs and nouns. It's crude, but it often works very well as a "first cut" for finding classes and methods.

For example, just reading through that first post of your gives me:

Nouns: Club, Member (Lifetime and Primary), Business, Donation, Individual, Dues (or maybe "Fee"), E-mail, Newsletter, Membership (Single and Family).

Verbs: give (or maybe "donate"), get (or maybe "send", since the system will be for the club), pay (derived from "dues", which presumably need to be paid), post (derived from "postal").

As you can see, the verbs may take a bit more 'finding', but the main thing at this stage is not to editorialize - ie, leave your preconceptions at the door - at this stage you're simply interested in getting lists of words. Note also that these are just the words I got from your 4-line description; once you have a proper requirements document, you'll probably have a lot more to work with. For example, verbs like "join", "cancel" and "list" (as in Membership lists) spring to mind.

What you'll find is that the Nouns often make good candidates for classes, and the Verbs for actions or methods. It's by no mean universal, but it can help you to get a grasp of the main parameters to your system. You can even try to tie them together; for example:

Member gets E-mail

Member gets Newsletter (or perhaps even "Club posts Newsletter to Member")

Business gives Donation

Member pays Dues

Do you see what's happening? We're gradually building up a picture of the things that the system is likely to need or do. And note that we haven't involved one jot of Java yet; this is much more like the exercise you would go through to design a database, but it works just as well with Java to get you kick-started.

HIH

Winston

[Campbell Ritchie]

I would suggest you should learn object‑orientation first. There is a section in the Java Tutorials about database access.

I would suggest that decisions about what products you plan to use might better follow the design of your program, rather than being part of the specification.

[Junilu Lacar]

As you may have gathered, if you're just learning Java, then you pretty much have a mountain in front of you. There are a LOT of things that go into building a non-trivial application, even for the relatively small scope that you have described. I say "relatively" because there are applications built by teams of developers (#members > 1 or 2) that can span weeks, months, and even years of time and effort. For a solo developer who is unfamiliar with the technology, that's almost like setting out to climb a Himalayan mountain with an overabundance of intestinal fortitude but only a backpack full of supplies. No Sherpas, pack mules, GPS, or anything like that. Not trying to discourage you but I think you're owed at least a chance to do a reality check.

Ok, maybe it's not really the size of Everest that you're looking at. Maybe just the Rockies. Or a minor peak in the Rockies. Still, if you're planning to do this yourself, the task in front of you is going to be daunting to say the least. I don't know if this helps but there are tools out there that can help you with a lot of the nitty gritty work. Spring Roo, Play for Java, Grails (Groovy on Rails) are a few that come to mind. These don't eliminate the need to understand the technology but they take care of a lot of the details for you.

[Junilu Lacar]

BTW, I programmed in Clipper, too, back in the day. None of the work I did in Clipper, apart from coding at the very basic level, comes close to comparing what it takes to create a Java application. By "coding at the basic level" I mean writing code to implement your business logic, read files, print reports, all those things are pretty much the same.

At a higher, more abstract level, the software components that you build in Java, the way they are organized, the way they are built, are just way too different as far as I can remember. Granted, my Clipper days were over 15 years ago but still, times were a lot simpler back then. I still remember a story I heard (or read) about the day that they (Nantucket) signed over Clipper to CA (Computer Associates), when all signatures were penned and people were getting up to leave, Brian Russell, the chief engineer or whatever for Clipper supposedly stood up and waved a handful of floppy disks above his head and asked "Uh... who wants the source code?"

[Fred Schauer]

I really appreciate all the suggestions, help, and concerns. I really want to learn java, this is a pro bono project that has no timeline and is something for me to learn on. Its probably about as simple as its going to get. I also have somewhat settled on MySql as the database as it is open source and seems to be quite popular. I'm, just plain tired of the $$ for upgrading to the next version just when the last one was working good, so open source is going to be my choice, thinking about Linux/Ubantu for an OS. I started on computers in DOS so the behind the scenes settings won't bother me.

I'm sure I'll be posting back some more questions once I get going, I think I've got enough here now to start and probably get some books. Any suggestions on current tutorials or current books?

Thanks A Lot!

Fred57

[Blake Edward]

As another beginner I can see the need and the desire to have something tangible and concrete to begin with. You could draw it out with pencil and make the connections on paper. It's less formal that way and allows you to erase, redraw, make notes as needed without feeling like you are taking steps that can't be easily redefined at any moment.

I really like Winston's post. It has in it many good choices that an OO programmer would make. I like the idea of starting (on paper) with a concrete class like Club. If the two clubs that merged are still somewhat separate, need to list their respective members, and do things internally a little different, I can see them as subclasses of "Club". Club could implement interfaces that each SubClub might instantiate and use differently. They might each inherit the same "membership" method but implement them differently.

It sounds like a good project, but a little daunting as a first project. You can see how you could spend weeks just thinking about it before ever writing a shred of code. Like many projects (ones I see at work) they/it can have the tendency to balloon and exceed the original scope of the project at an early stage.

[Junilu Lacar]

Blake Edward wrote:It sounds like a good project, but a little daunting as a first project.

Good project? Yes, I agree. Daunting as a first project? Absolutely. Even for a team of two or three experienced developers, it can be a challenge.

You can see how you could spend weeks just thinking about it before ever writing a shred of code.

Yes, that happens a lot. It even has a name: Analysis Paralysis

Like many projects (ones I see at work) they/it can have the tendency to balloon and exceed the original scope of the project at an early stage.

Yes, this too is common enough to have a few names: Scope Creep, Requirements Bloat and can even be disguised as a Stretch Goal

This is why I'm a big believer of Agile, incremental development, getting some working software quickly, failing fast, and going into maintenance mode ASAP.

[Jacob Anawalt]

Fred,

One thing that really helps me keep going in the face of so much to learn is to learn about small parts and walk through tutorials with example frameworks that helps me see I can create something and gain experience even if it isn't exactly what I intend to use in the end.

If you haven't settled down too much on a particular setup, try the Netbeans Platform CRUD Application Tutorial or something similar. If you can find an example that mixes all the technologies you are interested in working with, like JavaFX and MySQL, great. If not, take them in parts or find reasonable substitutes for learning with. For example the JavaDB (Derby) may not be MySQL, but it is much easier to get going if you're using something like NetBeans (vs installing MySQL and starting and administrating it.)

Happy Coding!

[Winston Gutkowski]

Blake Edward wrote:It sounds like a good project, but a little daunting as a first project. You can see how you could spend weeks just thinking about it before ever writing a shred of code...

Very true, which is why it's important to work out what the essential core of the application is first, and stick strictly to that initially. Once you've got that working; then might be the time to start adding "bells and whistles".

@Fred: And one way to do that is to answer a simple question: Why am I writing this application? And try to keep your answer to 10 words or less.

You'd be amazed how many people - and companies - fail to do it, which is often why applications (and projects) tend to "creep".

One clue to me came from your very first post: You didn't know the classes you'd need; but you were pretty sure that one of them would be Member (or Members).

And just one little tip on that point: Keep your class names singular. If you find you'll need a list or collection of something, try to think of a collective noun that describes it - which, in your case, is probably "Club" or "Society"; but could just as easily be a "Department" or a "Directory" or a "Sales Receipt".

Jacob Anawalt wrote:If you haven't settled down too much on a particular setup, try the Netbeans Platform CRUD Application Tutorial or something similar...

Good advice, but possibly premature. At this stage, I suspect all that Fred needs is to know that his database will probably need to support SQL and JDBC (even if he doesn't end up using it directly), and at the early stages it may even be worth using a more integrated db like Derby or JavaDB, which can actually be packaged in the jar.

Also: One of the things I like about lexical analysis is that it tends to start you off using words that the business understands. Things like 'CRUD' are very "programmer-centric", whereas a club or society is far more likely to use words like "join" or "upgrade" or "cancellation". And the longer you can use words that the client uses, the less likely you are to run into mistakes due to misinterpretation.

My 2¢.

Winston

[Junilu Lacar]

Winston Gutkowski wrote:Things like 'CRUD' are very "programmer-centric", whereas a club or society is far more likely to use words like "join" or "upgrade" or "cancellation". And the longer you can use words that the client uses, the less likely you are to run into mistakes due to misinterpretation.

Emphasis mine.

Yes! A now relatively famous guy named Eric Evans actually wrote a book exactly about this. One of the ideas mentioned all throughout the "Domain Driven Design" book or simply, "The DDD book," is that of a "ubiquitous language" that is comprised mainly of the words and phrases used by the people who work in the target domain. This is also the same idea behind "Domain Specific Languages".

[Junilu Lacar]

Winston Gutkowski wrote:possibly premature. At this stage, I suspect all that Fred needs is to know that his database will probably need to support SQL and JDBC (even if he doesn't end up using it directly), and at the early stages it may even be worth using a more integrated db like Derby or JavaDB, which can actually be packaged in the jar.

My advice would be to stay away from any database concerns for as long as you can. Concentrate on the objects and their behaviors and interactions first. The danger with going at it from the database side first is that your mental model of the problem and its solution will tend to become skewed in favor of the relational database model. One major problem you have to deal with when you're programming an OO application is that of Object-Relational Mapping (ORM). There are various and well-established patterns for dealing with ORM problems but they are almost always, if not always, based on an Object-centric view, not a Relational-centric view. It's difficult to apply those patterns if you start with a Relational-centric mindset.

The team that developed the popular FitNesse testing tool supposedly deferred any decisions about the database they were going to use for almost a year. By that time, the team had discovered and learned so much about the software from continuous use, testing, and refactoring that they realized that they could just keep their "temporary" solution of using the file system and plain old text files as persistent storage. The use of the database became an option that required a custom plug-in to be created. It turned out that hardly anyone uses that option anyway. When it is used, a custom plug-in can be written in a matter of hours or days, which is exactly what one of their early customers did. That validated their decision for them. By deferring their decision about using a database, they literally deferred it out of relevance and saved themselves a ton of time and effort that they were able to invest in creating features that were actually useful.

When programming an Object-Oriented application, it's better to focus on the objects first, not the database.

[Winston Gutkowski]

Junilu Lacar wrote:My advice would be to stay away from any database concerns for as long as you can. Concentrate on the objects and their behaviors and interactions first. The danger with going at it from the database side first is that your mental model of the problem and its solution will tend to become skewed in favor of the relational database model...

Yup. I'd certainly go along with that - although I suspect we're basically saying the same thing: Don't cast anything in stone too soon.

Winston

[Winston Gutkowski]

Junilu Lacar wrote:Yes! A now relatively famous guy named Eric Evans actually wrote a book exactly about this. One of the ideas mentioned all throughout the "Domain Driven Design" book or simply, "The DDD book," is that of a "ubiquitous language" that is comprised mainly of the words and phrases used by the people who work in the target domain.

There's only one qualification I'd put on that: As an analyst, one of your tasks is to sort out the "what" from the "how", and sometimes that involves highlighting mistakes in the client's view of the world. And that can be darn hard.

Example: I once had to write a little system to maintain a database for a frozen food distributor. This involved keeping track of their vans and refrigeration units, which were very expensive boxes that were designed to fit inside each van. The problem was that their paper system identified the fridge unit with the van, right down to using the van's license plate to identify each fridge, because 99% of the time it worked just fine, and it was simpler for them to simply equate a "van" to a vehicle AND its fridge unit combined.

It proved a very difficult thing to try and explain because, although I knew it wasn't normalised, it was what they were used to; and even after asking questions like:

Do your vans start out life with fridges in them?

Do your fridges start out life inside a van?

Have you ever had an accident that resulted in transferring a fridge from one van to another?

and getting them to understand that fridges and vans weren't the same thing, it didn't seem like a problem to them.

The answer to that last question was "Sure. It's happened a couple of times. We just re-label the fridge" (most of their paperwork was organised by "fridge ID"). I even got accused of trying to get them to "change their way of working" for no good reason; and it wasn't until I was able to track down a discrepancy in their fixed assets system, which was due to a "transferred" fridge that had the wrong date for depreciation that I was finally able to convince them that there was a problem with their existing procedures. And even then it was a tough slog.

Welcome to analysis.

Winston

[Junilu Lacar]

Winston Gutkowski wrote:...it wasn't until I was able to track down a discrepancy in their fixed assets system, which was due to a "transferred" fridge that had the wrong date for depreciation that I was finally able to convince them that there was a problem with their existing procedures. And even then it was a tough slog.

Being an agent of Change isn't easy. "That's just the way things work around here" has the inertia of a mountain. Lucky for you, you found a lever long enough.