Re: Slightly OT: Programming with Modules

["Ken Keefe" <kjkeefe@gmail.com>]

Well, doing what you are doing is a good start. To be able to think
about design like that, it mostly comes from experience. Keep reading
source code and books that talk about source code. My English teacher
in Junior High always told me that if you want to learn to write well,
read good material. That holds true for coding as well. Try to focus
on projects with a decent sized dev team and look at more than one.
The three you were talking about are excellent examples. If you
dissect a project written by one or two people, you may or may not be
getting the best example. With a dev team of 10 or more, chances are a
lot better that you will have a good example. Bigger sizes sort of
forces teams to code well or crash and burn...

Also, when reading source code, don't go line by line, file by file.
Pick a feature out about the application, for example, the login
process for media wiki. Then start with the UI and work your way down
into how it is processed and how it interfaces with the DB. Take on
small features first and then try to tackle bigger ones. If you get
stuck on a piece of code and can't figure out what it is doing, send
their dev list a mail asking or ask in their dev irc channel. However,
don't get stuck on a piece of code and then stop. Maybe write down a
note that you need to figure out what the deal was with that for loop
on line 320 of amazing.php, but keep moving and just leave that as a
black box for now. Chances are that the next piece you look at will
help you discover what the last piece was.

One other suggestion that I wish I had had at the point you are in
life. As you learn to program, it is REALLY important that you don't
get too focused on a particular language, or framework, or project.
You need to first learn the concepts of programming at a fundamental
level. Learn how to optimize a loop, not how to make gcc optimize some
framework for performance on an AMD64. That sort of knowledge comes
and goes fast, learning the real theory behind coding will last you a
long time and it will make learning all that other stuff a lot easier.

However, I consider myself a computer scientist above anything else,
so perhaps my view is a little skewed. I'm sure other members of the
list will disagree and share their point of view. I guess that's what
makes this, my 2 cents.

After rereading this, I think it is all valid but perhaps did not
directly answer your question. So, allow me to do that now.
Modularization is usually done by designing (not in code, usually) a
basic layout of what your application is and what it does. Start by
looking at your application as one big massive entity. Then, begin
breaking down the original application into pieces and then those
pieces into pieces and so on. Next, identify which of these pieces are
core pieces, they basically hold the application together and are
something you probably don't want or need to change. The rest are most
likely peripheral features that aren't necessary individually, but
taken together actually are the real meat of your application. Now,
treat these peripheral pieces as little applications by themselves.
What is the bare minimum for how these little applications need to
interact? These are the hooks, which are typically just an
well-defined set of functions that any module must provide to be
considered a valid module of  particular type.

For example, I've dug into the mediawiki project a little and I know
that authentication is modularized so that people can write things
that allow for authentication via LDAP, text files, or other
mechanisms. If you take a look at the basic authentication module in
mediawiki, you'll see that it has a required function called
authenticate($user, $pass) (this may be dated, it's been a while).
Basically, whenever a user logs in, the core parts of the mediawiki
code call the authenticate() function in whichever the active module
is. Here's some more on hooks:
http://www.mediawiki.org/wiki/Manual:MediaWiki_hooks .

Finally, take a good look at Object Oriented Programming. Modular
programming in its technical form is kind of out of style. Currently
the big thing is OOP and it is used all over the place. And, in most
of the places it is not used, people are trying to move to an OOP
design strategy. By it's very nature, it demands you think of the
world in a modularized way, OOP just doesn't call it modules.

Hope that helps some. Sorry for being so long winded. But, like I
said, I wish I had been told all that when I was finishing high
school.

Ken

On 2/17/07, Mark Thurman <met1204@charter.net> wrote:
> I'm a young programmer (just finishing high school) who has done a fair
> amount of programming with PHP, MySQL, and other web technologies.
> However, being self trained, I was wondering if the members could help
> me with some questions.  I am looking at projects such as PHPNuke,
> Wikipedia, phpBB2, etc and they all have modules, extensions etc.
>
> How does one go about designing a program so it can be extended later
> with plugins, apis, and modules?
>
> For example, in Wikipedia, to add a "Special" page, you include that
> page's source code in the main file, and then voila, it appears in
> lists, links, and adds its own functions and links to the code?  How
> does one think and design a program so that functionality is possible?
>
> I've tried reading source code from some of these projects and I never
> can just follow along myself.  Therefore, if anyone has some simple code
> they'd be willing to share, links to only books or howtos, or just
> personal experiences, please reply on or off list.  If I haven't made
> myself clear, please ask for clarification.
>
> Thanks for your help,
> Mark
>
>
> -
> To unsubscribe, send email to majordomo@silug.org with
> "unsubscribe silug-discuss" in the body.
>

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.