The core of object oriented programming

Question

Hi guys,

I am trying to understand the core of object oriented programming for php or actionscript proect. As far as I understand, we will have a Main class that control different elements of the project. For example, photoslider class, music control class..etc. I created instance of those classes inside my Main class and use their method or property to control those objects.

I have studied many OOP articles but most of them only talks about inheritance, encapsulation...etc I am not sure if I am right about this and I would appreciate if someone can explain more about it. Thanks!

Answer 1

It seems like you're asking about the procedures or "how-tos" of OOP, not the concepts.

For the how-tos, you're mostly correct: I'm not specifically familiar with PHP or ActionScript, but for those of us in .NET, your program will have some entry point which will take control, and then it will call vairous objects, functions, methods, or whatever- often passing control to other pieces of code- to perform whatever you've decided.

In psuedo-code, it might look something like:

EntryPoint
  Initialize (instanciate) a Person
  Validate the Person's current properties
  Perform some kind of update and/or calculation
  provide result to user
Exit

If what you're looking for is the "why" then you're already looking in the right places. The very definitions of the terms Encapsulation, Inheritance, etc. will shed light on why we do OOP.

Answer 2

It's mostly about grouping code that belongs to certain areas together. In non-OOP languages you often have the problem that you can't tell which function is used for what/modifies which structures or functions tend to do too many loosely related things. One work around is to introduce a strict naming scheme (e.g. start every function name with the structure name it's associated with). With OOP, every function is tied to a data structure (the object) and thus makes it easier to organize your code. If you code gets larger/the number of tasks bigger inheritance starts to make a difference.

Good example is a structure representing a shape and a function that returns its center. In non-OOP, that function must distinguish between each structure. That's a problem if you add a new shape. You have to teach your function how to calculate the center for that shape. Now imagine you also had functions to return the circumfence and area and ... Inheritance solves that problem.

Note that you can do OOP programming in non-OOP languages (see for example glib/gtk+ in C) but a "real" OOP language makes it easier and often less error-prone to code in OOP-style. On the other hand, you can mis-use almost every OOP language to write purely imperative code :-) And no language prevents one from writing stupid and inefficient code, but that's another story.

Answer 3

Same question , i was asking when i were just starting my career but i understood Object Orientation as i progress in my career.

but for very basic startng point in oop.

1- think about object just try to relate your daily household things like ( your laptop, your ipad, your Mobile, your pet)

Step 2-

Try to relate objects like ( Your TV an your remote ) this gives you the basic idea how object should relate to each other.

Step 3-

Try to visulize how things compose to create a full feature like your Body compose of (Heart, Lungs and many other organs)

Step 4-

Try to think about object lifetime ( Like as a example a car enigne is less useful outside Car , so if car is a object than this object must contain a engine and when actual car object destroys engine is also destroyed)

Step 5-

Try to learn about a polymorphism ( Like a ScrewDriver can take may shapes according to your need then map to your objects if your using c# than try to leran about ToString() method overriding)

Step 6 -

Try to create a real life boundry to your real life object ( Like your House ; You secure your house by various means )

this is the initial learning .. read as much as text as you find and try to learn by your own examples

in the last ; oop is an art first , try to visulize it.

Answer 4

Not sure what sort of answer you're looking for, but I think 10s of 1000s of newly graduated comp sci students will agree: no amount of books and theory is a substitute for practice. In other words, I can explain encapsulation, polymorphism, inheritance at length, but it won't help teach you how to use OO effectively.

No one can tell you how to program. Over time, you'll discover that, no matter how many different projects your working on, you're solving essentially the same problems over and over again. You'll probably ask yourself regularly:

• How to represent an object or a process in a meaningful way to the client?
• How do I reuse functionality without copy-pasting code?
• What actually goes in a class / how fine-grained should classes be?
• How do support variations in functionality in a class of objects based on specialization or type?
• How do support variations in functionality without rewriting existing code?
• How do I structure large applications to make them easy to maintain?
• How do I make my code easy to test?
• What I'm doing seems really convoluted / hacky, is there an easier way?
• Will someone else be able to maintain the code when I'm finished?
• Will I be able to maintain the code in 6 months or a year from now?
• etc.

There are lots of books on the subject, and they can give you a good head start if you need a little advice. But trust me, time and practice are all you need, and it won't be too long -- maybe 6 or 9 months on a real project -- when OO idioms will be second nature.

Answer 5

Hi, my main suggestion is to look at the objects as "smart serfs": each one of these will have memory (the data members) and logic (the member functions). In my experience, the biggest strength of OOP is the control that you have on the evolution of your design: if your software is remotely useful, it will change, and OOP gives you tools to make the change sustainable. In particular:

• a class should change for only one reason, so it must be solve only one problem (SINGLE RESPONSABILITY PRINCIPLE)
• changing the behaviour of a class should be made by extending it, not by modifying it (OPEN CLOSED PRINCIPLE)
• Focus on interfaces, not on inheritance
• Tell, don't ask! Give orders to your objects, do not use them as "data stores"

There are other principles, but I think that these are the ones that must be really understood to succeed in OOP.

Answer 6

I'm not sure I ever understood OOP until I started programming in Ruby but I think I have a reasonable grasp of it now.

It was once explained to me as the components of a car and that helped a lot...

There's such a thing as a Car (the class).

my_car and girlfriends_car are both instances of Car.

my_car has these things that exist called Tyres.

my_car has four instances of Tyres - tyre1, tyre2, tyre3, tyre4

So I have two classes - Car, Tyre and I have multiple instances of each class.

The Car class has an attribute called Car.colour.

my_car.colour is blue

girlfriends_car is pink

The sticking point for me was understanding the difference between class methods and instance methods.

Instance Methods

An instance method is something like my_car.paint_green. It wouldn't make any sense to call Car.paint_green. Paint what car green? Nope. It has to be girlfriend_car.wrap_around_tree because an instance method has to apply to an instance of that Class.

Class Methods

Say I wanted to build a car? my_new_car = Car.build

I call a Class method because it wouldn't make any sense to call it on an instance? my_car.build? my_car is already built.

Conclusion

If you're struggling to understand OOP then you should make sure that you understand the difference between the Class itself and instances of that Class. Furthermore, you should try to undesrstand the difference between class methods and instance methods. I'd recommend learning some Ruby or Python just so you can get a fuller understanding of OOP withouth the added complicaitons of writing OOP in a non-OOP language.

Great things happen with a true OOP language. In Ruby, EVERYTHING is a class. Even nothing (Nil) is a class. Strings are classes. Numbers are classes and every class is descended from the Object class so you can do neat things like inherit the instance_methods method from Object so String.instance_methods tells you all the instance methods for a string.

Hope that helps!

Kevin.