system at June 20th, 2006 09:48 — #1
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
ed_mack at June 21st, 2006 04:56 — #2
What's the difference between OO or Component? That component is better designed?
system at June 23rd, 2006 10:11 — #3
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
nodlehs at June 23rd, 2006 12:44 — #4
You could be describing OOD the same way you describe COD... Object = Component...
jare at June 24th, 2006 13:16 — #5
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).
nodlehs at June 26th, 2006 10:58 — #6
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
eddie at June 26th, 2006 11:04 — #7
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.
system at June 26th, 2006 16:12 — #8
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?
eddie at June 26th, 2006 18:23 — #9
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.
system at June 27th, 2006 12:11 — #10
Yes, but if there is checkbox for OO so why not to put there checkbox for CO ?
oisyn at June 27th, 2006 12:15 — #11
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...
eddie at June 27th, 2006 12:59 — #12
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?
system at June 28th, 2006 10:39 — #13
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