The Graph Theory in C# (Part 1)
Many developers agree that the best way to express the world in code is through object-oriented programming, or OOP. OOP basically represents everything as objects. In fact, modern OOP languages have the "object" as the base or root class of everything, including the traditionally primitive types like char, integer, float, double and Boolean. From the most basic to the most complicated, they are all just objects in OOP.
While it may seem for most people that an object, say a black ball, is a black ball in all angles however you look at it and there can't be so many ways to describe it, different OOP programmers programming a black ball could actually come up with tremendously varied approaches and strategies to fully define it. Some may go with just the basics of defining a black resizable sphere. Others may add in some attributes like hardness, materials, textures and weight. Some would add features that could let it obey, or disobey, the laws of physics. And still some would add so many special features to it that the result could become a radical abstraction so far out of this world, it may allow for the creation of the most unimaginably unthinkable instance of a black ball.
Why is this, you ask? Well, for one thing, OOP does not set limits. In fact, this is just as true with any programming paradigm. Truly, if you ask a programmer, given a problem where there is at least one hint of a solution, translating it to program code gets the common "everything is possible" mantra.
Now, think about an object of study in discrete mathematics called the graph (Graph Theory). If you haven't done so, you can read about it in here. Or you can just trust me on this one that, putting it plainly, graphs are simply so complex, it even got its own glossary page in Wikipedia. Now imagine that and a software developer tasked to program the graph. If something as seemingly common and simple as a ball cannot be described in more or less the same way by different OOP programmers, can you visualize how much worse it would be for graphs?
I had a problem at work where we needed to analyze a set of thousands of interconnected objects. We were able to flatten them out in to two lists: the list of objects; and a list of those objects linked with the other objects. I needed a way to extract portions of these linked objects to help make our analysis and planning for the project less overwhelming. In this sense, the solution thought of was to process the data in to graphs and subgraphs.
With that in mind, I started researching about how to program graphs in C#. I'm telling you now so I won't have to say "I told you so", it was a huge waste of time and energy. As if our data was not overwhelming enough, the great Internet showed me that there are equally hundreds, perhaps even thousands, of ways that various developers are suggesting how to program the graph theory.
I couldn't find a solution on the Internet that satisfied my criticisms and judgement. Eventually, it brought me to a realization: perhaps I was doing it the wrong way -- wherein I was reading about it in other people's codes, instead of actually reading and learning about graphs per se.
That started my quest to building my own C# library for graphs (Graph Theory). I feel good about what I came up with. It's not what you would expect. In fact, you might find it disappointing. Regardless, I like what I did because it implements the basic definition of what a graph is: G = (V, E). That to me is more important.
While it may seem for most people that an object, say a black ball, is a black ball in all angles however you look at it and there can't be so many ways to describe it, different OOP programmers programming a black ball could actually come up with tremendously varied approaches and strategies to fully define it. Some may go with just the basics of defining a black resizable sphere. Others may add in some attributes like hardness, materials, textures and weight. Some would add features that could let it obey, or disobey, the laws of physics. And still some would add so many special features to it that the result could become a radical abstraction so far out of this world, it may allow for the creation of the most unimaginably unthinkable instance of a black ball.
Why is this, you ask? Well, for one thing, OOP does not set limits. In fact, this is just as true with any programming paradigm. Truly, if you ask a programmer, given a problem where there is at least one hint of a solution, translating it to program code gets the common "everything is possible" mantra.
Now, think about an object of study in discrete mathematics called the graph (Graph Theory). If you haven't done so, you can read about it in here. Or you can just trust me on this one that, putting it plainly, graphs are simply so complex, it even got its own glossary page in Wikipedia. Now imagine that and a software developer tasked to program the graph. If something as seemingly common and simple as a ball cannot be described in more or less the same way by different OOP programmers, can you visualize how much worse it would be for graphs?
I had a problem at work where we needed to analyze a set of thousands of interconnected objects. We were able to flatten them out in to two lists: the list of objects; and a list of those objects linked with the other objects. I needed a way to extract portions of these linked objects to help make our analysis and planning for the project less overwhelming. In this sense, the solution thought of was to process the data in to graphs and subgraphs.
With that in mind, I started researching about how to program graphs in C#. I'm telling you now so I won't have to say "I told you so", it was a huge waste of time and energy. As if our data was not overwhelming enough, the great Internet showed me that there are equally hundreds, perhaps even thousands, of ways that various developers are suggesting how to program the graph theory.
I couldn't find a solution on the Internet that satisfied my criticisms and judgement. Eventually, it brought me to a realization: perhaps I was doing it the wrong way -- wherein I was reading about it in other people's codes, instead of actually reading and learning about graphs per se.
That started my quest to building my own C# library for graphs (Graph Theory). I feel good about what I came up with. It's not what you would expect. In fact, you might find it disappointing. Regardless, I like what I did because it implements the basic definition of what a graph is: G = (V, E). That to me is more important.
Comments
Post a Comment