Split Paths

<p>Join us, as we take a deep look into OOP (Object orientated programming) and the fundamentals of how to do it. </p> <h3>Split Paths</h3> <p>There are two paths to take when learning to program: the easy way, and OOP (Object-Oriented Programming.) Sure, you can start the easy way and migrate to OOP: it's a lot harder than if you'd simply started with OOP from the outset. <br /> Join us, as we take a deep look into OOP (Object orientated programming) and the fundamentals of how to do it.</p> <h1>Split Paths: Basics of Object orientated programming</h1> <p>Years ago I started playing guitar: never had lessons. Several years later I realized I just couldn't get better: finally I went to a guitar teacher. He told me the reason I couldn't improve (sucked, in fact) was because the way I was holding my pick had hosed the flexibility in my hand. I was devastated: I'm telling you this because at that point, I had to take a new path.<br /><br /> As a green programmer, you too have a choice of paths: the easy way, or object-oriented.<br /><br /> Today we learn the benefits of learning to first program using objects, OOP classes. It is fairly notable that programming will be harder in the beginning but will progressively become easier as you learn more and adapt to your coding. On the other hand, you can very well choose to learn coding line by line, bit by bit. This approach is relatively easier to begin with, but programming will eventually become more challenging as you move on to objects and so forth. So, in reality, it's really up to you and how much ability you possess within your learning curve. If you feel as if you are a bright learner and enjoy your work becoming increasingly more difficult as opposed to studying hard, then learn to code the easiest way first. Meanwhile if you enjoy the benefits of an easier-flowing work environment after long nights of hard studying then by all means learn OOP classes first and foremost. By the way if I could go back in time I would cry a bit more and get my mom to pay for the guitar lessons... </p> <h2>Split Paths Video Transcript</h2> <div class="expandable"><pre> I have a small analogy to talk about. A long time ago, I started playing the guitar, and I never really went to a guitar teacher. Retroactively, a couple years after I started playing, I realized that I just couldn't get any better, and I wasn't really that good. I decided to go to a guitar teacher, and that he told me on the first lesson that the reason why I can't get better is because the way I'm holding the pick is really messing up my flexibility in the hand. That was so devastating; to be honest, I don't think I ever really recuperated from then. I'll never be a professional guitar player. Why am I saying this right now? We're at a crosspath between working in this world of object oriented programming where it is the direction of the future of programming as far as we can see, or working the old way. <a href="http://02geek.com/courses/video/6/49/Split-Paths.html">Why OOP</a>? You can work and choose to take that path, but you could choose to work in the more simple path. It's really a choice that you need to make. The reason I made that guitar analogy is because if you choose the more simple path, you could always try and move into the object oriented world. There's no reason not to. But then when you move into the object oriented world, it will be a bit harder to move into it after having learned the other way., If you choose from the beginning to start leaning in that direction, it's going to be much easier than later on to integrate ideas that are object oriented. With that said, it's definitely your choice and one of those things which is kind of like the good and bad is that if you choose the easier path right now it's going to get <strong>harder</strong> programming as time goes on, as you build more sophisticated applications. If you choose the path of working with object oriented programming it's an approach of programming that obviously has been endorsed by Flash and by many other languages. Although it has a lot of overhead, a lot more to type, a lot more things to think about, but by adding these complexities it kind of takes the world of programming into a world that's much more familiar to users, which, what is more familiar to us than objects? If it's a phone, if it's the noise that's in the background that I wish wasn't there, if it's this bottle of water that I have here. All these are objects that I could relate to more easily than just lines and lines of code, obviously. So why am I saying all that? If we work in an environment where we're thinking about objects, we're thinking about grouping things up, even though setting these groupings and getting used to these groupings might be a little bit more hard, if we get used to working with groups and get used to working with objects and things that are kind of like tangible in our heads, as we evolve as programmers, as we add more code, as we get more sophisticated, it's going to be so much easier working. </pre> </div>