Head First Object-Oriented Analysis and Design

How much OOD are you really expecting from the team? Are they legit "never seen java before" kind of devs? do they know the fundamentals? A lot of java programs these days are like a weird mish-mash of functional, oop, and procedural elements. Mastering OOP, for example, won't give them a great grasp of lambda functions, folding, stream aggregates, or other concepts. I'm not expecting Java devs to be busting out UML diagrams with perfect notation at a moment's notice.

I found the Head First book to be really good back in the day for a crash/refresher course: https://www.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678

I'm not sure how it's aged in the last 12 or whatever years, and I remember the writing style to be a bit annoying, but it got the message through.

after that I'd probably send them to Clean Code first (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/).

For just a practical-purpose OOAD, I would bet there are a few articles and online classes you could cobble together for a makeshift training.

https://www.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678

The answer is..

alt text http://headfirstlabs.com/Images/hfooad_cover.gif

http://headfirstlabs.com/books/hfooad/

http://www.amazon.com/dp/0596008678/?tag=forelangstud-20

All "relativity" aside, not fast. Based on the fact that you said you never programmed before...to become a basic programmer, a few years.

And to become a good to outstanding (using design patterns and industry recognized standards that relate to common standards as defined by ISO/IEC 9126 Standard such as testability, maintainability, etc.) programmer, it takes years of experience and coding often.. you do not become "Sr." or an "Architect" overnight and the same thing is true for a mid-level developer who doesn't code slop.

It's always a process where you improve. So learning is relative. But to learn the basics, seems simple until you start to design classes and interfaces. And even Leads stumble on the basics..doing things wrong. Everyone does. There is so much to be aware of.

If you're just going to be adding features (using classes your Lead or Architect has stubbed out for the team) and not really adding new classes, etc. it's easier....but you should take care in coding using standards and you still have to know complex areas of OOP. But that's not really OOP. When you start to creating classes, interfaces and knowing about inheritance, heap, references, etc. yada yada...and REALLY understanding it takes time no matter how smart you are or think you may be.

So, for a new programmer. Not easy. Be prepared to code a lot. And if you are not, find a job where you are. It's all about coding as much possible so you can get better.

Read these books FIRST. Do not dive into any others out there because they are not geared toward teaching you the language in a way you can get up to speed fast:

http://www.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678/ref=pd_bbs_sr_4?ie=UTF8&s=books&qid=1231280335&sr=8-4

http://www.amazon.com/Head-First-SQL-Brain-Learners/dp/0596526849/ref=pd_bbs_sr_7?ie=UTF8&s=books&qid=1231280335&sr=8-7

http://www.amazon.com/Head-First-C-Brain-Friendly-Guides/dp/0596514824/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1231280393&sr=8-1

http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124/ref=pd_bbs_sr_3?ie=UTF8&s=books&qid=1231280393&sr=8-3

they will get you the fasted jump start into understanding, better than any books out there.

Also for these lame type of responses, ignore them:

"Then again, plenty of people (most normal people, non-programmers) never learn those subjects, so if you're like "most" people then the answer would be "it would take forever" or "it will never happen"."

Those come from developers (typically leads) who have some Ego trip that DON'T want you to learn. Everyone learns differently and at different paces and eventually you will become "fast". I get very tired of hearing Sr. developers say statements like this when their sh** also stinks many times no matter how good they are. Instead they should be helping the team to succeed and learn as long as their team is working hard to keep abreast and doing what they can on their own as well (not leachers).

Make sure you try to get a Jr. Level Developer position first...

For Java, yes, the head first series as others have suggsted. That is my favorite series of books. I've read over 2 of them and both were great. As well as the Java one, you should also get the OOD one: http://www.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678/ref=sr_1_1?ie=UTF8&s=books&qid=1263239109&sr=8-1 Object Oriented design is at the heart of learning Java.

Also, if you want to go a little cheaper, the Java tutorial is excellent IMO. There is a lot of meat there and its defiantly fast and easy to progress through. Check it out here: http://java.sun.com/docs/books/tutorial/ Go down to the section header "Trails Covering the Basics" and start there.

Learn the paradigm and then which language you choose matters less.

Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D alt text http://ecx.images-amazon.com/images/I/51eQgNjOOWL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU02_.jpg

I would start with : Head first object-oriented analysis and design. and once you mastered it : Head first design patterns.

