Comments on: The Most Important Things They Don’t Teach in CompSci 101 (but should): Maintainability http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/ Just slightly more than my twitter stream. Fri, 20 Nov 2015 19:10:40 +0000 http://wordpress.org/?v=2.5.1 By: Isaac http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/#comment-3813 Isaac Wed, 06 Jun 2007 21:51:13 +0000 http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/#comment-3813 <blockquote>Are you advocating <a href="http://en.wikipedia.org/wiki/Object_composition" rel="nofollow">composition</a> for is-a relationships?</blockquote> Programming is all about trade-offs. There are cases where inheritance makes sense, and composition is more awkward; my point is that they're fairly rare, especially compared to the vast number of cases where people use inheritance simply because some CS teacher said "this is how you extend objects." I advocate composition for most relationships. It's more flexible, usually easier to implement, and more transparent. That being said, in cases where is-a makes the most sense, then a classical inheritance may be appropriate. For example, if you are going to write a game with "monster" objects and "player" objects, and they behave <em>almost</em> the same but with fairly slight differences, then perhaps it makes sense to have them both inherit from an "agent" class. If this is a tile-based sprite game, it most certainly does <strong>not</strong> make sense for "agent" to inherit from "sprite" which inherits from "tile" which inherits from "pixelArray." An "agent" object should have a sprite object. A sprite object should have a location and a tile array. A tile object should have an array of pixels. Inheritance hierarchies should be as shallow and transparent as necessary, while intuitively expressing the nature of the objects involved. In practice, in most cases, that means "Don't use inheritance."

Are you advocating composition for is-a relationships?

Programming is all about trade-offs. There are cases where inheritance makes sense, and composition is more awkward; my point is that they’re fairly rare, especially compared to the vast number of cases where people use inheritance simply because some CS teacher said “this is how you extend objects.”

I advocate composition for most relationships. It’s more flexible, usually easier to implement, and more transparent. That being said, in cases where is-a makes the most sense, then a classical inheritance may be appropriate. For example, if you are going to write a game with “monster” objects and “player” objects, and they behave almost the same but with fairly slight differences, then perhaps it makes sense to have them both inherit from an “agent” class.

If this is a tile-based sprite game, it most certainly does not make sense for “agent” to inherit from “sprite” which inherits from “tile” which inherits from “pixelArray.” An “agent” object should have a sprite object. A sprite object should have a location and a tile array. A tile object should have an array of pixels. Inheritance hierarchies should be as shallow and transparent as necessary, while intuitively expressing the nature of the objects involved. In practice, in most cases, that means “Don’t use inheritance.”

]]>
By: Geoff Moller http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/#comment-3812 Geoff Moller Wed, 06 Jun 2007 21:17:31 +0000 http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/#comment-3812 <blockquote>If you ask me, don’t buck the epistemological trends–use the methodology that we use for everything else, and extend using has-a instead of is-a.</blockquote> Are you advocating composition for is-a relationships?

If you ask me, don’t buck the epistemological trends–use the methodology that we use for everything else, and extend using has-a instead of is-a.

Are you advocating composition for is-a relationships?

]]>
By: Isaac http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/#comment-3799 Isaac Sun, 03 Jun 2007 22:18:01 +0000 http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/#comment-3799 Absolutely. If things are done "right," and the code is designed with maintenance in mind, then it *should* be best for a junior dev to take care of maintenance. Reading code and documentation is educational, and it frees up the senior developers to do the more complicated work. All I meant to illustrate was that experienced developers must take care to design systems that are easy to maintain, since the maintenance programmer is probably walking in blind. Absolutely. If things are done “right,” and the code is designed with maintenance in mind, then it *should* be best for a junior dev to take care of maintenance. Reading code and documentation is educational, and it frees up the senior developers to do the more complicated work. All I meant to illustrate was that experienced developers must take care to design systems that are easy to maintain, since the maintenance programmer is probably walking in blind.

]]>
By: SeventhCycle http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/#comment-3797 SeventhCycle Sun, 03 Jun 2007 05:30:01 +0000 http://isaacschlueter.com/2007/06/the-most-important-things-they-dont-teach-in-compsci-101-but-should-maintainability/#comment-3797 "Maintenance is sloughed off onto the least experienced developer in the team." The reason for this primarily is that a more experienced developer should be the one to engineer interaction between different parts of the program. Granted, there may be bugs that are interface related, the idea is that a maintenance person can fix things within one module without breaking any others. This doesn't mean it works, but I understand their reasoning. “Maintenance is sloughed off onto the least experienced developer in the team.”

The reason for this primarily is that a more experienced developer should be the one to engineer interaction between different parts of the program.

Granted, there may be bugs that are interface related, the idea is that a maintenance person can fix things within one module without breaking any others.

This doesn’t mean it works, but I understand their reasoning.

]]>

Warning: fopen(/var/www/isaacschlueter.com/public/wp-content/cache/meta/wp-cache-c57910014d71cf021fcf2f3770705114.meta) [function.fopen]: failed to open stream: Permission denied in /var/www/isaacschlueter.com/public/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 378

Warning: fputs(): supplied argument is not a valid stream resource in /var/www/isaacschlueter.com/public/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 379

Warning: fclose(): supplied argument is not a valid stream resource in /var/www/isaacschlueter.com/public/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 380