Java

10-Jul-12 21:19

No one is going to provide a full solution in this way, you need to start by doing your own research into the classes and Java frameworks that will help you. Start here[^] and see which of these can be of use to you.

How do I decide for class responsibilities?

Neo101018-Jul-12 5:56

8-Jul-12 5:56

How do I decide what types to make and what responsibilities to give them, given a design concept? Should I base myself on user stories/functional requirements in order to decide which responsibilities my classes need?

It's not easy to adhere to the SOLID principle.

For example I have this.. 'make a blog' assignment. I wrote down one of those functional requirements: "a blog entry has to have a title and a body". Does that mean I have to write a class Post with members Body and Title?

Should a Post (BlogEntry) class only have a body and the title is supposed to be the responsibility of another class?
Kind of confusing.

There must be a set of rules that tell programmers how to decide on which objects to make and what responsibilities and implementation to give them.

Any ideas on this?

Thanks

Nagy Vilmos8-Jul-12 6:31

8-Jul-12 6:31

This is something that gets easier the more you practice. Start by writing down in PROPER prose what the software will do. Now take all the nouns out, they are your candidate classes.
Firstly find the items that are synonyms - blog, post, posting and entry will most likely be used to reference the same thing. Then have a look at what is left and if the items actually perform anything or if they just record a state. If all they are recording is state, then they are probably attributes rather than classes. In your case, I think you'll find the body and title are probably just attributes.

However, there is not a single way to do these things and it is an experience thing that will tell you which is best. Alas there is not really enough here for me to give you a fuller answer.

Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett

Neo101018-Jul-12 7:44

8-Jul-12 7:44

Hmm.. I learned that the method of taking out nouns and looking at verbs is incorrect. It is more abstract.

Nagy Vilmos8-Jul-12 8:19

8-Jul-12 8:19

So your 1 semester class trumps my 25 years of experience, well done.

I said it is a starting point. With EXPERIENCE you don't need to bother and you can see the classes inherent in a system easily, but that comes with practice. Lots and lots of practice.

Neo101018-Jul-12 8:44

8-Jul-12 8:44

Excuse me? I come from a university with one of the highest reputations there are. We program and work the qualitative way. This isn't one semester. It's my graduate year. I'm actually going to be an Application Developer. There's only so far you can get with 'practice' and 'experience'. Fundamental concepts and methods are far more important. That's why the top engineers get higher ranked without doing the work. Didn't you ever learn that? The tons of math and logic theory I had to process before I came to this point. The years of lectures on Software Engineering. Never underestimate the importance of scholar theory.

Nagy Vilmos8-Jul-12 8:49

8-Jul-12 8:49

Dear boy, I have been there already. FYI, I recently did another degree course - exactly to get an update on the academic theory - and noun/verbal extraction is still a very valid and useful exercise. When, or if, you work professionally, you will understand that there is so much within the problem domain that impacts how classes are decided upon.

Experience is the dog's doo-dahs in deciding how to break down a problem domain to find candidate classes.

Richard MacCutchan8-Jul-12 22:22

8-Jul-12 22:22

CsTreval wrote:
I come from a university with one of the highest reputations there are.

Soon to be lowest.

CsTreval wrote:
I'm actually going to be an Application Developer.

With this attitude you are bound to go far.

Nagy Vilmos9-Jul-12 8:31

9-Jul-12 8:31

Undergraduates are so sweet when they think they know things.

Stingrae7899-Jul-12 4:02

Stingrae789

9-Jul-12 4:02

My graduate university is ranked among the lowest in England, even they taught us that even with experience there is always more to learn. Education is great but never tie yourself to it, what works in theory doesn't always apply to every situation. In industry experience is worth more atleast until you actually have had a few jobs.

Software development is the one field where a specific degree doesn't necessarily make you better than Joe Bloggs who self-taught. Also experience > actual software developed > education as far as I can see

Also lose the idea that top people get paid to do practically nothing you will find that even some CEOs work over 9 hours a day, design and planning may be what they (top engineers) actually get paid for but that still involves thinking and much of that comes as the result of experience.

Neo101019-Jul-12 6:48

9-Jul-12 6:48

Right. At your university they never taught you in the advanced English class about the Dilbert principle? This happens in real life too, you know? Hence the principle. I know some people who get paid very highly and I chat with them for about 50% of the time I'm taking lectures. What does this imply? Well, it implies that they are sitting on their chair all day being lazy and getting paid huge salaries (because I know his function). It used to be that the really hard working and intelligent people were bumped up to manager. Now it's the other way around. If you really believe that hard working smart people get the better salaries, you're wrong. I've experienced nothing like it in the real world. I've worked before as well. I've been programming on a 3 month contract in a company my university suggested. The programmers were just absolutely horrible and cynical people. They were also not very bright. I knew more about programming and computers than they did. Anyway not to drift off the point here. Experience certainly may help in the IT industry of today, but if it wasn't for my university's high reputation (because they have excellent courses and professors) I wouldn't even have had the slightest chance to function as a temporary programmer in a company. I tried before. You have no idea how many 'no' answers I got. Meanwhile, a top paid programmer I know who works for one of the best software development companies can only type with two fingers and can't even do a copy paste in Excel! How fair is that?! Yes, what a world. With hard work you get somewhere.. please.