The things you've listed sort of split into two separate categories: Paradigms/Architectures, and specific tools.

I'd focus on the Paradigms and Architectures first - those are the skills that will be portable across tech stacks and will be useful for a longer period of time.

For OOP, I actually enjoyed Head First Object Oriented Analysis and Design [1]. The Head First books aren't for everyone, but I like they way they encourage you to do exercises to help reinforce what you've learned.

For RESTful services, I found Roy Fielding's original PhD dissertation on REST[2] to be quite helpful for a conceptual overview. It's a long read, but I enjoyed it.

For Spring and Spring Boot, I've found the official Spring guides[3] to be better than any of the books I've read. So many Spring books seem to go out of their way to try to be as long as possible. The guides, on the other hand, tend to be short and to the point.

As for general books...the one I always circle back to is Structure and Interpretation of Computer Programs[4]. I found that once you've worked through it, so many aspects of programming just make more sense. Lots of people find it a difficult book to work through, but I've found that the more times I revisit the book over the course of my career, the more helpful it is. Every time I read it I seem to have an 'aha!' moment I hadn't experienced previously.

[1] https://www.amazon.com/Head-First-Object-Oriented-Analysis-D...

[2] https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...

Unfortunately, the roadblock you've hit is all too typical in academia. Academic projects tend to start with video rental stores, libraries or student registration systems (yours is a variance of this with a doctor's office) and then inheritance is taught with animals. The guideline you've provided is also very typical

they recommend thinking about what an object can do for its method, and what its responsibilities are for its attributes

In fact when beginners ask I usually explain an object's property's are the things it knows about itself and its methods are the things it knows how to do. Which is really just another way of saying exactly what you have there. As you've discovered this way of thinking quickly breaks down when you start discussing more tangible systems and not just examples.

For instance the guideline works pretty well with this object:

public class Tree
{
    public int Height { get; set; }
    public void Grow(int byHowMuch)
    {
        Height += byHowMuch;
    }
}

While this certainly fits the bill your right to think that it doesn't "feel" right:

public class Secretary
{
    public void MakeAppoinment(Patient patient)
    {
        //make the appointment
    }
}

So what's the solution? It's a matter of taking what you are being taught and applying it. Learning and understanding design patterns will help a lot with developing systems which are more functional than a tree that knows how to grow.

Recommended reading:

• Design Patterns: Elements of Reusable Object-Oriented Software (also known as the Gang of Four or GoF)
• Head First Design Patterns
• Head First Object-Oriented Analysis and Design

To solve the issue you're been presented I would probably use a combination of inherited person classes and interfaces, which would perform their actions through a series of service classes. Essentially a secretary, doctor, and patient would all inherit from person and each of these classes could be passed to accompanying service classes. The service classes may or may not do things like SeePatient(). Please don't take this example to mean that person classes wouldn't have methods.

Stack Overflow has more than a few related questions which may be of use:

• Is Single Responsibility Principle a rule of OOP?
• Are there any rules for OOP?
• why is OOP hard for me?

Additionally, it would be good to check out:

• Single responsibility principle
• Don't repeat yourself
• PrinciplesOfOod

Finally, there isn't a single definition of what makes an application object oriented. How you apply patterns, principles etc. will define your program. The fact that you are asking yourself these questions shows that you are on the right track.

OOP principle - program to interfaces

What does "program to interfaces, not implementations" mean?

For more of OOAD, read this book. It explains majority OOAD principles and techniques very well.

alt text http://headfirstlabs.com/Images/hfooad_cover.gif

This question is probably more appropriate on https://codereview.stackexchange.com/

Not to be rude, but a newbie programmer developing an API is like a first-year med student offering to do open-heart transplants for free. I understand that you believe that you can program, but if you intend to release publicly accessible code, you probably need more experience. Otherwise guys like me will muck through it and file bug reports ridiculing your code.

That said, if you want theory of good API design you should probably check out Head First Object Oriented Analysis and Design. You'll want to focus on these key concepts

1. Program to an Interface, not an Implementation
2. Encapsulate what varies

...and follow other good design principles.

...honestly, there's a lot to cover to good interface and good systems design. You can use this as a learning exercise, but let people know they shouldn't rely on your code. Though they should know that screen scraping is far more brittle and instable than web service API requests anyway, but many don't.

That said, to provide some initial guidance:

