Non-modular code sucks!

Today I went to the trouble of fitting some of my existing code for audio hardware output. That code is basically a C++ class that wraps the PortAudio library into a more convenient form. Now, the problem I encountered is that the class had dependencies bolted in from another application’s code. What I had to do today then was to remove all the includes, member variables and methods referring to that other application’s classes. So not exactly a “plug and play” experience. 😦 Making the code compile wasn’t a too hard exercise (took me about 15 minutes this time), but a similar situation could be imagined where making things compile and run would be much more difficult, taking hours or even days.

This could have been prevented by using a more modular approach back when I was writing the engine class. Say, if I had the PortAudio engine class refer only to a simpler audio data provider class interface. Well, I had not planned that before…So what happened, is that I just today made the PortAudio engine class take in and use the base audio object class of my new application. But perhaps this would be a good moment to think about the more modular approach? Will I bother?

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s