Dave Kreskowiak9-Jul-12 7:11

Dave Kreskowiak

9-Jul-12 7:11

Wow. That was a bunch of useless, meaningless crap.

Did they also teach you, in your exalted university, that your final year is where you demonstrate that you can apply the techniques and information you've been fed over the last 3 years? If you're asking this question now, it seems that you're in a bit of trouble.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak

Nagy Vilmos9-Jul-12 8:30

9-Jul-12 8:30

Did your super duper university not teach you what a paragraph is?

Legibility. Learn the word and learn it quickly!

Richard MacCutchan9-Jul-12 8:43

9-Jul-12 8:43

He didn't actually say what the University's reputation was for, just that it was the highest.

Nagy Vilmos9-Jul-12 8:48

9-Jul-12 8:48

Top for arrests? Absenteeism? We may never know... Big Grin | :-D

Richard MacCutchan9-Jul-12 9:03

9-Jul-12 9:03

We should be told; time for a judicial inquiry.

Nagy Vilmos9-Jul-12 9:12

9-Jul-12 9:12

Nah. Let's just have a witch hunt.

jschell9-Jul-12 12:13

jschell

9-Jul-12 12:13

CsTreval wrote:
It used to be that the really hard working and intelligent people were bumped
up to manager.

Sigh...what fun to be young again.

I suggest you research the "Peter Principle". You will find that the copyright on the primary book that introduced that was 1969.

CsTreval wrote:
I knew more about programming and computers than they did.

One thing I knew even in college was that is was really unlikely that I know everything. And with that understanding I found that almost (if not everyone) I have ever met has given me the opportunity to learn something.

CsTreval wrote:
Meanwhile, a top paid programmer I know who works for one of the best software
development companies can only type with two fingers and can't even do a copy
paste in Excel!

