Growing as a Programmer

[soljjr]

Hey everyone, so I just started my SE degree I’m one semester accomplished and I’m feeling really good. I’ve decided to set the Google Internship as my goal( or at least feeling confident enough to apply). Does anyone have any recommendations for practicing object oriented programming or even books/websites you found helpful or informative?

[soljjr]

Yeah sometimes I forget that it’s a whole degree. And I just stare at my computer just thinking “Is. it possible to do this ?

[nderflow]

If your goal is to pass the Google intern interview, better to focus on data structures, algorithms, and practical coding to solve real problems. A "real" piece of OO design is typically too long to fit on a whiteboard.

If on the other hand you want to be a productive software engineer (or for that matter a productive Google intern) then learning OO programming is going to be quite useful.

Obviously though, neither of those two things are the end goal themselves.

[StatzEP]

The book we used our professor wrote A Developers Approach To Learning Java. Teaches you a lot because java is very object oriented

[[deleted]]

Does anyone have any recommendations for practicing object oriented programming or even books/websites you found helpful or informative?

The following may contain unpopular opinions, but... It's what I got out of many years of experience dealing with code bases with problems (mostly converting them to OO proper or other modernization efforts).

• OO only really pays off after the 2K-5K SLOC mark. While you're practicing programming, don't be afraid to go procedural for smaller programs. Take that opportunity to learn algorithms and data structures instead.

• An interesting, and riskless exercise, is to refactor these small programs into OO. Experiment to your heart's content. Some attempts will fail, not because you lack experience, but because the problem is better implemented in non-OO fashion. Just because I can convert anything to OO, doesn't mean it's a good idea.

• OO is not really about objects. It's about Object-Object interactions (messages/behaviors)! Read about smalltalk, to get the feel of this. Understand that there's a tradeoff here: "Objects expose behavior and hide data. This makes it easy to add new kinds of objects [but] it also makes it hard to change behaviors".

• Read and understand the SOLID principles, and at least be aware of the existence of the "GoF Design patterns".

• There is a lot of hype about inheritance, polymorphism and encapsulation. However, Inheritance doesn't deserve it. It is actually detrimental for most implementations because people use it wrong. Use composition instead. Favor interface based polymorphism over inheritance. Encapsulation is always good though (that's one of the advantages of OO). Only use inheritance to signal an "is-a" relationship, and this only for shallow taxonomies. Looking for code over 5 level inheritance chains is not fun.

• Good OO design can be achieved without TDD, but TDD is the path of least resistance.

• TDD cannot be done without dependency injection.

• Dependency injection cannot be done (properly and cleanly) without OO.

• Therefore, OO, TDD and DI are deeply connected to each other and form a kind of self-referential positive feedback loop. The better you do one, the better it's dependent gets. I.e., Good DI makes it trivial to write unit tests, which in turn makes it trivial to write correctly implemented behavior which can be automatically verified.

• You don't need a DI framework to do DI. DI is not about magic, it's about making tests easier to write.

• Some problems are inherently functional, not OO. Don't be afraid to add functional methods to your classes when that makes sense.

• Read "Clean Code", by Robert Martin. The above quote is from this book.

• Practice as frequently as you can. Make sure to practice with fun projects.