I graduated in 1990 in Electrical Engineering and since then I have been in university, doing research in the field of DSP. To me programming is more a tool than a job.
I agree with you. Definitively I do not like the "everything is an object" approach or code with a hierarchy of classes with a very fine resolution. I remember a library that had something like "abstract socket," "abstract TCP socket," "socket that eats bytes", ... "RTP socket" and so on. Honestly, a mess.
I program in Ada (that allows OOP, but not forces it on you) and my choice if defining a class (a "tagged type" in Ada jargon) or a normal type is if I expect to need hereditary or polymorphism or if I need to "factorize" some common code. For example, in a program that reads different formats it can make sense to have an "abstract parser" that defines the interface that an "input parser" must have and then for every format there is a parser handling it. This makes much simpler to add new parsers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you. Definitively I do not like the "everything is an object" approach or code with a hierarchy of classes with a very fine resolution. I remember a library that had something like "abstract socket," "abstract TCP socket," "socket that eats bytes", ... "RTP socket" and so on. Honestly, a mess.
I program in Ada (that allows OOP, but not forces it on you) and my choice if defining a class (a "tagged type" in Ada jargon) or a normal type is if I expect to need hereditary or polymorphism or if I need to "factorize" some common code. For example, in a program that reads different formats it can make sense to have an "abstract parser" that defines the interface that an "input parser" must have and then for every format there is a parser handling it. This makes much simpler to add new parsers.