1. Yes, use OOP. Encapsulate the part that actually does the scraping (presumably using cURL) in a class. This will allow you to switch scraping engines transparently to the end user. Encapsulate your outputs in classes, which will allow for easy extension (i.e. if JSON output is in a Single Responsibility class and XML Output is in another, I can add RSS Output easily by making a new class without breaking your old code)
2. Think about the contracts your code must live up to. That will drive the interface. If you are scraping a particular type of data (say, sports scores for a given day), those should drive the types of operations available (i.e. function getSportsScoresForDate(date toGet))
3. Start with your most abstract/general operations at a top level interface, then use other interfaces that extend that interface. This allows users to have interfaces at different levels of granularity (i.e. class SensorDataInterface has a method getData(). HeartRateMonitorInterface extends SensorDataInterface and adds getDataForTimeInterval())

Well, you can read just book about open source project, and authors can show what and how. E.g. I read Pro Spring 2.5 and there is even chapter called "Spring Patterns" with explanation of why and how they call files, directories, design patterns they use and invite you to use etc. Probably take a look at the books about open source projects you investigate.

UPDATE (just that paragraph insert to extend answer:) : as I told previously, you can look through the books about open source projects and find there information how this project is developed, architectural issues etc. Once I looked for real good example of "Open/Closed Principle" using, theory is nice but I would not say that it is so clear how to use it. The only book which helped me was Expert Spring MVC and Web Flow (I already pointed you to google books with that chapter I read). I didn't read the whole book, but I am sure it contains a lot of such things (what and how was used to make Spring done). From book Clean Code: A Handbook of Agile Software Craftsmanship I remember that there is a chapter, when they take a code from one open source project and make it better (unfortunately open source does not mean that it is good enough); that book also contain reference to how some other projects where written (e.g. jUnit). I don't know any book, which is completely dedicated to any project, there are just books where is "theory", and books about project which can have some explanation of what is inside. I would recommend books from APress (Pro and Expert series, afaik "beginning" books does not contain such explanation), and Packt Publishing - their main topic is open source.

UPDATE 2 (just can't stop :) Just remembered new series of books from OReilly "Beautiful ...." - I never read it, but I looked through. It actually consists of different stories behind development, real stories from life. I see there is also Beautiful Code: Leading Programmers Explain How They Think - I should contain what you need. Other "beautiful" books can be worth of your time too.

About patterns in general there are a lot of good books, and it depends on what exactly are you looking for. E.g. Head First Design Patterns is quite good to explain common patterns in fun way. If you need more, you can take a look at Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions to see how different applications, systems etc. can be integrated (and how open source projects do it too). Etc. Just specify what patterns or tricks do you want to read about, community will make its suggestion ;)

Some web links out of my bookmarks:

1. Anti Patterns Catalog - know what you are not going to do!
2. Design Patterns and Martin Fowler's Catalog - that's shortly about what is good to use and know about
3. SOA patterns - community site for SOA patterns (integration etc.)

And few more books to take a look at:

1. Head First Object-Oriented Analysis and Design
2. Agile Software Development, Principles, Patterns, and Practices
3. Code Complete - this book is just a bible of how to write code...

people, who develop open source definitely know what are those books about ;)

Hope that helps

UPDATE (25-05-2011) Just found one book, which I definitely going to buy, and I think it perfectly fits your question:

The Architecture of Open Source Applications

Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well — usually programs they wrote themselves — and never study the great programs of history. As a result, they repeat one another’s mistakes rather than building on one another’s successes. This book’s goal is to change that. In it, the authors of twenty-five open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to this book provide unique insights into how they think. Electronic versions of The Architecture of Open Source Applications for e-readers will be available for download soon.

Yikes.

JavaScript seems like a really poor choice for starting a new developer off on the right path. It has the basic constructs of most languages, but weak typing and the Prototype approach to Object Oriented development would be hard to transition away from.

That said, I would first pick up a book on straight Object Oriented programming concepts first. Head First Object-Oriented Analysis and Design seems to be a popular choice around here.

After that, I'd go straight to Obj-C. You'll pick up the pieces you need from C without learning any of the potential bad habits that people sometimes bring wit them from a procedural language like C to an Object Oriented language like Obj-C.

Not a direct answer to your question but O'Reilly's Head First Object-Oriented Analysis and Design is an excellent place to start.

Followed by Head First Design Patterns