On this post, I’m going to talk a bit about diagrams. More precisely, Fluxogram and Class diagrams. And a little talk about data structured and object oriented programming.
On previous posts, I’ve mentioned that I’d rather use procedural programming than object-oriented one. The reason is because, procedural or data structure oriented programming is simpler and less obscure in my point of view. Simpler, because you only have to think on Data Structures, Functions to manipulate them and Algorithm. While in Object-Oriented Programming (OOP), you have to think on (obscure parts) classes, private/public/protected functions or methods whatever you call them, enhance, polymorphism, objects and, finally on algorithm. Well, there are so many things to think before programming in OOP… to my head, is extremely easier to think in data structures and functions, even though when I have to modify or extend functionalities of an amount of functions.
Although, I like Python programming. Yes, I know. It is OOP language. However, Python is a very flexible OOP language… actually, it is a sort of hybrid language because you decide if you wanna program in object-oriented or not. It is not like Java. Java is a very, very unflexible OOP language which follows all the theories of an object-oriented programming. (I’m comparing to Python style). However, in terms of community and performance, Java has evolved and conquered fellows many more than Python or other OOP languages, I guess.
Well, let me focus on the intention of this post :)… I know, I was way off.
The focus of this post, is about fluxograms and class diagrams. This won’t waste so much time.
Today, I was thinking about an algorithm and I started sketching my mindmap into a paper. I started doing blocks and conditional blocks. What I was actually doing was fluxograms. I noticed how fluxograms can be essential to any programmer sometimes. Then, I remembered OOP. People from software design tend to think class diagrams first before having an algorithm. So, I put myself in a position of an software engeneering student. I don’t know about how software engeneering experts think :), but… beginner students, maybe I know… I think they tend to think first in class diagrams before any algorithm.
The difference between a fluxogram and class diagram is that, fluxograms maps algorithm… HOW to behave… how the system flows are or how the program will flow. While class diagram, tell us (the problem is here) HOW to make, how many objects I should use, how many connections between objects and so on. The guy who use fluxograms think algorithmically, while who use class diagrams doesn’t or at least, tend not to think on it… or maybe mixed between how to make and what to make… a messy :). So, that is why I think fluxograms can be extremely useful.
You might think, “You’re thinking in a small programs”… well, actually I’m not… I’m gonna use an example. Linux kernel. This kernel and many tools from Linux are built on C, right? Data-structured language. It works. There are thounsands and thousands lines of codes. There is no class diagram. There is no plenty and unnecessary docs. There exist important things about docs. Function names and what they do. Data structures and for what purpose, they exist. Also, there are scketches such as fluxograms. Pseudo-codes.
The other drawback that I see on class diagrams is that… a class diagram may limit the “power” or flexibility of an OOP language, such as Python. How to program in Python, how to think when you write down codes in python is different compared to Java, for example. I think, a class diagram suits well in Java because Java follows all the OOP language theories… it seems that UML (class diagram) was designed to work only with Java. 🙂
Well, for who are fan of Java, I’m sorry if I said something awkful hehe :).. but you know, anyone has his/her own opnion. 🙂
The goal of this post, is to encourage you to think about pros and cons of fluxograms and class diagrams; and OOP and non-OOP.
Thanks for reading.