On Mon, Sep 14, 2009 at 08:59:12AM +0100, Anselm R Garbe wrote:
> > Just curious as to the arguments against OO programming. All the classes
> > I have taken in uni always trumpet OO. I have been using it ever since
> > but I do agree that it can get out of hand at times.
>
> Let me paste some response I gave recently via priv mail:
>
Thanks for sharing the response, it helped in understanding your
viewpoint.
>
> > My question is that, there are some approaches that 'seem'
> > easier/logical to implement with OO, how does one approach this in a not
> > OO way?
>
> Well that was my excuse when I was a fan of OO as well, that there are
> plenty problems "better solved" using OO. When carefully thinking
> about it, I always concluded, no, this problem is better not solved
> the OO way.
>
> Can you give examples where you think OO is the better choice?
>
Some examples:
1. I designed a software to automate testing of the boxes that we
build. The main language used is Python (I guess it's hard to avoid OO
when using python). Basically the design is such that I have a test
case class that is used when instantiating different test cases
(attributes include: name, status, tester, etc.). How would you
approach this in a non-OO way?
2. A colleague of mine needed to design a packet generation engines for
our box. He used OO concepts in CC by using techniques such as VTABLE,
defines for methods, classes, etc:
/**
* Macros for declaring classes
*/
#define CLASS(CX, SX)\
typedef struct CX *CX;\
struct CX {struct SX super;
#define IMPLEMENTS(IX) struct IX *IX
#define VTABLE(CX, SX) };\
extern struct CX##Class __##CX;\
typedef struct CX##Class *CX##Class;\
struct CX##Class {struct SX##Class super;
#define METHODS };
#define END_CLASS
So then, he can instantiate multiple different engines depending on
processor load, etc.
> Kind regards,
> Anselm
>
Thanks again, this discussion is really helping me.
Received on Mon Sep 14 2009 - 16:16:35 UTC
This archive was generated by hypermail 2.2.0 : Mon Sep 14 2009 - 16:24:01 UTC