A question for OOP experts. - page 3
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Creature.
Flora/Fauna
Subspecies
Species
Family
etc.
Is that what you want?
Well it's a simple inheritance from the base entity "Entity".
But you can go deeper than that - there are single-celled/multicellular, and that's all to living things. But there are also non-living ones. It all depends on tasks, for which you need to find properties of a base object, and inherit from them.
If you're really nuts, you can get to atoms and start dividing them into parts in search of a fundamental parent object (be careful - a fission reaction can become a chain reaction, and you'll destroy half of the world :))
Right. At first glance, the concept of OOP is ideal for building a hierarchy. But how do you work with a hierarchy built through OOP? It is a sea of syntax and complexity of transitions between links because of the access rights to the classes and their contents. This is where the overhead begins, as a consequence of division into classes. On the one hand OOP allows to build a hierarchy, on the other hand it makes it extremely difficult to work with it.
Well, no. OOP gives very easy access to any member of the hierarchy in any location.
Start by finding your base object with the minimum required properties.
The rest of the objects inherit from it. To avoid reinventing the wheel, your base object should inherit the CObject class of the standard library. This allows you to create your own hierarchy of objects without any need to re-invent the lists
CObject --> CBaseObject --> your hierarchy.
In CBaseObject you must have a virtual method that returns this object. Then each of your descendants will have this method accordingly, and it will return exactly the descendant object. The base class of CObject already has a method -Type(). If you have the same virtual method of CBaseObject, and it will return the type of object, you will know what object you have accessed.
It's like a basic foundation for all your objects. And they should all be stored in their own lists - each list will only contain objects of one type - fish, animals, humans, gods, etc.
That is, you will need to have a list for each subtype. And there must be one list, which will contain the following lists in the hierarchy. Each of these lists must also have lists - again - that are next in the hierarchy. And so on.
I.e., you need also a base list object, in which you will place the required lists. And this base list must have a Type() method, and there must be a method that allows you to return any object stored in it by its index. Then, if this is done, you will automatically have a method in any of the lists that returns the required object.
In general, you have to think through your foundation object first, and then your list object. You don't have to create object-lists either, they already exist.
And then it's a matter of technique. And you only need to know the type of object you are looking for. There will be many types in its hierarchy, and each of them is known to you and you can request and receive it.
As it seemed to me, it has nothing to do with OOP in this case.
In Peter's case, all the objects in the array are searched for by some key. And there is no difference if you use classes, if you use arrays, if you use a bunch of declared objects at all.
OOP allows to have a list of objects, each of which, say, has the GetColor() method - and the user goes through all objects in search of the right colour. But, if without OOP - we have an array of identical structures, which the user needs to know about, to get the colour from where it is necessary, with the OOP - the user does not need to know exactly how and where the colour is stored - the GetColor() method of the object knows, where to get the colour.
So, for OOP - the user does not need to know how and where the colour of the object is stored. So, if we suddenly need to add an "object for the blind", in which the colour is encoded by Braille dots, we can easily add this object to our list and change only its GetColor() method, which would receive colour code from the dots in Braille and return it in regular form. For the user of our list, nothing will change.
If we have just an array - we can't put "braille dots" there. We have no such field in it.
The benefit of OOP is really well seen when we inherit from CObject, then create an array of objects CArrayObj, and then, by writing only comparison function - we immediately get the ability to quickly sort and binary search.
Roughly speaking, for my example above, with colour - for OOP - we write a comparison function, getting colour through GetColor(), and we can sort our objects by colour, even without knowing that we have half of objects with real colour and half with "braille dots".And if we want to add an object with new colour coding - again we just need to write GetColor() function, which would bring its colour representation to standard - and then already writtensorting and searchingalgorithms will accept this new object without problems.
That is, in fact, OOP allowed us to have a sorting and search algorithm for objects not yet written, before we've even decided how exactly they will be represented by a colour and how it will be stored.
The benefits of OOP are really clear, when we inherit from CObject, then create an array of objects CArrayObj, and then, by writing only comparison function, we get fast sorting and binary search.
It's a sea of syntax and difficulties with transitions between links because of access rights to classes and their contents. This is where the overhead begins, as a consequence of the division into classes. OOP on the one hand allows you to build a hierarchy, on the other hand it makes it extremely difficult to work with.
access rights modifiers allow to detect errors at compile time
In general, all this does not complicate the work with classes, do not use it, write everything in public: and then it will be easier to work with them.
SZZY: A lot of nice phrases about OOP, encapsulation and inheritance... This is all good, but the most important advantage of OOP over other programming styles is storage of all data (class fields) and functions of work with these data (class methods) in one place (class) - in book it is encapsulation. Further the use of OOP depends on the task, if the task allows to scale classes, hierarchy will be needed and there will be base classes and their descendants - whether to use it, depends on you
I must admit that in the OOP concept, "Object" is presented in a wider context than in my "Kernel". But, this is not surprising, since I have so far only dealt with graphics, and OOP is used for a wide range of tasks. My "menu" of objects is rather sparse and apart from "label", "element", "window" there's probably not much else... However, for graphical interfaces there isn't much more I need.
However, the question of extending the concept of "Object" and building a hierarchy has now arisen. A simple two-dimensional kernel cannot accept the entire variety of knowledge base objects and therefore either a different kernel for different objects should be created or the concept of OOP should be followed.
In essence, this is a purely technical issue. Which is more efficient, which is faster, which is more readable, etc...
Indeed, you can simply keep all objects in an array as a list of properties, among which will be pointers to other arrays, with other objects and so on. Oryou can explicitlyuse OOP. Object orientation is invariably present in both approaches, only the methods of implementation are different. The same memory, the same pointers, the same objects, the same classification. Only the code form is different...
I wanted to tell Peter about this when he understands the concept of data storage that has been proposed to him.
I will try to understand this concept of storing and handling data.
Okay. (chuckles) We can chat in person about the subject. Or on Skype, as you prefer. It's just that the specifics are not on the topic of this thread - here, as I understand it, are just general questions.