Comments on: The future of software is… Back to the basics http://nutrun.com/weblog/the-future-of-software-is-back-to-the-basics/ nutrun Fri, 08 Jan 2010 06:54:37 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: mv http://nutrun.com/weblog/the-future-of-software-is-back-to-the-basics/comment-page-1/#comment-168 mv Fri, 01 Dec 2006 01:26:34 +0000 http://new-site.nutrun.com/?p=50#comment-168 This is a good article. OO is not going away; what is going away is the attention of a large number of fairly new programmers to the basics, as this article tries to emphasise. Before OO, there was structured, and before that, modular prorgamming. But the fundamental principles go to the very first assembly language macros and routines: encapsulate, encapsulate, encapsulate This is a good article.

OO is not going away; what is going away is the attention of a large number of fairly new programmers to the basics, as this article tries to emphasise.

Before OO, there was structured, and before that, modular prorgamming.

But the fundamental principles go to the very first assembly language macros and routines:
encapsulate, encapsulate, encapsulate

]]> By: Bill W. Davis http://nutrun.com/weblog/the-future-of-software-is-back-to-the-basics/comment-page-1/#comment-167 Bill W. Davis Tue, 12 Sep 2006 20:31:45 +0000 http://new-site.nutrun.com/?p=50#comment-167 Another concept to remember is that a component should be completely self contained and deployable on it's own. That doesn't mean you can't deploy it along with other components/application, but that you could if you wanted to. A component should not depend on anything but itself as far as deploying it is concerned. Any other "things" that it needs to do it's job should also be components and "talked" to thru interfaces. Another concept to remember is that a component should be completely self contained and deployable on it’s own. That doesn’t mean you can’t deploy it along with other components/application, but that you could if you wanted to. A component should not depend on anything but itself as far as deploying it is concerned. Any other “things” that it needs to do it’s job should also be components and “talked” to thru interfaces.

]]> By: Jeff http://nutrun.com/weblog/the-future-of-software-is-back-to-the-basics/comment-page-1/#comment-165 Jeff Mon, 11 Sep 2006 13:43:03 +0000 http://new-site.nutrun.com/?p=50#comment-165 there was an interesting thread on the exposure of methods/classes/interfaces in the Yahoo XP group a few months back, http://tech.groups.yahoo.com/group/extremeprogramming/message/120709. It was a longish running discussion about the benefits of exposing a restricted API that makes it easier to understand the intention of the designer in making the code versus the benefits of exposing more of the code to allow people to do things that may not have been envisioned by the original author(s). One of the interesting ideas I took from it was you could use namespaces/packaging to seperate narrow easy to understand APIs while exposing a larger API, which may be of interest to users of the code for ideas other than those originally envisioned by the author. there was an interesting thread on the exposure of methods/classes/interfaces in the Yahoo XP group a few months back, http://tech.groups.yahoo.com/group/extremeprogramming/message/120709.

It was a longish running discussion about the benefits of exposing a restricted API that makes it easier to understand the intention of the designer in making the code versus the benefits of exposing more of the code to allow people to do things that may not have been envisioned by the original author(s).

One of the interesting ideas I took from it was you could use namespaces/packaging to seperate narrow easy to understand APIs while exposing a larger API, which may be of interest to users of the code for ideas other than those originally envisioned by the author.

]]> By: Vishal Singh http://nutrun.com/weblog/the-future-of-software-is-back-to-the-basics/comment-page-1/#comment-166 Vishal Singh Mon, 11 Sep 2006 11:01:42 +0000 http://new-site.nutrun.com/?p=50#comment-166 One of the reasons why OOP is disappearing is becuase of lot of frameworks which may not really be OO and also perhaps the reason for non maintainable code.. One of the reasons why OOP is disappearing is becuase of lot of frameworks which may not really be OO and also perhaps the reason for non maintainable code..

]]>