Programming Paradigms

nicholasjames

If you asked me a week ago what programming paradigm I tried to follow, I'd probably answer, "Until it works", or more likely, "Until the error goes away." However, I've recently been discussing the different ways of handling general tasks in NetLinx and have been trying to solidify in my mind what my particular "style" is and, more importantly, how to explain it.

As far as a specific paradigms are concerned, I was only instructed on object-oriented programming during my java days. Though I learned through certification, and other AMX written code, how AMX prefers to handle certain concepts, there doesn't seem to be any specific technique they use.

To be honest, I've only recently been reading up on this subject and, let's be honest, it's been mostly on Wikipedia. So, as I get the ball rolling, I apologize if I use phrasing that no self-respecting computer scientist would. For example, on the subject of modules in general, I would describe them as code that does one simple thing (like talking to a display), blindly reporting out to whoever is listening, while blindly accepting commands from whoever happens to know their language. Want to put that info on a touch panel? Then make a new module that knows the same language and only reports to the touchpanel what the display module just said. See? Sounds more like I'm describing Lilliputians than elegant lines of code.

I've heard it said that programmers discussing their style of programming is akin to discussing politics and religion. I think some of the discussions I've read on this forum bear that out! Risky or not, I'd still love to discuss how you think about code and, if any, what technique (or mix thereof) you think works best for NetLinx.

catalino

Netlinx event structure is mix of Behavior patterns, all wrapped up in a Module pattern. If you want to get serious about design patterns, look at the Design Patterns book produced by the Gang of Four.

It's much easier to use modern design patterns into Duet, mainly because you'll find a lot of Java examples of design patterns out there, and if you're unfamiliar with the purpose of the pattern you will find it difficult to translate into a netlinx-language equivalent. But roughly think of modules as objects(even though they are not) that can be instantiated. It's not quite 1:1, but it gets us far enough.

DHawthorne

I try to encapsulate my modules as much as possible to make them act like objects. It's doable to an extent, though at times not worth the trouble.