Re: [dev] Conversation with Anselm R. Garbe of suckless.org

2009/9/14 Amit Uttamchandani <atu13439_AT_csun.edu>:
> 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?

Can't speak for python, I have very limited experience with python.
Though what's wrong with function pointers to unit test functions?
(Instead of class/interfaces that just have a test function?). Or even
less coupled, what about a test case per executable, that way you can
test using very different approaches from a shell script and/or
Makefile.

> 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.

I don't like this approach. What's wrong with struct composition and
some type field at the struct's beginning? Using that approach you can
write quite generic functions that deal with different types. Eg

typedef struct _GenericType GenericType;
struct _GenericType {
   int kind;
   union {
       SpecialType1 type1;
       SpecialType2 type2;
   } type;
};

then you can use GenericType as argument or return type, but
specialise the handling for each of such values based on type->kind
and cast accordingly. In fact it's pretty much smilar to what your
colleage does with his macros, but more honest and clear imho.

Kind regards,
Anselm
Received on Mon Sep 14 2009 - 18:15:07 UTC