Split Paths
Join us, as we take a deep look into OOP (Object orientated programming) and the fundamentals of how to do it.
Split Paths
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.
Join us, as we take a deep look into OOP (Object orientated programming) and the fundamentals of how to do it.
Split Paths: Basics of Object orientated programming
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.
As a green programmer, you too have a choice of paths: the easy way, or object-oriented.
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...
Split Paths Video Transcript
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.
Why OOP?
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 harder 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.
Got A Question?
