
Ask HN: What should people know about OOP and program design? - bendmorris
I'm helping to teach a university course called Advanced Programming for Biologists. This is the second of a two part course that teaches grad students (and some faculty members) enough of a programming foundation to be able to hack together solutions to problems. We're using Python. The first class covered the basics (data types, functions, etc.) So far we've covered debugging, SQL with sqlite, and version control, among other things.<p>I'll be covering Object Oriented Programming one week and "program design" the next, but I have a lot of latitude in what to present. As hackers, what do you feel would be most important to cover in a setting like this? Any resources you would recommend?
======
calufa
\- abstraction from a design level

\- introduction and importance of cpu, memory, harddrive, network and gpu from
a design perspective

\- teach how to represent data with objects

\- scalability from a design perspective. why performance tuning will safe you
ass in the long road -- explain data-driven-development

\- the power of data and analytics visualizations

\- agile, and why iterating means move fast, and why being dynamic is
important. why quick sprints are better than product releases (3 months of dev
without exposing anything to the user = risk)

\- were we are now in this field, and what others have done and are doing - i
mean Ted-like inspiration

\- its important to understand that design patterns exists and what they do.
but are not really necessary at this point because design patterns are hard
things to crack for people new to programming. yet very powerful way to
abstract the functionalities of the app, and thats why is important to know
what they are. for small projects the use of strong design patterns seem
sometimes a little exaggerated. for new people design patterns can set the bar
really high

------
latch
With static languages, I find that testability is generally the best way to
flush out poor design. In fact, I've argued before that TDD is a design-
process, not a testing process. You can write code, then try to test it, if
it's hard to test, your design is probably wrong.

Do it a couple times on medium size projects, and you don't need to write
tests anymore (for that reason), since what works and what doesn't always
seems to stick really well.

This isn't really true for dynamic languages, since they tend to be much
easier to test (stub anything) and don't have all of boilerpoint crap that's
necessary in the general purpose static languages folk uses(java/c#)

Not sure if that helps :)

------
Michael_K
I would structure the lecture like this:

\- a bit of evolution of programming and why OO was so huge (re-usability of
encapsulated and independent code pieces/modules/libraries)

\- fundamentals about OO - encapsulation, polymorphism, inheritance

\- How to design - UML, class diagrams.

\- Python code examples from biology would be cool. (Tell you class that they
shold imagine to be god. They now create an entirely new planet with all its
animals and living creatures on them). Have them designing a UML, then
present/share/discuss. How does the inheritance look like (chimp -> monkey ->
mammal -> living organism...)

Let us know it it went :-)