So there are several possibilities.
1. You do not have any idea what that person actually does.
2. That specific company and/or department is a failure.
3. All companies are like that and thus you will never get a job (because they don't hire people that can program.)

CsTreval wrote:
It used to be that the really hard working and intelligent people ...I knew more about programming and computers than they did

I can't be sure but I would suppose that arrogance is one trait that will in fact lead to...
- not getting hired in the first place
- getting fired once hired.

pasztorpisti14-Jul-12 0:03

pasztorpisti

14-Jul-12 0:03

+5 I agree... to some extent. Being a good coder isn't always enough to get a good salary. The best combination is being a good (at least average) coder and having a level a social awareness, and to have the balls on a job interview. My experience is that having balls and being social is more important to have a good salary than being a good coder. Its enough to be an average coder.
EDIT: You are angry (and sometimes arrogant), but you are on a better way than a hardcore programmer if want good pay - this is also dependent on the place you work at, but in my experience being a very good coder is secondary most of the time. Debating with anger is also a bad habit. If you got angry you lost the match.

modified 14-Jul-12 6:39am.

jschell9-Jul-12 12:01

jschell

9-Jul-12 12:01

CsTreval wrote:
Excuse me? I come from a university with one of the highest reputations there
are. We program and work the qualitative way. This isn't one semester. It's my
graduate year. I'm actually going to be an Application Developer. There's only
so far you can get with 'practice' and 'experience'. ... That's why the top engineers get higher ranked
without doing the work. Didn't you ever learn that?

Ahh...so then why do you not already understand how to do it?

Also given that you already understand that it isn't just black and white what makes you think that it can be answered in the completely general way that you asked the question?

CsTreval wrote:
There's only so far you can get with 'practice' and 'experience'. Fundamental
concepts and methods are far more important.

Absolute rubbish.

I have been responsible for hiring and interviewing people for more than 15 years and the PRIMARY requirement is experience. Education, even a PHD, has almost zero relevance after five years of real experience and has zero relevance when considering actual problem domain knowledge.

Someone with no actual work experience would need to have a half time mentor for at least six months before they could be expected to be fully productive. True regardless of the school they went to.

CsTreval wrote:
Never underestimate the importance of scholar theory.

Nor should one over estimate it. Nor should one think that in the day to day work of creating code that "scholar[ly] theory" has much importance because most of the time it is not relevant.

Andrei Straut16-Jul-12 0:22

Andrei Straut

16-Jul-12 0:22

CsTreval wrote:
I come from a university with one of the highest reputations there are

So do I, even if it's from Romania

CsTreval wrote:
I'm actually going to be an Application Developer

So what? I'm a Software Engineer. I don't think it would've got me my job by itself. Being a Software Engineer / Application Developer / Software Architect / [Insert-another-fancy-title-here] counts for nothing in a company that does real work, if you can't back it up with knowledge

CsTreval wrote:
There's only so far you can get with 'practice' and 'experience'

Yes, and after only 2 years experience, I've found my teachers suck, and have nothing to do with the current technologies and methodologies, most of them proven to work (AGILE as a methodology for instance, or HTML5/CSS3 as techonlogies. Not to mention that those who taught Java had no idea on how to use the language besides teaching the fundamental algorithms (sorting, searching) and data structures (arrays, lists) in it)

CsTreval wrote:
The tons of math and logic theory I had to process before I came to this point. The years of lectures on Software Engineering

Oh yeah, the tons of math, logic, and analog electronics WTF | :WTF:

Now, I'm not saying they might not be useful, but the chance they are is pretty negligible.

I've been through college too, I even studied pretty hard. Nothing of that ever helped during the first few days of my professional career, while I've banged my head on a wall trying to get Tomcat6 to work on a CentOS. Nothing! Then I've learned that school only teaches you the basics, the rest comes from passion and, most especially, experience. Look at the most prominent guys here (I'm talking OriginalGriff, Dalek Dave, JSOP, and maybe others, who I'm sorry for not mentioning right now). How many of them do you think have strong educational backgrounds? And yet, just look at the stuff this guys post, and the articles they write. That, my friend, comes from experience, and not education. I'll take any of these guys anytime over 90% of my college teachers.

Oh, and to end, you know there's an old saying...

Wiser people that you and I said:
Those who can, do. Those who can't, teach

Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.

modified 16-Jul-12 6:39am.

pasztorpisti13-Jul-12 23:40

pasztorpisti

13-Jul-12 23:40

This is code design not a grammar lesson! XD But for some extent your statement is true because some of the nouns usually identify your packages or classes or the data structures you might pack into a single class. Don't rely on methods, use your brain and experience. There is no method that compensates you for not having experience so practice! practice! practice! But on my road learning code design I use the following guidline:

First you have to be able to break down a problem into small pieces, then to break down those pieces into even smaller pieces. This is the most difficult step, you need some coding experience to do this. You have to be able to identify problems and patterns. This way you get a "hierarchy of problems" a "tree of those problems". The root of this tree is your program, some nodes in the tree below the root are packages, and as you go down towards the leaf nodes you will find classes sooner or later. If you break down the problems with enough granulartiy your tree will identify the package and class structure of your program too. Of course you can start this tree from a package or class level if you have to solve only a part of the problems.
Now you have the classes and you have to find out what kind of data, which member variables are needed to solve the problems that belong to a class and you have to put them into the right class, the same is true for the methods that work with that data.

I usually spot out bad code design in a minute, this usually involves code (method(s)) that doesn't work with the member variables of the actual class the method resides in, instead the method uses data and methods that it reaches from other objects. In this case the method should be moved to somewhere else where its most used data resides. If it uses a lot of data from here and there maybe from incoming parameters (or a lot of classes call that method) then it can be put into a helper class as a static helper method.
EDIT: Another bad design is bloat code - huge monolithic classes. In this case the problem the class solves needs to be split into sub-problems and more classes.

modified 14-Jul-12 5:53am.

Pete O'Hanlon9-Jul-12 7:55

Pete O'Hanlon

9-Jul-12 7:55

It is confusing if you concentrate on one item to the exclusion of all else. Take your example; you have a statement that "a blog entry has to have a title and a body". Okay, I can see where you are going with that, but you're now wondering whether or not you violate SOLID to have a body element AND a title element. This is designing in isolation. You need to consider the other requirements to see what effect they have.

For instance, suppose you have a requirement that states that a title must have more than 20 characters and less than 150 characters. Does this mean that you need to create a separate Title class which encapsulates the rules, or do you make it part of the BlogEntry class? Well, that depends - you might want to create a separate validation engine which is responsible for enforcing the rules, in which case you would probably just use attributes on your BlogEntry properties, so the mechanism for defining HOW to validate the properties is external, but the rules for each element are attached (this is a common technique).

Then you need to consider where your rules are applied. Do you do everything in your UI, or do you abstract to a business rules class? Is your BlogEntry class actually a model instead? Should you use MVC?

The thing I'm trying to get at here is that there is no "one size fits all" solution. As others have said, it's experience, but it is also a case that your start and end point has to be "what do I need to put in to satisfy the requirements?" By all means, consider the use cases - a well architected use case should be a vital part of developing your application because it should tell you how the user will actually use your application. Beyond that, adhering to SOLID is a mix of experience and common sense, and you shouldn't slavishly adhere to something just because someone else has written about how good it is.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Nagy Vilmos9-Jul-12 8:23