Sharpening The Blade: Paradigms and Patterns

The Test


Preliminary test: Is MVC a programming paradigm, or a programming design pattern?

Scroll to the bottom of this post to see the answer. If you answered correctly with 100% confidence, and could explain it to a 5 year old, you may close this web page.

Otherwise let the learning begin...!

The Reasoning


A lot of the people in the Information Technology industry forget their Computer Science roots over the years. Binary trees, database principles such as CRUD or ACID, principles of procedural programming, and so on. If we don't use them then who cares right? Well it turns out companies in particular care. They want you to have strong theoretical knowledge. But to be honest maybe you find yourself starting to care too. You take for granted these data structures or concepts you use but can't put terms to, and it makes you look sloppy.

Today is the beginning of your re-education.

This will be a series of short articles that will help you improve as a computer scientist, mostly for programmers out of Academia for awhile. You're expected to have touched or have learned these things already, and these will act as a refresher - to jolt your memory. Believe me you know these things, you just have to remember! Remember who you are and why you became a programmer! (To be the best, of course :)

The Lesson


Personally before I began this endeavor I didn't even see a clear line between what a programming paradigm or design pattern were. "Aren't they the same things with different names?", I thought. After some searching, no, they aren't. Lucky for us there is a clear distinction between the two too!

Here is how I mentally separate the two:
Paradigms are "styles". Programming paradigms are ways to...structure code? NO.


Try again.

Programming paradigms are ways to code.
It's like martial arts. There are many ways to fight. Many fighting styles! That's easy enough to remember, right? Programming paradigms = fighting styles.

So a design pattern could be...like a fighting pattern. Like using 3 punches and 1 kick in that order, over and over because it's effective. It's structured fighting, not just random flailing.

Design patterns are ways to structure code.

Fighting Styles


Lets list some common programming paradigms [deadlink] then:
  • Imperative - no control structures like ifs, whiles, fors, or even functions. Everything is computed line-by-line.
  • Structured - has control structures, but still no functions.
  • Procedural - has control structures and functions!
  • Object Oriented - computation is done by passing messages to objects, which hold behavior and sometimes state.
  • Functional - a paradigm with a great increase in popularity lately. Uses only functions to pass state and perform computations.
  • Logic (Rule-based) - just throwing in a paradigm no one talks about. Code is structured in such a way that instead of describing how something is done, you ask what something is.
You can see that paradigms can be composed. This composition has a proper term, called "multi-paradigm". Remember that, it's a really important term! Programming languages have to support paradigms. Some languages only support 1 paradigm - others many! For example Java supports the Object Oriented paradigm, whereas Swift is a multi-paradigm language, supporting Object Oriented and Functional paradigms. You could argue Java supports even more, and I would agree, because Object Oriented paradigms are inherently using the Procedural paradigm (which uses Structured, which uses Imperative...!). Functional though doesn't inherit any of these. It is a different beast all together, but can be combined with other paradigms if the programming language supports it.

Wow. Now you're a flipping programming paradigm master. Take that you snarky University graduates. Lets move on to design patterns baby!

Designing Code with Patterns


Design patterns are a little tricky sometimes. I guess visually they are difficult to distinguish. A paradigm is more integrated, you almost don't even "see" it. It is a part of the language.

A design pattern is less so. You can see a design pattern because it's literally just a structuring of code. Maybe you're using the Decorator pattern, where you "wrap" functions in a function that runs before or after. A more familiar pattern maybe, the MVC pattern, visually breaks up code into three components to separate concerns. There are TONS of design patterns. Personally I only know a handful. To fix this I'm beginning to review the list of design patterns at least once a week, because they can be powerful assets to have. While researching about design patterns though I learned something interesting. There are actually multiple categories of patterns!

There are 5 categories of design patterns: Creative, Structural, Behavioral, Concurrency and Architectural.

At first it will seem to be extremely difficult to come up with design patterns for these. Like what the hell is a "creative" design pattern?! Creative...create...a way to create things? Maybe a generator-like thing that spits out values? Or how about objects?? We've just defined a Factory Creative design pattern! So that's what Creative design patterns do - they create things in a certain way.

Structural is a bit more difficult to describe. They have an effect on the structure of the code and make expressing certain things more easy. For example the Adapter pattern creates an interface for a class that might be used with many other classes that originally had incompatible interfaces. Instead of recoding them all, we simply added a "structural construct" to help out. Which is what design patterns and supposed to do - make our lives a little easier and more organized.

Behavioral patterns don't seem to be too popular. They're patterns that emerge from communication between objects. For example, the Null object pattern is about there being an object that represents NULL, but instead of crashing the program (normal behavior), the NULL object sends an empty message, and the program continues (modified behavior).

Concurrency design patterns are pretty obvious. Essentially any structuring of code that helps with creating concurrent applications. An extremely common example is the Lock pattern, where you use Mutex locks to lock resources. I was surprised to find this was design pattern, but when you think about it, it is a pattern that is used all the time.

Architectural is really simple too. MVC. Enough said. Lets keep this short and simple.

So bam! You know how to identify design patterns a mile away now. The next step is to take a look at a few and read about them. At the next code walk-through you can explain how you used all these fancy-shmancy design patterns...

Congratulations


And that's it for our first re-education lesson. It doesn't really end here though. You need to take this knowledge and apply it in your work. Don't just forget about it again! Force yourself to create little examples to really make it sink in.

Keep being awesome - see you later!

----

Answer: It's a design pattern.

Comments

  1. This blog awesome and i learn a lot about programming from here.The best thing about this blog is that you doing from beginning to experts level.

    Love from

    ReplyDelete
    Replies
    1. Thank you, comments like this mean a lot to me. I hope to produce more articles soon.

      Delete

Post a Comment

Popular Posts