Ask HN: What should people know about OOP and program design? | Hacker News Reader

Ask HN: What should people know about OOP and program design?

10 pointsbendmorris3 comments

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.

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?

View on HN

- 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

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 :)

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 :-)

Reply on news.ycombinator.com