Could you add this feature (to General Features). I've markeg OOD, but this is like calling Wolfenstein3D a 3D game
4
Component Oriented
Started by Guest_Mithrandir_*, Jun 20 2006 01:48 PM
12 replies to this topic
#1 Guest_Mithrandir_*
-
- Guests
Posted 20 June 2006 - 01:48 PM
I can see Object Oriented Design, but Componet (or Interface Oriented) is better, but is not metioned Could you add this feature (to General Features). I've markeg OOD, but this is like calling Wolfenstein3D a 3D game
Could you add this feature (to General Features). I've markeg OOD, but this is like calling Wolfenstein3D a 3D game
#2
-
- Members
-
- 1239 posts
Senior Member
Posted 21 June 2006 - 08:56 AM
What's the difference between OO or Component? That component is better designed?
#3 Guest_Mithrandir_*
-
- Guests
Posted 23 June 2006 - 02:11 PM
Component is like pack of classes. When you are designing with components your program is like a group of bricks (or mayby rather blackboxes) communicatig via interfaces.
For example: you have engine with skybox, terrain, main rendering, collisions. Each one as separate component. So if someone else is using your enginge need only knows interfaces of each component. And, if this teoretical person want to put their own code for example skybox code, all he(she) needs to do, is to write component with interfaces defined by you.
COD is more flexible and scalable. You can use OOD and COD but you don't have to.
I don't know, is that clear? My english is so horrible
For example: you have engine with skybox, terrain, main rendering, collisions. Each one as separate component. So if someone else is using your enginge need only knows interfaces of each component. And, if this teoretical person want to put their own code for example skybox code, all he(she) needs to do, is to write component with interfaces defined by you.
COD is more flexible and scalable. You can use OOD and COD but you don't have to.
I don't know, is that clear? My english is so horrible
#4
-
- Members
-
- 152 posts
Valued Member
Posted 23 June 2006 - 04:44 PM
You could be describing OOD the same way you describe COD... Object = Component...
#5
-
- Members
-
- 247 posts
Valued Member
Posted 24 June 2006 - 05:16 PM
I agree with what Mithrandir said, although the distinction is certainly not as cut & dry as in functional vs imperative vs OOP. COD simply makes more emphasis on components being as independent of each other and interoperable as possible.
Consider the UNIX environment: many small programs completely independent from each other, but designed to be combined in standard ways (pipes and command line).
Consider the UNIX environment: many small programs completely independent from each other, but designed to be combined in standard ways (pipes and command line).
#6
-
- Members
-
- 152 posts
Valued Member
Posted 26 June 2006 - 02:58 PM
There is already words that describe the degree to which components work together, its called Cohesion and Coupling. No need to make up a new term for it. In general you want to minimize coupling and maxamize cohesion.
Coupling and Cohesion
EDIT: Added link for people who haven't read about coupling and cohesion before
Coupling and Cohesion
EDIT: Added link for people who haven't read about coupling and cohesion before
#7
-
- Members
-
- 751 posts
Senior Member
Posted 26 June 2006 - 03:04 PM
I think the OP is trying to distinguish a *form* of OOD.
Interface driven coding *is* OOD. OOD is basically just an umbrella term for various styles of coding.
Interface driven coding usually is more prevalent in Java/C# (I believe those two languages don't allow multiple inheritance at all, but allow multiple interfaces to inherit from... Or maybe that's only Java?), although COM makes use of it as well as DirectX and the like.
What did the OP want us to do? To mention it in the Wiki? Or to have it as a 'checkbox' in the engines list?
I'd be alright with writing a quick section about it in the wiki under engineering and the like. But for beginner coders with very little OOD skills, interface coding might be a bit much to start with.
Interface driven coding *is* OOD. OOD is basically just an umbrella term for various styles of coding.
Interface driven coding usually is more prevalent in Java/C# (I believe those two languages don't allow multiple inheritance at all, but allow multiple interfaces to inherit from... Or maybe that's only Java?), although COM makes use of it as well as DirectX and the like.
What did the OP want us to do? To mention it in the Wiki? Or to have it as a 'checkbox' in the engines list?
I'd be alright with writing a quick section about it in the wiki under engineering and the like. But for beginner coders with very little OOD skills, interface coding might be a bit much to start with.
#8 Guest_Mithrandir_*
-
- Guests
Posted 26 June 2006 - 08:12 PM
I'd asked about checkbox in engines list :] But information on Wiki would be helpfull for everybody It's good to know, that you still have something new to learn 
So maybe both thins?
It's good to know, that you still have something new to learn So maybe both thins?
#9
-
- Members
-
- 751 posts
Senior Member
Posted 26 June 2006 - 10:23 PM
Well, I agree with the idea of having perhaps a discussion of it for new developers.
The checkbox idea.... Well, I'd personally try and avoid having checkboxes on something that could be a rather long laundry list (Does it use Interface design? Is it Procedural? Does it make use of Functional paradigms? Etc). Ideally, if there was some easy way to quantify how modular/easy-to-modify an engine is, I'd like to see that. But scales from X-Y are highly subjective.
Also, how the code is organized/laid out *technically* can be encapsulated by your own OO wrapper. Hence why C based API's haven't died out. They might not be the preferable way for someone with an OO mind to code - but they're easily wrapped with data adaptor classes and the like.
Anyhow, that's just some of my personal feelings on the subject. Hope I didn't tread on anyones sensibilities too loudly. :)
The checkbox idea.... Well, I'd personally try and avoid having checkboxes on something that could be a rather long laundry list (Does it use Interface design? Is it Procedural? Does it make use of Functional paradigms? Etc). Ideally, if there was some easy way to quantify how modular/easy-to-modify an engine is, I'd like to see that. But scales from X-Y are highly subjective.
Also, how the code is organized/laid out *technically* can be encapsulated by your own OO wrapper. Hence why C based API's haven't died out. They might not be the preferable way for someone with an OO mind to code - but they're easily wrapped with data adaptor classes and the like.
Anyhow, that's just some of my personal feelings on the subject. Hope I didn't tread on anyones sensibilities too loudly. :)
#10 Guest_Mithrandir_*
-
- Guests
Posted 27 June 2006 - 04:11 PM
Yes, but if there is checkbox for OO so why not to put there checkbox for CO ?
#11
-
- Moderators
-
- 1842 posts
DevMaster Staff
Posted 27 June 2006 - 04:15 PM
eddie said:
Well, I'd personally try and avoid having checkboxes on something that could be a rather long laundry list (Does it use Interface design? Is it Procedural? Does it make use of Functional paradigms? Etc)
Then use flags and display it as an int (preferably in hex). We're all developers here...
C++ addict
-
Currently working on: the 3D engine for Tomb Raider.
-
Currently working on: the 3D engine for Tomb Raider.
#12
-
- Members
-
- 751 posts
Senior Member
Posted 27 June 2006 - 04:59 PM
Heh: .oisyn. ;)
Anyhow, Mithrandir: my point being that we don't want a scattering of checkboxes for everything, do we? Especially since CO is simply a type of OO.
I believe the aim right now was to have a checkbox to differentiate between an OO language and a procedural one -- two big umbrella terms that could have many different implementations. Why give special consideration to CO?
Anyhow, Mithrandir: my point being that we don't want a scattering of checkboxes for everything, do we? Especially since CO is simply a type of OO.
I believe the aim right now was to have a checkbox to differentiate between an OO language and a procedural one -- two big umbrella terms that could have many different implementations. Why give special consideration to CO?
#13 Guest_Mithrandir_*
-
- Guests
Posted 28 June 2006 - 02:39 PM
Of course, that CO is kind of OO. But have you ever use COMs? There is much more power in it.
What is a difference for end user between procedural and OO engine? Once again: there is much easier to replace part of engine in COD. There is more possibilities to do user-wanted changes, to update engine online if one is using COD.
If you have OO engine, you probably have hundreds of classes with different connections between them. And if you want to make changes in someone’s code... ugh... this is heavy. COD force designer to organize code in packages (components), so work with this code is simply easier. One could organize code in such a way without COD, but… how to be sure if this is done well?
I as mentioned at the beginning – I’ve check “OO” when filling form for my engine (which is pending so long...). But I wanted to be sure, why is no “CO” checkbox there. CO is now pretty popular technique everywhere, so I was little surprised
Ok... maybe it will be better to shut up now
What is a difference for end user between procedural and OO engine? Once again: there is much easier to replace part of engine in COD. There is more possibilities to do user-wanted changes, to update engine online if one is using COD.
If you have OO engine, you probably have hundreds of classes with different connections between them. And if you want to make changes in someone’s code... ugh... this is heavy. COD force designer to organize code in packages (components), so work with this code is simply easier. One could organize code in such a way without COD, but… how to be sure if this is done well?
I as mentioned at the beginning – I’ve check “OO” when filling form for my engine (which is pending so long...). But I wanted to be sure, why is no “CO” checkbox there. CO is now pretty popular technique everywhere, so I was little surprised
Ok... maybe it will be better to shut up now
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
