Session 1 - Introduction to Object-Orientation

<Meh>

I tried to keep this session as basic as possible so you'll have to excuse the stupid code examples. My audience is also a mixture of senior and junior devs although, I expect everybody that's attending the sessions, to at least know this already. This is merely a "recap".

Slideshow: http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-1-objectoriented-principles
Code Samples: https://github.com/SheepWorx/Training


The question when it comes to OO and refactoring/designing of code has always been... "How far do I take it?". Refactoring is good, but as the saying goes, too much of a good thing, even OO, can be a bad thing.

There will always be risks or concerns that will be allowed due to the usual constraints: time and money.

A good guide is usually anticipating the growth of the business. If you can anticipate what is most likely to change in the near future, then that should give you a good idea of how far to refactor something. Performance is also a good guide. OO is nice and all, but it can introduce a fairly complicated structure in your code and introduce a lot more overhead and instructions. What will you sacrifice more? Performance or maintainability?

For me, the GoF (Gang of Four) patterns are a good start. Industry standard design patterns in general are nice because they're a tried and tested method of solving a particular problem, while ensuring the code is loosely coupled, maintainable, testable, etc. I've always been taught that patterns come and go and yes, there is merit in knowing a few, but in the end it's not knowing the patterns, but thinking in terms of building patterns that matter.

Technologies change constantly, languages change and with that, patterns will change as well. If you can practice building your own patterns, I feel that skill is much more valuable than memorizing a few.

Anyways, I'm getting ahead of myself. This session is just about the basics. Next up after this will be the first of the 5 SOLID principles: The Single Responsibility Principle.

</Meh>