Head First Object-Oriented Analysis and Design

Author: Brett McLaughlin, Gary Pollice, David West
All Stack Overflow 28
This Year Stack Overflow 3
This Month Hacker News 1


by rpeden   2018-02-16
Oh wow - this is actually a really big and important question.

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...

[3] https://spring.io/guides

[4] https://mitpress.mit.edu/sicp/full-text/book/book.html

by anonymous   2017-08-20

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:

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:

Additionally, it would be good to check out:

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.

by anonymous   2017-08-20

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

by anonymous   2017-08-20

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())
by anonymous   2017-08-20

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
enter image description here

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.

by anonymous   2017-08-20


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.

by anonymous   2017-08-20

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