Notice from mastercomputers:
I had to change my description of an object after being hit over the head by my missus. Women are not Objects, though it did make it more interesting to read and hopefully by what I say you can make your own judgement. Sorry if I offended anyone but I was sure this would make people Think in Terms of Objects better.
Introduction
In everyday life we are exposed to Objects yet we may not think of them as such
Take the aerial for instance, this object is connected to an antennae which receives broadcasting signals and directs it back to your TV, how it is doing this is the implementation that this object was developed to do and in most circumstances does not need a thorough understanding by the end user of how it does it as long as you get your reception on the TV. This object can also accept a connection from your VCR which shows how the aerial can be a reusable object and suitable for other object.
The electrical power outlet is what you would want your own objects to be like, it is such a large ordeal that many objects of all shapes and sizes interface with this yet how many people really appreciate it.
Off-topic:
We currently had another large scale black out that wiped the entire power of our major city losing millions in revenue, this is when people started to appreciate it and now many questions are asked as to why this happened, who is to blame but more importantly, how can they resolve it so it will never happen again, since this is the second time it happened and we did not learn from our first mistake.
On-topic:
This shows how great your own objects can become and there are many developers who have created such objects that have benefitted the programming community, just remember you could develop that next big thing. Again however, it is not vitally important to the end user as to what drives the power to this electrical outlet, it could be a nuclear power plant, hydroelectric resservior, wind powered or even solar powered. This is just the implementation that is behind the scenes and this is how you can make your objects act like, where end users should not need to worry about what goes on in the background as long as in the foreground it does what they want.
So What Makes an Object?
This is quite a tough question and to be honest, I would answer with something obscure and riddling that would sound good yet cause more confusion. It is best if we dissect it and take out what is common amongst objects in a programming language and although I don't claim to properly answer this question, I do claim to shed some light on what an object could be and hopefully that light clears up some of the things that helps you make your own conclusion as to what a programming object could be.
If we look at real world objects which I believe a lot of programming objects are based on, we can see some concepts that are similar for programming. In another thread which related similarly to objects and classes I talked about a dog as an object. For this I'm going to use the dog, but I'm going to introduce two new objects to clarify it even more, the owner and the trainer.
Objects usually share two characteristics that should be for any object. This is properties and methods, terms that are related to programming so don't confuse our numerous definitions used in the English language. The property is basically instances that gives meaning and description a place. A dog, owner and trainer can each have a name property which is how we can refer to these objects individually, indirectly or even in a group. Sometimes you will call the dog by it's official name, other times you may decide to change it's name depending on the dogs behavior (which is another term for method). If DOG is BAD call it MUTT. The object is the dog that we are doing a comparison on, we are evaluating it's behavior or state that it is in or performing at that time (instance) and then using a method to change it's name property and then triggering an action or event that then makes us use our own behavior or method as a result of it. Now how was that for psuedo-code or shedding light on the subject?
As you can see these things usually come naturally to us, which is how we would want to model our objects. The more natural you can make your object operate, the more likely you will be successful.
So our dog consists of many properties, which can have many methods for how we can manipulate it. Some properties can not be altered which in our case are constants like the breed of the dog, other properties can vary like the name, color, state the dog is in, it's hunger, etc. Giving our dog a name and then providing it with natural methods that dogs may possess like barking, wagging tail, etc. Is just part of describing that particular dog, in a larger scale we can have an object that describes all dogs and what they are capable of doing, like for instance I'm referring to DOG which is a larger object that encapsulates those animals into that one group. This object is what makes it a good idea for interfacing all your dogs into, because they gain all the same functionality and it should be common, of course there are some things you must change in the object but you provide these methods so that those changes can be made without much hassle. There's some things in this object that classifies that the particular animal I am actually talking about is actually a dog and can fit perfectly in this class. I may have gone too far and out of basic scoping so I'm going to bring it back now.
So we have a dog, an owner and a trainer. I was never good at telling jokes, so I'll leave that for someone else.
So we have a dog, an owner and a trainer, the dog can interface with the trainer to learn new tricks. The trainer has methods to teach the dog new trick. Basically the trainer is extending the dogs capabilities and providing it with new methods or functionality that allows the dog to perform new tricks. This is showing objects interacting with each other, which is what objects should be capable of doing if the interface is correct. It's not meant to be possible to plug the aerial into the electrical power outlet, but it is possible none the less, though the electrical power outlet may not provide this object with what it provides the TV with it still has a method to handle it and that is what you must think about too, what other methods must your object provide to make sure that it's intended use is not abused, thi s should help you think about error handling and not missing the aerial, it too must have it's own way of handling errors too. The electrical power outlet decides it'll send a current down the aerial, the error supplies the current with a means to travel its wire and when it hits the atennae the atennae uses it's method to explode or catch on fire, or something drastic that it never knew it could do before.
The owner as an object, sets some of the varying properties of this dog, by giving it a name, the owner has methods of handling this dog, though the owner may not know what the dog actually wants, the owner still has a means to work with the dog.
So we have 3 separate objects, each having similar properties but different methods, when thinking about objects, it's a good idea to think about building blocks and separating your code so it does not become hard to maintain. Also helps that you do not need to have the trainer around all the time, because once the dog learns the new trick, the object of that dog should now reflect that it has learnt that method and can now perform it successfully without a trainer and the owner should now understand that the dog has learnt this new trick and has learnt a method of calling the dog and making it perform that trick. These are all happening at different times, but are happening, and the objects are updating themselves to reflect these changes.
So back to the question, What is an Object?
Well you can see that objects can be anything and everything, that is why explaining it in programming terms is quite hard, because literally everything in your program is an object, each character, each defined type, everything. Even properties are objects, even methods are objects, they each share characteristics of objects that suggest it's an object, so no matter what your missus says or methods she takes towards your actions, it's true. However chosing the right class to define the object is where all this error handling and assault usually arises from.
Properties are more commonly the constants or variables within the container or other containers, Methods are more commonly the functions and actions that are triggered or called upon to manipulate our properties or properties of other objects.
You Talked Too Much and I Still Can Not Think In Terms of Objects
Look around you everything is an object, the toughest part is the implementation, what actually drives the object to perform its operation.
I just pressed the switch on the TV to turn it on. I changed it's state property to being powered-off to being powered-on, the implementation that works with the action of me pressing that button is the coding you must think of performing for it, so I changed it's state, I must now call on another object to supply me power, another object to supply my reception, while inside my own contained object, I need to direct the electrical current to the correct components which means I have objects inside of my own object. If I were to explain every little detail about objects then I would be here forever, e.g. Now that the electrical power outlet is supplying the power, I must direct it to a fuse, the fuse being it's own object determines what to do with it and possibly passes it off to a capactitor (another object), which then performs it's methods and then sends it off maybe to a resistor, diode and so on.
I know if I did explain every little detail, I would have written the ultimate guide, but time is a factor that controls my methods.
That is why I'm leaving the coding aspects up to you, thinking about every object you require in your program is the daunting part about programming but must take place, but one thing I do think everyone needs when programming is to have fun with it. Try things out, make it perform badly, correct it, do everything you can possibly think of for your program, especially trying to get it to interact with incompatible objects and you're on your way to wasting time I know, but there's too many serious programmers out there who want to get the job done, and want it done quickly while the efficiency of their program and programming style reveals their true nature. I do not want to be known as a serious hardcore programmer with years of experience behind me and the ability to help many succeed in life, I just want to share knowledge and help others improve where I left off and in the same respect they can help me continue my quest for more knowledge.
I could have based this purely on code but I find reflecting it against real and known objects easier to think of than saying I'm going to write a file handling class, the properties I want to have is the name of the file, the extension the file uses, the attributes I can set on this file, the owner and location, etc and for the methods I would like to have the ability to rename the property, change the attributes so that it makes the file read only, etc. These are the things you have to sit down, jot on a pad and really dig deep into what you really want to get out of the object you are going to develop.
This message was proudly brought to you by MC with additional input from my missus.
Cheers,
MC
