Re: [OT] Business Layer Ideas
My high school had mostly reformed teachers. One once said, with
pride, that there had been no one in the trunk of his car for quite a
while.
On 6/1/05, Laurie Harper [EMAIL PROTECTED] wrote:
(yes, my school actually had Fortran, COBOL and Pascal classes!)
Your *high school* had multiple courses on different programming
languages? My high school ('secondary school' actually, I'm originally
from England) had exactly one 'O'-level computer course and one
'A'-level course. There might bave been a pre--'O'-level required course
too...
Any which way, my first computer related course in school was so basic I
walked away and never looked back until I got to university and realised
that I was skipping too many physics classes to play around in the
computer labs :-)
I'm guessing (from other posts in this thread) you're a little older
than I am. That would make your high school pretty impressively
forard-looking...!
L.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
You can lead a horse to water but you cannot make it float on its back.
~Dakota Jack~
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On Jun 2, 2005, at 1:46 AM, Laurie Harper wrote: I'm guessing (from other posts in this thread) you're a little older than I am. That would make your high school pretty impressively forard-looking...! I attended the first computer class given at my high school in 1965. It was kind of a funny situation - one other student and I taught the teacher, who then taught the rest of the class. The two of us had been messing about with computers for two years at that point, and knew a LOT more than the teacher. The course was taught from an obscure little book which illustrated all of its concepts in an assembler code for a non-existent machine. To facilitate the class, I wrote an emulator (in FORTRAN) for the assembler language which was used for several years after I graduated. It was a fun time to be into computers - when most people still didn't know what a computer was. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On Thu, June 2, 2005 1:29 am, Laurie Harper said: I have to admit that refactoring on butcher paper was a bitch though! I would think refactoring on on butcher paper would be very easy... just need a good pair of scissors and some Scotch tape. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On Thu, June 2, 2005 2:23 am, Dakota Jack said: My high school had mostly reformed teachers. One once said, with pride, that there had been no one in the trunk of his car for quite a while. Funny... the teachers in my school would say that with a damn, I miss the good'ole days look on their face. On 6/1/05, Laurie Harper [EMAIL PROTECTED] wrote: I'm guessing (from other posts in this thread) you're a little older than I am. That would make your high school pretty impressively forard-looking...! What's more amazing is that my high school was really pretty lousy overall. I remember when the school DISTRICT started their computer program... they picked six of us that were doing well and asked if we wanted to take some computer classes. Four of us said sure, why not, even though we didn't know what a computer was! I remember it well... it was 4th grade... our first assignment was to write a program to calculate the area of a triangle... a couple of questions came to mind... what is a triangle (ok, I got that one)... what is it's area... how does one calculate it... how does one write a program? Ah, fun days! I also remember that by the end of the class, I was the only one left (it was, after all, completely optional). So, it's even *more* surprising that the district pushed ahead with *any* kind of computer classes... 75% attrition doesn't sound like too big a success to me! Then again, as I discovered later, the teacher didn't have any more of a clue than we students did, except he knew how to do the underlying math problem. The computer part? I probably taught HIM! :) I doubt I'm that much older than you by the way, but I have two kids, so it might sound like I am :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Frank W. Zammetti wrote: On Thu, June 2, 2005 1:29 am, Laurie Harper said: I have to admit that refactoring on butcher paper was a bitch though! I would think refactoring on on butcher paper would be very easy... just need a good pair of scissors and some Scotch tape. Yeah, but I was only allowed to use scissors made of plastic... ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Laurie Harper wrote: Frank W. Zammetti wrote: On Thu, June 2, 2005 1:29 am, Laurie Harper said: I have to admit that refactoring on butcher paper was a bitch though! I would think refactoring on on butcher paper would be very easy... just need a good pair of scissors and some Scotch tape. Yeah, but I was only allowed to use scissors made of plastic... ;-) I would have KILLED for scissors! Which, erm, might be why I didn't get 'em. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Ok, ok, you win :) LOL -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, June 2, 2005 2:32 pm, Laurie Harper said: Frank W. Zammetti wrote: On Thu, June 2, 2005 1:29 am, Laurie Harper said: I have to admit that refactoring on butcher paper was a bitch though! I would think refactoring on on butcher paper would be very easy... just need a good pair of scissors and some Scotch tape. Yeah, but I was only allowed to use scissors made of plastic... ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Business Layer Ideas
-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
======
Hi, Peter,
I am not sure what you are saying here. I had trouble
following you.
The Strategy Pattern is roughly the following:
public class DefaultStrategyInterface implements StrategyInterface {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doWork() {
// Do business logic
int value = hleper.calculateSomething(params);
// Do more business logic
}
}
The Template Method Pattern used in Struts which necessitates the use
of the Chain of Responsibility Pattern, cf.
http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html, is
roughly the following:
public abstract class AbstractMethodInterface implements
MethodInterface {
public void doWork() {
// Do some business logic
int value = calculateSomething(params);
// Do more business logic
}
protected abstract int calculateSomething(params);
}
So, in a real sense, the Strategy Pattern advocates, in comparison to
the Template Method Pattern, composition over inheritance allowing for
ease of testing and a host of other good results.
Struts is based on the Template Method Pattern which Sigglelow rightly
sees is rescued by the Chain of Responsibility Pattern. This is the
context in which I was addressing the Strategy Pattern. Can you give
a little demo of how CoR metamorphasis's into this? I find your not
interesting but cannot see what it means.
Thanks
Consider a GUI algorithm that displays rows from the database.
The typical problem is to work out the best column width for
rendering the screen.
interface IFormatDatabaseColumnWidth {
public int calcColumnWidth( Object[][] data, MetaData metaData[], int
columnNo );
}
// Slowest and most accurate algorithm iterates all rows in the result set
class AllRowsFDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm based on the first 100 rows
class First100FDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm that calculates the column width for every N rows
class StepwiseFDCW implements IFrameDatabaseColumnWidth { ... }
This is the classic strategy pattern, as I remember writing it in a Swing/JDBC
five years ago. (In fact Xenon-SQL is still out there somewhere, but it
is broken against JDK 1.3 and 24/7/365 the time to fix it! )
You can rewrite the above strategy with Chain of Responsibility
pedantically. If you have a very functional requirement for it.
class ChainFDCW implements IFrameDatabaseColumnWidth {
Catalog catalog;
String commandName;
// IoC container friendly
public void setCatalog( catalog ) { ... }
public void setCommandName( name ) { ... }
public int calcColumnWidth( Object[][] data, MetaData metaData[], int
columnNo )
{
Context context = new FDCWContext( data, metaData, columnNo );
Command command = catalog.getCommand( commandName );
command.execute( context );
if ( context.isCalculatedOk() )
return context.getColumnWidth();
else
throw new StrategyRuntimeException(
Failed to calculate column width );
}
}
Ok writing a CoR for calculating data width takes a bit of stretching
the imagination, but of course you can do it, which is the point.
On 5/31/05, Pilgrim, Peter [EMAIL PROTECTED] wrote:
-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
====
I should have added that Rod (Johnson) in the book cited pointedly
advocates extensive use of the Strategy Pattern, see pp.
421 ff. The
use of CoR in Struts 1.3 for the extensible
RequestProcessor is not a
feature but is a way of solving the problem created by
the original
use of the Template Method Pattern in that context. Had
the Strategy
Pattern been used in the first instance, everything would
have worked
better, in my opinion. In many ways, I think in the future the
Template Method Pattern may be seen as an Anti-Pattern.
Just to forestall flamethrowers, I want to emphasize that others
probably think differently and even the majority, i.e.
by definition
the members ipsa facto of the meritocracy, may think
differently.
But, Rod Johnson is no slouch on these matters. He
thinks the use of
Strategy Pattern is one of the reasons [Spring] is such
a flexible
and extensible framework.
Hello Jack
It can be shown that ``Chain of Responsibility'' pattern can be
metamorphed into the ``Strategy'' pattern. The first
proviso is that one
of your commnds becomes a catalogy factory or invoker of other
generic commands itself. The second proviso is you must pass all
your information back and
Re: [OT] Business Layer Ideas
Thanks, Peter,
This reply is in three parts: Oops, Ugh and GoF.
FIRST PART: Oops!
I am afraid there is a fatal flaw in your reasoning. Your example of
the Strategy Pattern is *not* the Strategy Pattern. It is merely two
differing implmentations of an interface. The Strategy Pattern is a
client based pattern. As the Gang of Four (GoF) in Design Patterns:
Elements of Reusable Object-Oriented Software said on the inside of
the cover:
Strategy (315) Define a family of algorithms encapsulate each
one, and make them
interchangeable. Strategy lets the algorithm vary independently
from clients that use
it.
So, your point about the Strategy Pattern, of course, does not work
and is a non-starter.
A Strategy Pattern most importantly introduces some Helper utility
interface for the various implementations of an algorithm. Thus, you
could have either
A.
interface IFormatDatabaseColumnWidth {
public void setHelper(Helper helper);
public void doWork();
}
or
B.
Inteface IFormatDatabaseColumnWidth {
public void doWork();
}
But the implementations would have to be something like:
public class IFormatDatabaseColumnWidthImpl {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doWork() {
// Do business logic
int value = helper.calcColumnWidth(data,metaData[]),columnNo);
// Do more business logic
}
}
Thus, there would be a Helper interface:
interface Helper {
int calcColumnWidth(Object [][] data, MetaData metaData[]) int columnNo);
}
The differing calculations, then, would go into the Helper interface
implementations and not into the IFormatDatabaseColumnWidth interface
implementations. So, you might have
public class AllRowsFDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Slowest and most accurate algorithm iterates all rows in
the result set
}
}
and
public class First100FDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Algorithm based on the first 100 rows
}
}
and
public class class StepwiseFDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Algorithm that calculates the column width for every N rows
}
}
Please note that the pattern essentially uses polymorphism and late
binding not through implementations of an interface but through a
composite pattern.
Thus, when inversion of control (IoC) is used with the Strategy
Pattern, whether you are doing Dependency Injection (DI) or Dependency
Lookup (DL), the Helper is what is the subject of the lookup or
injection. (IoC, including DL, cannot be identified as DI merely.)
Your explanation of the Strategy Pattern leaves out what is essential
to the pattern. Consequently, your explanation is merely how Chain of
Responsibiltiy (CoR) can be used instead of differing implementations
of an interface. See below for a short note on your CoR example.
On 6/1/05, Pilgrim, Peter [EMAIL PROTECTED] wrote:
Consider a GUI algorithm that displays rows from the database.
The typical problem is to work out the best column width for
rendering the screen.
interface IFormatDatabaseColumnWidth {
public int calcColumnWidth( Object[][] data, MetaData metaData[], int
columnNo );
}
// Slowest and most accurate algorithm iterates all rows in the result set
class AllRowsFDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm based on the first 100 rows
class First100FDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm that calculates the column width for every N rows
class StepwiseFDCW implements IFrameDatabaseColumnWidth { ... }
This is the classic strategy pattern, as I remember writing it in a Swing/JDBC
five years ago. (In fact Xenon-SQL is still out there somewhere, but it
is broken against JDK 1.3 and 24/7/365 the time to fix it! )
SECOND PART: Ugh!
In my opinion, by the way, as an aside, using the CoR to replace mere
implementations of an interface would be rather *nuts*. This would
merely obfuscate and provide no benefit at all. This is what our
fellow traveler Frank Zammettie finds inherently suspicious about the
*OOP nuts*. This is, I am afraid, similar to some of the rather *knee
jerk* uses of CoR floating around. How does that old saw go? A boy
with a new hammer sees the whole world as a nail?
THIRD PART: GoF
The GoF used as their signal example a Composition class which
traversed and repaired (traverse(), repair()) and, much like your
algorithms with result sets, employed a field utility class Compositor
with the method compose() to implement various linebreaking strategies
(SimpleCompositor, TeXCompositor, and ArrayCompositor).
According to the GoF, who defined these things, the Strategy Pattern
must contain:
A Context interface holding a
Re: [OT] Business Layer Ideas
On Wed, June 1, 2005 9:47 am, Dakota Jack said: This is what our fellow traveler Frank Zammettie finds inherently suspicious about the *OOP nuts*. Woah, leave me out of this. I've purposely stayed away from this thread all this time, now I have to get in... I don't want anyone thinking I'm anti-OOP or anything remotely like that. I am very much an OOP proponent. While I almost certainly have used the term OOP nuts at some point because I think some people could probably be described that way, that really sounds a lot more harsh than my opinion actually is, so let me clarify... What I have said is that I have seen many instances where people take the OOP exercise so far in trying to get a perfect architectural structure in place that they wind up writing code that is actually harder to understand than it otherwise could be. There is great benefit to writing code that is composed of smaller, largely interchangeable pieces rather than large monolithic pieces. We all know this. However, I have seen this taken so far that it takes forever to grasp how all the pieces fit together to form the larger whole, and this is just as bad as writing one larger whole would have been. Related to this, patterns are a wonderful invention, but I see day in and day out people trying to find a pattern for every single situation. People seem to think that they have to solve every problem by finding a suitable pattern. The problem is, everyone seems to be so pattern-gung-ho nowadays that they simply want to apply a pattern and if it actually makes things more complex, too bad. If it doesn't really fit the problem but does happen to solve it, that's fine too. A pattern mismatch, or a pattern where none was truly needed, is just as bad as no pattern at all in my experience. Simplicity is a beautiful thing. That is always my underlying design goal for two reasons... One, in a corporate environment as I work in, you never know when someone else is going to have to come along and maintain your code. You aren't doing them any favors by writing code that, while architecturally sound, is more complex to grasp. If after three months they say wow, this guy architected this code perfectly!, that's great, but if those three months are spent not being especially productive while they try and understand what you built, then the code wasn't well-written in the end. Two, when you jump around between many different projects, you tend to forget your own work quickly. I sometimes look at code I wrote just last year and go I don't remember how or why I did this. Fortunately I comment the hell out of everything I do, but more importantly I try to code in straight-forward ways. Sometimes that means *NOT* creating that helper class to encapsulate 10 lines of code, even though that might architecturally be better and fit some pattern, but instead just inline it (assuming I don't expect it to be shared of course). In a nuthshell, my point is absolutely *USE* OOP and patterns, and other related techniques, think in those ways all the time, but don't over-engineer things!! Don't make design decisions because you CAN do something, make them because it is the RIGHT thing to do. And don't over-complicate things for the sake of achieving some theoretical design utopia. Make your code easy to understand, even if sometimes at the cost of design trade-offs. Naturally there is a balance to be struck... architecture *IS* after all important! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Sorry, Frank. I did not mean to misrepresent you in any way but merely to use a jocular reference out of good nature. I know you are into OOP. On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 9:47 am, Dakota Jack said: This is what our fellow traveler Frank Zammettie finds inherently suspicious about the *OOP nuts*. Woah, leave me out of this. I've purposely stayed away from this thread all this time, now I have to get in... I don't want anyone thinking I'm anti-OOP or anything remotely like that. I am very much an OOP proponent. While I almost certainly have used the term OOP nuts at some point because I think some people could probably be described that way, that really sounds a lot more harsh than my opinion actually is, so let me clarify... What I have said is that I have seen many instances where people take the OOP exercise so far in trying to get a perfect architectural structure in place that they wind up writing code that is actually harder to understand than it otherwise could be. There is great benefit to writing code that is composed of smaller, largely interchangeable pieces rather than large monolithic pieces. We all know this. However, I have seen this taken so far that it takes forever to grasp how all the pieces fit together to form the larger whole, and this is just as bad as writing one larger whole would have been. Related to this, patterns are a wonderful invention, but I see day in and day out people trying to find a pattern for every single situation. People seem to think that they have to solve every problem by finding a suitable pattern. The problem is, everyone seems to be so pattern-gung-ho nowadays that they simply want to apply a pattern and if it actually makes things more complex, too bad. If it doesn't really fit the problem but does happen to solve it, that's fine too. A pattern mismatch, or a pattern where none was truly needed, is just as bad as no pattern at all in my experience. Simplicity is a beautiful thing. That is always my underlying design goal for two reasons... One, in a corporate environment as I work in, you never know when someone else is going to have to come along and maintain your code. You aren't doing them any favors by writing code that, while architecturally sound, is more complex to grasp. If after three months they say wow, this guy architected this code perfectly!, that's great, but if those three months are spent not being especially productive while they try and understand what you built, then the code wasn't well-written in the end. Two, when you jump around between many different projects, you tend to forget your own work quickly. I sometimes look at code I wrote just last year and go I don't remember how or why I did this. Fortunately I comment the hell out of everything I do, but more importantly I try to code in straight-forward ways. Sometimes that means *NOT* creating that helper class to encapsulate 10 lines of code, even though that might architecturally be better and fit some pattern, but instead just inline it (assuming I don't expect it to be shared of course). In a nuthshell, my point is absolutely *USE* OOP and patterns, and other related techniques, think in those ways all the time, but don't over-engineer things!! Don't make design decisions because you CAN do something, make them because it is the RIGHT thing to do. And don't over-complicate things for the sake of achieving some theoretical design utopia. Make your code easy to understand, even if sometimes at the cost of design trade-offs. Naturally there is a balance to be struck... architecture *IS* after all important! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Not a problem. Just didn't want anyone else to get the wrong impression. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, June 1, 2005 10:35 am, Dakota Jack said: Sorry, Frank. I did not mean to misrepresent you in any way but merely to use a jocular reference out of good nature. I know you are into OOP. On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 9:47 am, Dakota Jack said: This is what our fellow traveler Frank Zammettie finds inherently suspicious about the *OOP nuts*. Woah, leave me out of this. I've purposely stayed away from this thread all this time, now I have to get in... I don't want anyone thinking I'm anti-OOP or anything remotely like that. I am very much an OOP proponent. While I almost certainly have used the term OOP nuts at some point because I think some people could probably be described that way, that really sounds a lot more harsh than my opinion actually is, so let me clarify... What I have said is that I have seen many instances where people take the OOP exercise so far in trying to get a perfect architectural structure in place that they wind up writing code that is actually harder to understand than it otherwise could be. There is great benefit to writing code that is composed of smaller, largely interchangeable pieces rather than large monolithic pieces. We all know this. However, I have seen this taken so far that it takes forever to grasp how all the pieces fit together to form the larger whole, and this is just as bad as writing one larger whole would have been. Related to this, patterns are a wonderful invention, but I see day in and day out people trying to find a pattern for every single situation. People seem to think that they have to solve every problem by finding a suitable pattern. The problem is, everyone seems to be so pattern-gung-ho nowadays that they simply want to apply a pattern and if it actually makes things more complex, too bad. If it doesn't really fit the problem but does happen to solve it, that's fine too. A pattern mismatch, or a pattern where none was truly needed, is just as bad as no pattern at all in my experience. Simplicity is a beautiful thing. That is always my underlying design goal for two reasons... One, in a corporate environment as I work in, you never know when someone else is going to have to come along and maintain your code. You aren't doing them any favors by writing code that, while architecturally sound, is more complex to grasp. If after three months they say wow, this guy architected this code perfectly!, that's great, but if those three months are spent not being especially productive while they try and understand what you built, then the code wasn't well-written in the end. Two, when you jump around between many different projects, you tend to forget your own work quickly. I sometimes look at code I wrote just last year and go I don't remember how or why I did this. Fortunately I comment the hell out of everything I do, but more importantly I try to code in straight-forward ways. Sometimes that means *NOT* creating that helper class to encapsulate 10 lines of code, even though that might architecturally be better and fit some pattern, but instead just inline it (assuming I don't expect it to be shared of course). In a nuthshell, my point is absolutely *USE* OOP and patterns, and other related techniques, think in those ways all the time, but don't over-engineer things!! Don't make design decisions because you CAN do something, make them because it is the RIGHT thing to do. And don't over-complicate things for the sake of achieving some theoretical design utopia. Make your code easy to understand, even if sometimes at the cost of design trade-offs. Naturally there is a balance to be struck... architecture *IS* after all important! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Good stuff Frank. Your point is a good one and well made. I just spoke at a Java User Group here in Wisconsin on a similar issue, about how most people don't need to improve their Java programming skills, rather they need to improve their programming skills! I think that pattern use falls in the same area. There are folks that use patterns religiously, thinking that they're being good programmers. All the while not realising that they're reducing themselves down to the level of a coding monkey. Too much of the Java code that I see is not object-oriented, it's object-obsessed. Objects defined for any small silly thing. Wrappers upon wrappers, calls to super in multiple levels of inheritance. Arrgh. It's like trying to follow the plot of one of Frank Herbert's Dune novels. (Good for novels, bad for programs though!) Simon On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 9:47 am, Dakota Jack said: This is what our fellow traveler Frank Zammettie finds inherently suspicious about the *OOP nuts*. Woah, leave me out of this. I've purposely stayed away from this thread all this time, now I have to get in... I don't want anyone thinking I'm anti-OOP or anything remotely like that. I am very much an OOP proponent. While I almost certainly have used the term OOP nuts at some point because I think some people could probably be described that way, that really sounds a lot more harsh than my opinion actually is, so let me clarify... What I have said is that I have seen many instances where people take the OOP exercise so far in trying to get a perfect architectural structure in place that they wind up writing code that is actually harder to understand than it otherwise could be. There is great benefit to writing code that is composed of smaller, largely interchangeable pieces rather than large monolithic pieces. We all know this. However, I have seen this taken so far that it takes forever to grasp how all the pieces fit together to form the larger whole, and this is just as bad as writing one larger whole would have been. Related to this, patterns are a wonderful invention, but I see day in and day out people trying to find a pattern for every single situation. People seem to think that they have to solve every problem by finding a suitable pattern. The problem is, everyone seems to be so pattern-gung-ho nowadays that they simply want to apply a pattern and if it actually makes things more complex, too bad. If it doesn't really fit the problem but does happen to solve it, that's fine too. A pattern mismatch, or a pattern where none was truly needed, is just as bad as no pattern at all in my experience. Simplicity is a beautiful thing. That is always my underlying design goal for two reasons... One, in a corporate environment as I work in, you never know when someone else is going to have to come along and maintain your code. You aren't doing them any favors by writing code that, while architecturally sound, is more complex to grasp. If after three months they say wow, this guy architected this code perfectly!, that's great, but if those three months are spent not being especially productive while they try and understand what you built, then the code wasn't well-written in the end. Two, when you jump around between many different projects, you tend to forget your own work quickly. I sometimes look at code I wrote just last year and go I don't remember how or why I did this. Fortunately I comment the hell out of everything I do, but more importantly I try to code in straight-forward ways. Sometimes that means *NOT* creating that helper class to encapsulate 10 lines of code, even though that might architecturally be better and fit some pattern, but instead just inline it (assuming I don't expect it to be shared of course). In a nuthshell, my point is absolutely *USE* OOP and patterns, and other related techniques, think in those ways all the time, but don't over-engineer things!! Don't make design decisions because you CAN do something, make them because it is the RIGHT thing to do. And don't over-complicate things for the sake of achieving some theoretical design utopia. Make your code easy to understand, even if sometimes at the cost of design trade-offs. Naturally there is a balance to be struck... architecture *IS* after all important! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Business Layer Ideas
-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
====
Strategy (315) Define a family of algorithms encapsulate each
one, and make them
interchangeable. Strategy lets the algorithm vary independently
from clients that use
it.
This is exactly I always thought it was too.
So, your point about the Strategy Pattern, of course, does not work
and is a non-starter.
Yes I missed the ``StrategyContext'' the actual POJO or entity that
encapsulates the ``Strategy'' and de-couples from the POJO.
Because of this decoupling you can thus change the strategy and
therefore write a __crazy_frog__ implementation that calls chain
if you found a worthy cause for it.
A Strategy Pattern most importantly introduces some Helper utility
interface for the various implementations of an algorithm. Thus, you
could have either
A.
interface IFormatDatabaseColumnWidth {
public void setHelper(Helper helper);
public void doWork();
}
or
B.
Inteface IFormatDatabaseColumnWidth {
public void doWork();
}
But the implementations would have to be something like:
public class IFormatDatabaseColumnWidthImpl {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doWork() {
// Do business logic
int value = helper.calcColumnWidth(data,metaData[]),columnNo);
// Do more business logic
}
}
Thus, there would be a Helper interface:
interface Helper {
int calcColumnWidth(Object [][] data, MetaData
metaData[]) int columnNo);
}
The differing calculations, then, would go into the Helper interface
implementations and not into the IFormatDatabaseColumnWidth interface
implementations. So, you might have
public class AllRowsFDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Slowest and most accurate algorithm iterates all rows in
the result set
}
}
and
public class First100FDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Algorithm based on the first 100 rows
}
}
and
public class class StepwiseFDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Algorithm that calculates the column width for every N rows
}
}
Please note that the pattern essentially uses polymorphism and late
binding not through implementations of an interface but through a
composite pattern.
Thus, when inversion of control (IoC) is used with the Strategy
Pattern, whether you are doing Dependency Injection (DI) or Dependency
Lookup (DL), the Helper is what is the subject of the lookup or
injection. (IoC, including DL, cannot be identified as DI merely.)
Your explanation of the Strategy Pattern leaves out what is essential
to the pattern. Consequently, your explanation is merely how Chain of
Responsibiltiy (CoR) can be used instead of differing implementations
of an interface. See below for a short note on your CoR example.
Dependency injection can be used anywhere where there is a public constructor
or JavaBean setters. If you are using strategy pattern that you are right
you can inject the ``strategy'' into the ``StrategyContext'' at run-time.
And in this case if you want to use CoR inside the ``StrategyContext''
of course you need to write an adaptor for your algorithm interface
to call the first command of the Chain.
On 6/1/05, Pilgrim, Peter [EMAIL PROTECTED] wrote:
Consider a GUI algorithm that displays rows from the database.
The typical problem is to work out the best column width for
rendering the screen.
interface IFormatDatabaseColumnWidth {
public int calcColumnWidth( Object[][] data,
MetaData metaData[], int
columnNo );
}
// Slowest and most accurate algorithm iterates all rows in
the result set
class AllRowsFDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm based on the first 100 rows
class First100FDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm that calculates the column width for every N rows
class StepwiseFDCW implements IFrameDatabaseColumnWidth { ... }
This is the classic strategy pattern, as I remember writing
it in a Swing/JDBC
five years ago. (In fact Xenon-SQL is still out there
somewhere, but it
is broken against JDK 1.3 and 24/7/365 the time to fix it! )
SECOND PART: Ugh!
In my opinion, by the way, as an aside, using the CoR to replace mere
implementations of an interface would be rather *nuts*. This would
merely obfuscate and provide no benefit at all. This is what our
fellow traveler Frank Zammettie finds inherently suspicious about the
*OOP nuts*. This is, I am afraid, similar to some of the rather *knee
jerk* uses of CoR floating around. How does that
RE: [OT] Business Layer Ideas
-Original Message- From: Simon Chappell [mailto:[EMAIL PROTECTED] Sent: 01 June 2005 16:29 To: Struts Users Mailing List Subject: Re: [OT] Business Layer Ideas Good stuff Frank. Your point is a good one and well made. I just spoke at a Java User Group here in Wisconsin on a similar issue, about how most people don't need to improve their Java programming skills, rather they need to improve their programming skills! I think that pattern use falls in the same area. There are folks that use patterns religiously, thinking that they're being good programmers. All the while not realising that they're reducing themselves down to the level of a coding monkey. Patterns came from the recognition of common idioms, practices in the industry. Religously following and applying patterns could condemn you not to discovering future oversights and other intuitions. Too much of the Java code that I see is not object-oriented, it's object-obsessed. Objects defined for any small silly thing. Wrappers upon wrappers, calls to super in multiple levels of inheritance. Arrgh. It's like trying to follow the plot of one of Frank Herbert's Dune novels. (Good for novels, bad for programs though!) I wonder, if they will get over the dessert dunes onto lambda functions and tuples next? Simon Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 9:47 am, Dakota Jack said: This is what our fellow traveler Frank Zammettie finds inherently suspicious about the *OOP nuts*. Woah, leave me out of this. I've purposely stayed away from this thread all this time, now I have to get in... I don't want anyone thinking I'm anti-OOP or anything remotely like that. I am very much an OOP proponent. While I almost certainly have used the term OOP nuts at some point because I think some people could probably be described that way, that really sounds a lot more harsh than my opinion actually is, so let me clarify... What I have said is that I have seen many instances where people take the OOP exercise so far in trying to get a perfect architectural structure in place that they wind up writing code that is actually harder to understand than it otherwise could be. There is great benefit to writing code that is composed of smaller, largely interchangeable pieces rather than large monolithic pieces. We all know this. However, I have seen this taken so far that it takes forever to grasp how all the pieces fit together to form the larger whole, and this is just as bad as writing one larger whole would have been. Related to this, patterns are a wonderful invention, but I see day in and day out people trying to find a pattern for every single situation. People seem to think that they have to solve every problem by finding a suitable pattern. The problem is, everyone seems to be so pattern-gung-ho nowadays that they simply want to apply a pattern and if it actually makes things more complex, too bad. If it doesn't really fit the problem but does happen to solve it, that's fine too. A pattern mismatch, or a pattern where none was truly needed, is just as bad as no pattern at all in my experience. Simplicity is a beautiful thing. That is always my underlying design goal for two reasons... One, in a corporate environment as I work in, you never know when someone else is going to have to come along and maintain your code. You aren't doing them any favors by writing code that, while architecturally sound, is more complex to grasp. If after three months they say wow, this guy architected this code perfectly!, that's great, but if those three months are spent not being especially productive while they try and understand what you built, then the code wasn't well-written in the end. Two, when you jump around between many different projects, you tend to forget your own work quickly. I sometimes look at code I wrote just last year and go I don't remember how or why I did this. Fortunately I comment the hell out of everything I do, but more importantly I try to code in straight-forward ways. Sometimes that means *NOT* creating that helper class to encapsulate 10 lines of code, even though that might architecturally be better and fit some pattern, but instead just inline it (assuming I don't expect it to be shared of course). In a nuthshell, my point is absolutely *USE* OOP and patterns, and other related techniques, think in those ways all the time, but don't over-engineer things!! Don't make design decisions because you CAN do something, make them because it is the RIGHT thing to do. And don't over-complicate things for the sake of achieving some theoretical
Re: [OT] Business Layer Ideas
On Wed, 2005-06-01 at 10:31 -0400, Frank W. Zammetti wrote: ... Simplicity is a beautiful thing. That is always my underlying design goal for two reasons... Now this is really a perfect statement on architectures! Thanx Frank Leon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Patterns came from the recognition of common idioms, practices in the industry. Religously following and applying patterns could condemn you not to discovering future oversights and other intuitions. Back when I was a young programmer we used to have to think. THINK! Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart stencil. We had it rough I tell you, but I think that we wrote better code back in those days. And those of us that came through them, still have a tendency to do so. When was the last time you had to worry about memory efficiency? I have 1.5 Gb of RAM on my machine at home. Goodness, how do you use all of that up? (Photoshop is the only thing that comes close to using that much memory) My first computer had 1K, yes, that's 1024 bytes. To get anything worthwhile to work in that, you had to think hard and squeeze harder. It made us think. Many programmers today don't even know that computers used to be that small. I wonder, if they will get over the dessert dunes onto lambda functions and tuples next? We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Real, worthwhile, programming is hard, so if your going to do it, study for it, and learn (LEARN I say) to do it well. Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. Yes. Yes. Yes. Thank you Craig. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
I have these 2 phrases posted in my office as a reminder... Simplicity is the ultimate sophistication - Leonardo da Vinci The ability to simplify means to eliminate the unnecessary so that the necessary may speak - Hans Hofmann - Glenn Leon Rosenberg [EMAIL PROTECTED] 01/06/2005 11:42 AM Please respond to Struts Users Mailing List user@struts.apache.org To Struts Users Mailing List user@struts.apache.org cc Subject Re: [OT] Business Layer Ideas On Wed, 2005-06-01 at 10:31 -0400, Frank W. Zammetti wrote: ... Simplicity is a beautiful thing. That is always my underlying design goal for two reasons... Now this is really a perfect statement on architectures! Thanx Frank Leon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On Wed, June 1, 2005 12:15 pm, Simon Chappell said: Back when I was a young programmer we used to have to think. THINK! Hey, I'm the resident bemoaner of how rough we used to have it! How dare you take my job?!? :) LOL Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart stencil. Stencils?!? I laugh at your stencils! It was only freehand drawings for us, and that was when we took the time to actually PLAN anything! We had it rough I tell you, but I think that we wrote better code back in those days. And those of us that came through them, still have a tendency to do so. I have said on numerous occassions that programmers that have never touched Assembly are, with few exceptions, not as good. And although the overall tone of my reply here is a joking one, this is a point I am serious about. I have actually rejected resumes because they had no Assembly experience. I'm not saying you have to be able to hand-code a 3D game engine, but at least have had some exposure. I spent a number of years doing absolutely nothing BUT Assembly, and while I honestly haven't done anything beyond some very simple subfunctions in the past 5-7 years or so, I wouldn't trade that experience for all the algorithm classes and patterns knowledge in the world. There is NOTHING like understanding, at least at a conceptual level, what's going on down there in the lower layers of your machine. Assembly gives you this. Like I said, there are exceptions to this rule, but I haven't met too many. My first computer had 1K, yes, that's 1024 bytes. Timex Sinclair 1000 by any chance? I loved that little thing! So much so that I spend $200 on one off eBay last year (three of them actually, with a lot of extras). The best thing about it was that if you could manage anything decent on it you were learning... I crammed the entire catalog of movie times for a week for Long Island in it... invented my own rudimentary compression scheme (although I had no clue what compression or algorithms were back then... never even heard the words... I was like 9 or so!). And I didn't have the 16K expansion module because my dad tried to solder it on because we could never get a good contact, but he fried it in the process, so I was stuck with the 1K (actually, now that I think about it, it might have been 2K. I'm not sure). We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Real, worthwhile, programming is hard, so if your going to do it, study for it, and learn (LEARN I say) to do it well. I}hate}}}LISP. LISP... ugh. I can't stand any language that contains more parenthesis per 1,000 lines of code than ACTUAL CODE! :) Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. Yes. Yes. Yes. Thank you Craig. I agree... There are probably architecural decisions in Struts I could complain about, but I think it would quickly become nothing but nitpicking. Craig did a rather good job IMHO of straddling the line between a good architecure that is flexible and extensible without making it too complex. Good job indeed, thank you! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Come on guys... it is much tougher today than back when you and I were young! Programming is programming: things haven't changed that much. ;) I started out doing Assembler. Then moved on to Cobol and CICS. I remember the excitement when Cobol II came out wow 4 new instructions... learnt it in 15 seconds flat. Followed the fashion to Client/Server applications in VB C++ Moved on to Internet/Intranet/Extranet fashions... with Microsoft Technologies. All of the tiers, architectures infrastructures. Now I'm on the Java side of things. Think of all of the stuff happening today... APIs, Frameworks, Patterns, etc. And the responsibility of being competent today is a never ending task. I am smiling... knowing that I could probably go back to CICS/Cobol and be productive in half a day. Walk out of the office and forget about my job... which is something I cannot do anymore. But I am having a blast... and wouldn't change anything ah perhaps somethings that this is for another time! My little trip down memory lane. :) - Glenn Frank W. Zammetti [EMAIL PROTECTED] 01/06/2005 12:39 PM Please respond to Struts Users Mailing List user@struts.apache.org To Simon Chappell [EMAIL PROTECTED] cc Struts Users Mailing List user@struts.apache.org Subject Re: [OT] Business Layer Ideas On Wed, June 1, 2005 12:15 pm, Simon Chappell said: Back when I was a young programmer we used to have to think. THINK! Hey, I'm the resident bemoaner of how rough we used to have it! How dare you take my job?!? :) LOL Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart stencil. Stencils?!? I laugh at your stencils! It was only freehand drawings for us, and that was when we took the time to actually PLAN anything! We had it rough I tell you, but I think that we wrote better code back in those days. And those of us that came through them, still have a tendency to do so. I have said on numerous occassions that programmers that have never touched Assembly are, with few exceptions, not as good. And although the overall tone of my reply here is a joking one, this is a point I am serious about. I have actually rejected resumes because they had no Assembly experience. I'm not saying you have to be able to hand-code a 3D game engine, but at least have had some exposure. I spent a number of years doing absolutely nothing BUT Assembly, and while I honestly haven't done anything beyond some very simple subfunctions in the past 5-7 years or so, I wouldn't trade that experience for all the algorithm classes and patterns knowledge in the world. There is NOTHING like understanding, at least at a conceptual level, what's going on down there in the lower layers of your machine. Assembly gives you this. Like I said, there are exceptions to this rule, but I haven't met too many. My first computer had 1K, yes, that's 1024 bytes. Timex Sinclair 1000 by any chance? I loved that little thing! So much so that I spend $200 on one off eBay last year (three of them actually, with a lot of extras). The best thing about it was that if you could manage anything decent on it you were learning... I crammed the entire catalog of movie times for a week for Long Island in it... invented my own rudimentary compression scheme (although I had no clue what compression or algorithms were back then... never even heard the words... I was like 9 or so!). And I didn't have the 16K expansion module because my dad tried to solder it on because we could never get a good contact, but he fried it in the process, so I was stuck with the 1K (actually, now that I think about it, it might have been 2K. I'm not sure). We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Real, worthwhile, programming is hard, so if your going to do it, study for it, and learn (LEARN I say) to do it well. I}hate}}}LISP. LISP... ugh. I can't stand any language that contains more parenthesis per 1,000 lines of code than ACTUAL CODE! :) Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. Yes. Yes. Yes. Thank you Craig. I agree... There are probably architecural decisions in Struts I could complain about, but I think it would quickly become nothing but nitpicking. Craig did a rather good job IMHO of straddling the line between a good architecure that is flexible and extensible without making it too complex. Good job indeed, thank you! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Frank W. Zammetti wrote: Related to this, patterns are a wonderful invention, but I see day in and day out people trying to find a pattern for every single situation. People seem to think that they have to solve every problem by finding a suitable pattern. The problem is, everyone seems to be so pattern-gung-ho nowadays that they simply want to apply a pattern and if it actually makes things more complex, too bad. If it doesn't really fit the problem but does happen to solve it, that's fine too. A pattern mismatch, or a pattern where none was truly needed, is just as bad as no pattern at all in my experience. This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about patterns. I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write. -- Paul Graham Dave No, really, he's not a cult Newton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Dave- could you give us an example of over-using a weak abstraction ? Martin- - Original Message - From: Dave Newton [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Wednesday, June 01, 2005 2:19 PM Subject: Re: [OT] Business Layer Ideas Frank W. Zammetti wrote: Related to this, patterns are a wonderful invention, but I see day in and day out people trying to find a pattern for every single situation. People seem to think that they have to solve every problem by finding a suitable pattern. The problem is, everyone seems to be so pattern-gung-ho nowadays that they simply want to apply a pattern and if it actually makes things more complex, too bad. If it doesn't really fit the problem but does happen to solve it, that's fine too. A pattern mismatch, or a pattern where none was truly needed, is just as bad as no pattern at all in my experience. This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about patterns. I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write. -- Paul Graham Dave No, really, he's not a cult Newton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Simon Chappell wrote: Back when I was a young programmer we used to have to think. THINK! Ah, a man after my own heart. In those days, if we wanted the computer to do _anything_, we generally had to write it ourselves, and nobody had ever done it before, so we couldn't even cheat. And like you say, we were not blessed with an abundance of memory (although I had a luxurious 4K, giving me 3K of bloat over you ;) When was the last time you had to worry about memory efficiency? I actually still get to worry sometimes, as I work from time to time with small embedded systems, but even those are pretty extreme compared to stuff I was programming on even ten years ago. The game machine I programmed on rarely had more than 16K, into which we would cram (limited) AI, sound, voice, and graphics. We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Mmmm, Creamy Lisp Goodness. One major problem lies with how programmers are educated today. A lot of schools teach a language or a design philosophy but rarely are in-depth enough to actually breed the abstract skills necessary for the programmer to become useful. It's a shame, really. I went to college in 1986 (and had been programming since 1978) and within a few years of my graduation in 1990 the curriculum at most schools had been watered down to the point of near uselessness. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Frank W. Zammetti wrote: And I didn't have the 16K expansion module because my dad tried to solder it on because we could never get a good contact No no, you wanted it a little loose, for paging :D I}hate}}}LISP. LISP... ugh. I can't stand any language that contains more parenthesis per 1,000 lines of code than ACTUAL CODE! :) Sounds like why I hate Java; I dislike having more boilerplate than actual problem-solving material. I agree... There are probably architecural decisions in Struts I could complain about, but I think it would quickly become nothing but nitpicking. Craig did a rather good job IMHO of straddling the line between a good architecure that is flexible and extensible without making it too complex. Good job indeed, thank you! +1 Pretty lean and mean, all things considered. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On Jun 1, 2005, at 12:39 PM, Frank W. Zammetti wrote: Timex Sinclair 1000 by any chance? Agh, you youngsters... My first program ran on a Burroughs 220 that was a vacuum tube based computer! But seriously, I agree fully that having learned on machines that had very limited memory, and having spent a lot of time writing assembler made me a much better programmer. But what I think contributed the most was that all of my early programming was done on mainframes where one compile and run (actually compile, link and run; remember link editors and overlay structures?) per day was considered pretty good turnaround. If you were going to get your programming assignments done on time, you learned to debug code by reading it and thinking until you found the errors. I still make very little use of debuggers to this day, and find the younger programmers completely mystified as to how I ever get code to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On Wed, June 1, 2005 2:55 pm, Tom Dimock said: I still make very little use of debuggers to this day, and find the younger programmers completely mystified as to how I ever get code to work. I frequently get the same reaction... I rarely use a debugger either, yet I seem to have very little trouble tracking down problems. In fact, I dare say I am a more efficient bug hunter than many people I know who DO use them. I don't bemoan anyone using a debugger by the way, or any other advanced tool. Maybe at one point I would have, but no longer. I realize that each person works at peak efficiency in their own way, with their own preferred tools. That's one of the reasons I am a big believer in not forcing any given IDE on anyone and in fact I'll buy my guys virtually any tool they tell me they need (as long as they are convincing!)... especially in the Java world where it's relatively simple to make applications agnostic about development environments (except for those damned Websphere-specific files!), let each work in the way they are most comfortable and will be most efficient. As long as it all boils down to an Ant script and each can reproduce a build in their environment, I'm cool with it. For me, it's UltraEdit and a command line, for some it's WSAD or Eclipse or IntelliJ or whatever else. Here's a cool story (which illustrates just how pitiful my life is, but I digress)... back in high school one day a fellow student came to me... he was taking a Pascal class (yes, my school actually had Fortran, COBOL and Pascal classes!)... he was having endless trouble getting a program of his to work. He showed me the listing, and it took me about 10 minutes of looking at it, just reading the code, but I finally pointed out the problem. I don't remember exactly what the problem was, but it wasn't a simple syntactic error, it was a logic/flow issue. The thing is, I had never to that point even SEEN Pascal code! But, I knew enough about the structure of programming languages in general and about program construction in general and about logic in general that I could figure it out. sarcasmNow bow before me!/sarcasm Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Frank W. Zammetti wrote: On Wed, June 1, 2005 2:55 pm, Tom Dimock said: I still make very little use of debuggers to this day, and find the younger programmers completely mystified as to how I ever get code to work. I frequently get the same reaction... I rarely use a debugger either, yet I seem to have very little trouble tracking down problems. In fact, I dare say I am a more efficient bug hunter than many people I know who DO use them. Debuggers seem useful for only a small range of bug types. When you need one, they're awesome, but generally a good reading and understanding is more than enough. Or some simple logging :) (Although I have to admit, when game programming or the Sega GameGear I would have had to pull off my own hea if I hadn't had the ICE.) (except for those damned Websphere-specific files!) Weblogic, too :( I'm still not sure why it needs .JSPF files; if anybody knows, tell me, because it's causing me a headache right now. The thing is, I had never to that point even SEEN Pascal code! I did the same thing with COBOL once. And immediately swore I'd never learn COBOL. *shudder* Of course, I did the same thing with Java, and just look at me now... :/ Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
There is always a cost As Leon pointed IDE button clickers are now called Software Engineers What happens when a requirement comes along which is not acomodated by clicking 2 buttons? The entire project comes to an immediate HALT..the child prodigy sheepishly walks into his bosses office and cries he cannot do it since the IDE does not accomodate this feature..it is time to call the 'dreaded consultant' The forgotten rule of Extensibility means that however you build your app you must always be able to take on any features and functionality that the client may desire Always best to Read/update and understand the caveats of the requirements doc carefully before pushing *any* limited scoped solution into production.. Those who remember rolling your own customised solution know this is a lost artform Martin- - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Wednesday, June 01, 2005 2:44 PM Subject: AW: [OT] Business Layer Ideas One major problem lies with how programmers are educated today. A lot of schools teach a language or a design philosophy but rarely are in-depth enough to actually breed the abstract skills necessary for the programmer to become useful. It's a shame, really. I went to college in 1986 (and had been programming since 1978) and within a few years of my graduation in 1990 the curriculum at most schools had been watered down to the point of near uselessness. Well, make a stop... You can't compare things programmed back in the Dark Ages with nowerdays programming. We make far more complicated programms in far less time and for lesser cost. You can critisize overusage of patterns, but under-usage of patterns is clearly at least as bad. Patterns make code understanding simplier, because everyone (should) know them, and simplicity is the goal as many of us stated before. You can't reinvent the wheel each time you write a piece of code, it's simply waste of your time and customers/companies money. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On Wed, June 1, 2005 3:42 pm, Dave Newton said: (Although I have to admit, when game programming or the Sega GameGear I would have had to pull off my own hea if I hadn't had the ICE.) That's a good point... I do PocketPC game development, and I'd hate to think about doing it without a good debugger at the ready. Especially for those gee, I just switched to release mode and now this stupid array bounds is being overflowed because the optimzation switches are a bit too aggressive by default problems. Ugh. (except for those damned Websphere-specific files!) Weblogic, too :( I suppose it's true of any app server, save Tomcat :) The ironic thing about the Websphere files is that I am now the only one around here that can understand and edit them by hand! I let RAD generate them to begin with, then hacked the hell out of them to trim them down to the basics that I could easily understand, now I don't need RAD any more. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Leon, I meant to ask, what does the AW prefix on messages signify? I've seen it plenty of times but never really thought to ask until now. Oh yeah... IDE button-clickers... I HATE THEE! I have no problem with a person that uses convenience tools so long as they can do without them. I have no problem with using a tool to generate getters and setters for a bean class, but if you can't do it by hand then you have no business coding. I actually know people that have no business coding, sorry as that is. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, June 1, 2005 3:43 pm, Martin Gainty said: There is always a cost As Leon pointed IDE button clickers are now called Software Engineers What happens when a requirement comes along which is not acomodated by clicking 2 buttons? The entire project comes to an immediate HALT..the child prodigy sheepishly walks into his bosses office and cries he cannot do it since the IDE does not accomodate this feature..it is time to call the 'dreaded consultant' The forgotten rule of Extensibility means that however you build your app you must always be able to take on any features and functionality that the client may desire Always best to Read/update and understand the caveats of the requirements doc carefully before pushing *any* limited scoped solution into production.. Those who remember rolling your own customised solution know this is a lost artform Martin- - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Wednesday, June 01, 2005 2:44 PM Subject: AW: [OT] Business Layer Ideas One major problem lies with how programmers are educated today. A lot of schools teach a language or a design philosophy but rarely are in-depth enough to actually breed the abstract skills necessary for the programmer to become useful. It's a shame, really. I went to college in 1986 (and had been programming since 1978) and within a few years of my graduation in 1990 the curriculum at most schools had been watered down to the point of near uselessness. Well, make a stop... You can't compare things programmed back in the Dark Ages with nowerdays programming. We make far more complicated programms in far less time and for lesser cost. You can critisize overusage of patterns, but under-usage of patterns is clearly at least as bad. Patterns make code understanding simplier, because everyone (should) know them, and simplicity is the goal as many of us stated before. You can't reinvent the wheel each time you write a piece of code, it's simply waste of your time and customers/companies money. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
AW = RE in german :-) It's standart by outlook... -Ursprüngliche Nachricht- Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 21:55 An: Martin Gainty Cc: Struts Users Mailing List Betreff: Re: [OT] Business Layer Ideas Leon, I meant to ask, what does the AW prefix on messages signify? I've seen it plenty of times but never really thought to ask until now. Oh yeah... IDE button-clickers... I HATE THEE! I have no problem with a person that uses convenience tools so long as they can do without them. I have no problem with using a tool to generate getters and setters for a bean class, but if you can't do it by hand then you have no business coding. I actually know people that have no business coding, sorry as that is. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, June 1, 2005 3:43 pm, Martin Gainty said: There is always a cost As Leon pointed IDE button clickers are now called Software Engineers What happens when a requirement comes along which is not acomodated by clicking 2 buttons? The entire project comes to an immediate HALT..the child prodigy sheepishly walks into his bosses office and cries he cannot do it since the IDE does not accomodate this feature..it is time to call the 'dreaded consultant' The forgotten rule of Extensibility means that however you build your app you must always be able to take on any features and functionality that the client may desire Always best to Read/update and understand the caveats of the requirements doc carefully before pushing *any* limited scoped solution into production.. Those who remember rolling your own customised solution know this is a lost artform Martin- - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Wednesday, June 01, 2005 2:44 PM Subject: AW: [OT] Business Layer Ideas One major problem lies with how programmers are educated today. A lot of schools teach a language or a design philosophy but rarely are in-depth enough to actually breed the abstract skills necessary for the programmer to become useful. It's a shame, really. I went to college in 1986 (and had been programming since 1978) and within a few years of my graduation in 1990 the curriculum at most schools had been watered down to the point of near uselessness. Well, make a stop... You can't compare things programmed back in the Dark Ages with nowerdays programming. We make far more complicated programms in far less time and for lesser cost. You can critisize overusage of patterns, but under-usage of patterns is clearly at least as bad. Patterns make code understanding simplier, because everyone (should) know them, and simplicity is the goal as many of us stated before. You can't reinvent the wheel each time you write a piece of code, it's simply waste of your time and customers/companies money. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
AW = RE in german :-) It's standart by outlook... -Ursprüngliche Nachricht- Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 21:55 An: Martin Gainty Cc: Struts Users Mailing List Betreff: Re: [OT] Business Layer Ideas Leon, I meant to ask, what does the AW prefix on messages signify? I've seen it plenty of times but never really thought to ask until now. Oh yeah... IDE button-clickers... I HATE THEE! I have no problem with a person that uses convenience tools so long as they can do without them. I have no problem with using a tool to generate getters and setters for a bean class, but if you can't do it by hand then you have no business coding. I actually know people that have no business coding, sorry as that is. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, June 1, 2005 3:43 pm, Martin Gainty said: There is always a cost As Leon pointed IDE button clickers are now called Software Engineers What happens when a requirement comes along which is not acomodated by clicking 2 buttons? The entire project comes to an immediate HALT..the child prodigy sheepishly walks into his bosses office and cries he cannot do it since the IDE does not accomodate this feature..it is time to call the 'dreaded consultant' The forgotten rule of Extensibility means that however you build your app you must always be able to take on any features and functionality that the client may desire Always best to Read/update and understand the caveats of the requirements doc carefully before pushing *any* limited scoped solution into production.. Those who remember rolling your own customised solution know this is a lost artform Martin- - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Wednesday, June 01, 2005 2:44 PM Subject: AW: [OT] Business Layer Ideas One major problem lies with how programmers are educated today. A lot of schools teach a language or a design philosophy but rarely are in-depth enough to actually breed the abstract skills necessary for the programmer to become useful. It's a shame, really. I went to college in 1986 (and had been programming since 1978) and within a few years of my graduation in 1990 the curriculum at most schools had been watered down to the point of near uselessness. Well, make a stop... You can't compare things programmed back in the Dark Ages with nowerdays programming. We make far more complicated programms in far less time and for lesser cost. You can critisize overusage of patterns, but under-usage of patterns is clearly at least as bad. Patterns make code understanding simplier, because everyone (should) know them, and simplicity is the goal as many of us stated before. You can't reinvent the wheel each time you write a piece of code, it's simply waste of your time and customers/companies money. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
-Ursprüngliche Nachricht- Von: Dave Newton [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 21:37 An: Struts Users Mailing List Betreff: Re: AW: [OT] Business Layer Ideas Leon Rosenberg wrote: We make far more complicated programms in far less time and for lesser cost. Complicated is a pretty loaded term... I don't see much complication in the majority of web apps. Big, sure. Complicated? Sometimes. The most complicated stuff I've worked on lately is rules engines, for which I used Jess, which looked suspiciously like a combination of Lisp and Prolog. Interaction between existing systems can get hairy fairly quickly as well. By complicated I mean following: Modern OSes, office suites or business software. Modern guis, with integrated media support, integrated audio/video broad- and unicasts, animations, sounds, and so on... Would you be able to code them with c? Forget it. What we have had was mostly alpha-numeric based terminals (remember borlands gdi?) with maybe 10-20 business functions. Now, a pissy web-portal has more functionallity then the whole supercalc suite. Nostalgic talking about old times is ok, but you shouldn't forget reality... And talking about complicated and simplicity... What is simplier to read, 10 classes a 20 lines java code, or 5000 lines of assembler code doing the same? Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
-Ursprüngliche Nachricht- Von: Dave Newton [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 21:37 An: Struts Users Mailing List Betreff: Re: AW: [OT] Business Layer Ideas Leon Rosenberg wrote: We make far more complicated programms in far less time and for lesser cost. Complicated is a pretty loaded term... I don't see much complication in the majority of web apps. Big, sure. Complicated? Sometimes. The most complicated stuff I've worked on lately is rules engines, for which I used Jess, which looked suspiciously like a combination of Lisp and Prolog. Interaction between existing systems can get hairy fairly quickly as well. By complicated I mean following: Modern OSes, office suites or business software. Modern guis, with integrated media support, integrated audio/video broad- and unicasts, animations, sounds, and so on... Would you be able to code them with c? Forget it. What we have had was mostly alpha-numeric based terminals (remember borlands gdi?) with maybe 10-20 business functions. Now, a pissy web-portal has more functionallity then the whole supercalc suite. Nostalgic talking about old times is ok, but you shouldn't forget reality... And talking about complicated and simplicity... What is simplier to read, 10 classes a 20 lines java code, or 5000 lines of assembler code doing the same? Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
When I was going to programming school we had to walk to school and back and it was uphill both ways. On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 12:15 pm, Simon Chappell said: Back when I was a young programmer we used to have to think. THINK! Hey, I'm the resident bemoaner of how rough we used to have it! How dare you take my job?!? :) LOL Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart stencil. Stencils?!? I laugh at your stencils! It was only freehand drawings for us, and that was when we took the time to actually PLAN anything! We had it rough I tell you, but I think that we wrote better code back in those days. And those of us that came through them, still have a tendency to do so. I have said on numerous occassions that programmers that have never touched Assembly are, with few exceptions, not as good. And although the overall tone of my reply here is a joking one, this is a point I am serious about. I have actually rejected resumes because they had no Assembly experience. I'm not saying you have to be able to hand-code a 3D game engine, but at least have had some exposure. I spent a number of years doing absolutely nothing BUT Assembly, and while I honestly haven't done anything beyond some very simple subfunctions in the past 5-7 years or so, I wouldn't trade that experience for all the algorithm classes and patterns knowledge in the world. There is NOTHING like understanding, at least at a conceptual level, what's going on down there in the lower layers of your machine. Assembly gives you this. Like I said, there are exceptions to this rule, but I haven't met too many. My first computer had 1K, yes, that's 1024 bytes. Timex Sinclair 1000 by any chance? I loved that little thing! So much so that I spend $200 on one off eBay last year (three of them actually, with a lot of extras). The best thing about it was that if you could manage anything decent on it you were learning... I crammed the entire catalog of movie times for a week for Long Island in it... invented my own rudimentary compression scheme (although I had no clue what compression or algorithms were back then... never even heard the words... I was like 9 or so!). And I didn't have the 16K expansion module because my dad tried to solder it on because we could never get a good contact, but he fried it in the process, so I was stuck with the 1K (actually, now that I think about it, it might have been 2K. I'm not sure). We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Real, worthwhile, programming is hard, so if your going to do it, study for it, and learn (LEARN I say) to do it well. I}hate}}}LISP. LISP... ugh. I can't stand any language that contains more parenthesis per 1,000 lines of code than ACTUAL CODE! :) Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. Yes. Yes. Yes. Thank you Craig. I agree... There are probably architecural decisions in Struts I could complain about, but I think it would quickly become nothing but nitpicking. Craig did a rather good job IMHO of straddling the line between a good architecure that is flexible and extensible without making it too complex. Good job indeed, thank you! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Getting the patterns wrong is typical. Is everyone SURE (?) that Struts 1.3 is actually using the CoR pattern or is it just called that? On 6/1/05, Leon Rosenberg [EMAIL PROTECTED] wrote: One major problem lies with how programmers are educated today. A lot of schools teach a language or a design philosophy but rarely are in-depth enough to actually breed the abstract skills necessary for the programmer to become useful. It's a shame, really. I went to college in 1986 (and had been programming since 1978) and within a few years of my graduation in 1990 the curriculum at most schools had been watered down to the point of near uselessness. Well, make a stop... You can't compare things programmed back in the Dark Ages with nowerdays programming. We make far more complicated programms in far less time and for lesser cost. You can critisize overusage of patterns, but under-usage of patterns is clearly at least as bad. Patterns make code understanding simplier, because everyone (should) know them, and simplicity is the goal as many of us stated before. You can't reinvent the wheel each time you write a piece of code, it's simply waste of your time and customers/companies money. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
I had to use an abacus with only one bead per string for binarry. Flippity, flip, flip, flip. Gates were hell. I had to have an assembly of 12 abaci around my neck. On 6/1/05, Tom Dimock [EMAIL PROTECTED] wrote: On Jun 1, 2005, at 12:39 PM, Frank W. Zammetti wrote: Timex Sinclair 1000 by any chance? Agh, you youngsters... My first program ran on a Burroughs 220 that was a vacuum tube based computer! But seriously, I agree fully that having learned on machines that had very limited memory, and having spent a lot of time writing assembler made me a much better programmer. But what I think contributed the most was that all of my early programming was done on mainframes where one compile and run (actually compile, link and run; remember link editors and overlay structures?) per day was considered pretty good turnaround. If you were going to get your programming assignments done on time, you learned to debug code by reading it and thinking until you found the errors. I still make very little use of debuggers to this day, and find the younger programmers completely mystified as to how I ever get code to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Business Layer Ideas
We had to walk in the snow. And we couldn't afford snow boots, so we had to wrap newspapers around our feet! ...and they made us use Macs!!! ;-) -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 4:54 PM To: Struts Users Mailing List Subject: Re: [OT] Business Layer Ideas When I was going to programming school we had to walk to school and back and it was uphill both ways. On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 12:15 pm, Simon Chappell said: Back when I was a young programmer we used to have to think. THINK! Hey, I'm the resident bemoaner of how rough we used to have it! How dare you take my job?!? :) LOL Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart stencil. Stencils?!? I laugh at your stencils! It was only freehand drawings for us, and that was when we took the time to actually PLAN anything! We had it rough I tell you, but I think that we wrote better code back in those days. And those of us that came through them, still have a tendency to do so. I have said on numerous occassions that programmers that have never touched Assembly are, with few exceptions, not as good. And although the overall tone of my reply here is a joking one, this is a point I am serious about. I have actually rejected resumes because they had no Assembly experience. I'm not saying you have to be able to hand-code a 3D game engine, but at least have had some exposure. I spent a number of years doing absolutely nothing BUT Assembly, and while I honestly haven't done anything beyond some very simple subfunctions in the past 5-7 years or so, I wouldn't trade that experience for all the algorithm classes and patterns knowledge in the world. There is NOTHING like understanding, at least at a conceptual level, what's going on down there in the lower layers of your machine. Assembly gives you this. Like I said, there are exceptions to this rule, but I haven't met too many. My first computer had 1K, yes, that's 1024 bytes. Timex Sinclair 1000 by any chance? I loved that little thing! So much so that I spend $200 on one off eBay last year (three of them actually, with a lot of extras). The best thing about it was that if you could manage anything decent on it you were learning... I crammed the entire catalog of movie times for a week for Long Island in it... invented my own rudimentary compression scheme (although I had no clue what compression or algorithms were back then... never even heard the words... I was like 9 or so!). And I didn't have the 16K expansion module because my dad tried to solder it on because we could never get a good contact, but he fried it in the process, so I was stuck with the 1K (actually, now that I think about it, it might have been 2K. I'm not sure). We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Real, worthwhile, programming is hard, so if your going to do it, study for it, and learn (LEARN I say) to do it well. I}hate}}}LISP. LISP... ugh. I can't stand any language that contains more parenthesis per 1,000 lines of code than ACTUAL CODE! :) Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. Yes. Yes. Yes. Thank you Craig. I agree... There are probably architecural decisions in Struts I could complain about, but I think it would quickly become nothing but nitpicking. Craig did a rather good job IMHO of straddling the line between a good architecure that is flexible and extensible without making it too complex. Good job indeed, thank you! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
At least you had newspapers!!! -Ursprüngliche Nachricht- Von: Scott Piker [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 22:59 An: Struts Users Mailing List; Dakota Jack Betreff: RE: [OT] Business Layer Ideas We had to walk in the snow. And we couldn't afford snow boots, so we had to wrap newspapers around our feet! ...and they made us use Macs!!! ;-) -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 4:54 PM To: Struts Users Mailing List Subject: Re: [OT] Business Layer Ideas When I was going to programming school we had to walk to school and back and it was uphill both ways. On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 12:15 pm, Simon Chappell said: Back when I was a young programmer we used to have to think. THINK! Hey, I'm the resident bemoaner of how rough we used to have it! How dare you take my job?!? :) LOL Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart stencil. Stencils?!? I laugh at your stencils! It was only freehand drawings for us, and that was when we took the time to actually PLAN anything! We had it rough I tell you, but I think that we wrote better code back in those days. And those of us that came through them, still have a tendency to do so. I have said on numerous occassions that programmers that have never touched Assembly are, with few exceptions, not as good. And although the overall tone of my reply here is a joking one, this is a point I am serious about. I have actually rejected resumes because they had no Assembly experience. I'm not saying you have to be able to hand-code a 3D game engine, but at least have had some exposure. I spent a number of years doing absolutely nothing BUT Assembly, and while I honestly haven't done anything beyond some very simple subfunctions in the past 5-7 years or so, I wouldn't trade that experience for all the algorithm classes and patterns knowledge in the world. There is NOTHING like understanding, at least at a conceptual level, what's going on down there in the lower layers of your machine. Assembly gives you this. Like I said, there are exceptions to this rule, but I haven't met too many. My first computer had 1K, yes, that's 1024 bytes. Timex Sinclair 1000 by any chance? I loved that little thing! So much so that I spend $200 on one off eBay last year (three of them actually, with a lot of extras). The best thing about it was that if you could manage anything decent on it you were learning... I crammed the entire catalog of movie times for a week for Long Island in it... invented my own rudimentary compression scheme (although I had no clue what compression or algorithms were back then... never even heard the words... I was like 9 or so!). And I didn't have the 16K expansion module because my dad tried to solder it on because we could never get a good contact, but he fried it in the process, so I was stuck with the 1K (actually, now that I think about it, it might have been 2K. I'm not sure). We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Real, worthwhile, programming is hard, so if your going to do it, study for it, and learn (LEARN I say) to do it well. I}hate}}}LISP. LISP... ugh. I can't stand any language that contains more parenthesis per 1,000 lines of code than ACTUAL CODE! :) Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. Yes. Yes. Yes. Thank you Craig. I agree... There are probably architecural decisions in Struts I could complain about, but I think it would quickly become nothing but nitpicking. Craig did a rather good job IMHO of straddling the line between a good architecure that is flexible and extensible without making it too complex. Good job indeed, thank you! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [OT] Business Layer Ideas
At least you had newspapers!!! -Ursprüngliche Nachricht- Von: Scott Piker [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 22:59 An: Struts Users Mailing List; Dakota Jack Betreff: RE: [OT] Business Layer Ideas We had to walk in the snow. And we couldn't afford snow boots, so we had to wrap newspapers around our feet! ...and they made us use Macs!!! ;-) -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 4:54 PM To: Struts Users Mailing List Subject: Re: [OT] Business Layer Ideas When I was going to programming school we had to walk to school and back and it was uphill both ways. On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 12:15 pm, Simon Chappell said: Back when I was a young programmer we used to have to think. THINK! Hey, I'm the resident bemoaner of how rough we used to have it! How dare you take my job?!? :) LOL Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart stencil. Stencils?!? I laugh at your stencils! It was only freehand drawings for us, and that was when we took the time to actually PLAN anything! We had it rough I tell you, but I think that we wrote better code back in those days. And those of us that came through them, still have a tendency to do so. I have said on numerous occassions that programmers that have never touched Assembly are, with few exceptions, not as good. And although the overall tone of my reply here is a joking one, this is a point I am serious about. I have actually rejected resumes because they had no Assembly experience. I'm not saying you have to be able to hand-code a 3D game engine, but at least have had some exposure. I spent a number of years doing absolutely nothing BUT Assembly, and while I honestly haven't done anything beyond some very simple subfunctions in the past 5-7 years or so, I wouldn't trade that experience for all the algorithm classes and patterns knowledge in the world. There is NOTHING like understanding, at least at a conceptual level, what's going on down there in the lower layers of your machine. Assembly gives you this. Like I said, there are exceptions to this rule, but I haven't met too many. My first computer had 1K, yes, that's 1024 bytes. Timex Sinclair 1000 by any chance? I loved that little thing! So much so that I spend $200 on one off eBay last year (three of them actually, with a lot of extras). The best thing about it was that if you could manage anything decent on it you were learning... I crammed the entire catalog of movie times for a week for Long Island in it... invented my own rudimentary compression scheme (although I had no clue what compression or algorithms were back then... never even heard the words... I was like 9 or so!). And I didn't have the 16K expansion module because my dad tried to solder it on because we could never get a good contact, but he fried it in the process, so I was stuck with the 1K (actually, now that I think about it, it might have been 2K. I'm not sure). We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Real, worthwhile, programming is hard, so if your going to do it, study for it, and learn (LEARN I say) to do it well. I}hate}}}LISP. LISP... ugh. I can't stand any language that contains more parenthesis per 1,000 lines of code than ACTUAL CODE! :) Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. Yes. Yes. Yes. Thank you Craig. I agree... There are probably architecural decisions in Struts I could complain about, but I think it would quickly become nothing but nitpicking. Craig did a rather good job IMHO of straddling the line between a good architecure that is flexible and extensible without making it too complex. Good job indeed, thank you! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [OT] Business Layer Ideas
On 6/1/05, Leon Rosenberg [EMAIL PROTECTED] wrote: *snip* Would you be able to code them with c? Forget it. Actually, I suspect that alot of these have been coded with C/C++. What we have had was mostly alpha-numeric based terminals (remember borlands gdi?) with maybe 10-20 business functions. Now, a pissy web-portal has more functionallity then the whole supercalc suite. I think that I doubt this assertion. Nostalgic talking about old times is ok, but you shouldn't forget reality... I work with reality every day. And talking about complicated and simplicity... What is simplier to read, 10 classes a 20 lines java code, or 5000 lines of assembler code doing the same? Now, I don't know what the accepted conversion factor is for Java to assembler, but I think that this question/comparison is flawed. As a technical lead, if you show me ten classes each containing only 20 lines of code, then you'd better be prepared to explain yourself. I'm all for using the OO aspects of Java, but not at the expense of clear, concise code. Most less-experienced Java developers have too many objects, especially for their logic. I hate crawling around a million objects with short methods where the thread bounces around between them and leaves you feeling cross-eyed by the time you get it figured out. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Leon Rosenberg wrote: Modern OSes, office suites or business software. Modern guis, with integrated media support, integrated audio/video broad- and unicasts, animations, sounds, and so on... Would you be able to code them with c? Forget it. Why wouldn't I? We used to code most anything of importance in C, yanno, including some pretty fancy stuff. BeOS was written in C/C++, and that was pretty nifty. Plato and Lotus Notes was all or mostly C, at least at the beginning, wasn't it? Now, a pissy web-portal has more functionallity then the whole supercalc suite. Really? Depends on what you mean by functionality, I suppose. Supercalc could (and did) run businesses. I can't run a business with a portal. And talking about complicated and simplicity... What is simplier to read, 10 classes a 20 lines java code, or 5000 lines of assembler code doing the same? Guess that depends on what you know. Just like I'd avoid reading 5000 lines of assembly, I'd avoid reading 200 lines of Java, and read the documentation. A lot of the assembly coding I did ended up being mini-languages that would assemble to the actual code (sort of like a JVM, I suppose) so I didn't have to read 5000 lines, I just read the 200 lines that actually solved the problem, just like in the Java: I only read the code that's important. That said, the majority of low-level programming I did on bare-metal systems was in Forth, so I rarely had to look at my assembly code once it was written and tested. Nobody has said that modern* languages don't give you anything. All I said was that _I_ think patterns can be over-used, that _I_ was more productive using 15-year old SmallTalk and Lisp environments, and that I have yet to be convinced that much of what people think is so great about today's languages, platforms, tools, etc. is necessarily a Good Thing: I am consistently more impressed by programmers that learned to program in my era than today. Relax, it's okay. Dave * What's a modern language, anyway? What features does a modern language have? I don't think Java is as widely used as it is because it's interesting or powerful, it was just a better C++ with marketing. (And I'm only partially playing devil's advocate here.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On 6/1/05, Leon Rosenberg [EMAIL PROTECTED] wrote: Java is actually the first component-oriented language. SmallTalk? My Smalltalk/V 32-Bit Object-Oriented Programming System book circa 1994 has a Smalltalk link library (.sll) full of components called components which you could dynamically bind and unbind. -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Actually smalltalk was a very good candidate, and java sells some technologies as modern, which were developed in/for smalltalk decades ago... Ok, let's say: java is the first component-oriented language accepted by masses (or powered by a huge company)? Regards Leon -Ursprüngliche Nachricht- Von: Dakota Jack [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 23:43 An: Struts Users Mailing List Betreff: Re: [OT] Business Layer Ideas On 6/1/05, Leon Rosenberg [EMAIL PROTECTED] wrote: Java is actually the first component-oriented language. SmallTalk? My Smalltalk/V 32-Bit Object-Oriented Programming System book circa 1994 has a Smalltalk link library (.sll) full of components called components which you could dynamically bind and unbind. -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Actually smalltalk was a very good candidate, and java sells some technologies as modern, which were developed in/for smalltalk decades ago... Ok, let's say: java is the first component-oriented language accepted by masses (or powered by a huge company)? Regards Leon -Ursprüngliche Nachricht- Von: Dakota Jack [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 23:43 An: Struts Users Mailing List Betreff: Re: [OT] Business Layer Ideas On 6/1/05, Leon Rosenberg [EMAIL PROTECTED] wrote: Java is actually the first component-oriented language. SmallTalk? My Smalltalk/V 32-Bit Object-Oriented Programming System book circa 1994 has a Smalltalk link library (.sll) full of components called components which you could dynamically bind and unbind. -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Leon Rosenberg wrote: Actually smalltalk was a very good candidate, and java sells some technologies as modern, which were developed in/for smalltalk decades ago... And Lisp, don't forget Lisp. Ok, let's say: java is the first component-oriented language accepted by masses (or powered by a huge company)? Accepted by masses might work for me. Not that this is necessarily a Good Thing, of course, and might, in fact, be just the opposite. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
At least you had FEET! :) Leon Rosenberg wrote: At least you had newspapers!!! -Ursprüngliche Nachricht- Von: Scott Piker [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 1. Juni 2005 22:59 An: Struts Users Mailing List; Dakota Jack Betreff: RE: [OT] Business Layer Ideas We had to walk in the snow. And we couldn't afford snow boots, so we had to wrap newspapers around our feet! ...and they made us use Macs!!! ;-) -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 4:54 PM To: Struts Users Mailing List Subject: Re: [OT] Business Layer Ideas When I was going to programming school we had to walk to school and back and it was uphill both ways. On 6/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, June 1, 2005 12:15 pm, Simon Chappell said: Back when I was a young programmer we used to have to think. THINK! Hey, I'm the resident bemoaner of how rough we used to have it! How dare you take my job?!? :) LOL Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart stencil. Stencils?!? I laugh at your stencils! It was only freehand drawings for us, and that was when we took the time to actually PLAN anything! We had it rough I tell you, but I think that we wrote better code back in those days. And those of us that came through them, still have a tendency to do so. I have said on numerous occassions that programmers that have never touched Assembly are, with few exceptions, not as good. And although the overall tone of my reply here is a joking one, this is a point I am serious about. I have actually rejected resumes because they had no Assembly experience. I'm not saying you have to be able to hand-code a 3D game engine, but at least have had some exposure. I spent a number of years doing absolutely nothing BUT Assembly, and while I honestly haven't done anything beyond some very simple subfunctions in the past 5-7 years or so, I wouldn't trade that experience for all the algorithm classes and patterns knowledge in the world. There is NOTHING like understanding, at least at a conceptual level, what's going on down there in the lower layers of your machine. Assembly gives you this. Like I said, there are exceptions to this rule, but I haven't met too many. My first computer had 1K, yes, that's 1024 bytes. Timex Sinclair 1000 by any chance? I loved that little thing! So much so that I spend $200 on one off eBay last year (three of them actually, with a lot of extras). The best thing about it was that if you could manage anything decent on it you were learning... I crammed the entire catalog of movie times for a week for Long Island in it... invented my own rudimentary compression scheme (although I had no clue what compression or algorithms were back then... never even heard the words... I was like 9 or so!). And I didn't have the 16K expansion module because my dad tried to solder it on because we could never get a good contact, but he fried it in the process, so I was stuck with the 1K (actually, now that I think about it, it might have been 2K. I'm not sure). We can only hope. Perhaps the prophesied return of Lisp will finally happen and people will discover REAL programming, not this Teach Yourself The Latest Junk in 24 Hours stuff. Real, worthwhile, programming is hard, so if your going to do it, study for it, and learn (LEARN I say) to do it well. I}hate}}}LISP. LISP... ugh. I can't stand any language that contains more parenthesis per 1,000 lines of code than ACTUAL CODE! :) Well done, Craig, with restrospect. A simpler designed framework like Struts is exactly the example, the proof, which Simon espouses above. Yes. Yes. Yes. Thank you Craig. I agree... There are probably architecural decisions in Struts I could complain about, but I think it would quickly become nothing but nitpicking. Craig did a rather good job IMHO of straddling the line between a good architecure that is flexible and extensible without making it too complex. Good job indeed, thank you! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [OT] Business Layer Ideas
Fortran | | | Pascal Algol | | -- CPL | || Ada Modula-2 BCPL | || Ada 95 Modula-3 B | C Simula || | -- C++ | | | Eiffel Smalltalk Java Here are the object -oriented programming languages of note: Ada 95, Modula-3, C++, Eiffel, Smalltalk and Java. Right? I think Lisp along with Prolog, Scheme, Guile and CLOS (Common Lisp) as children of Logic and Fortran is considered to be Functional and Logic Programming Languages. On 6/1/05, Dave Newton [EMAIL PROTECTED] wrote: Leon Rosenberg wrote: Actually smalltalk was a very good candidate, and java sells some technologies as modern, which were developed in/for smalltalk decades ago... And Lisp, don't forget Lisp. Ok, let's say: java is the first component-oriented language accepted by masses (or powered by a huge company)? Accepted by masses might work for me. Not that this is necessarily a Good Thing, of course, and might, in fact, be just the opposite. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On 6/1/05, Pilgrim, Peter [EMAIL PROTECTED] wrote: -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] ==== Strategy (315) Define a family of algorithms encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. This is exactly I always thought it was too. The point is that whatever you thought it was you code was merely three implementations of an interface having nothing to do with the Strategy Pattern. This is not mere nitpicking or picnicing. If you look at some of the patterns without a careful eye you will miss everything. For example, you can do a UML diagram of a State Pattern and a Strategy Pattern and get the exact same diagram. Indeed, the GoF book does just that. This does not mean at all, however, that those two patterns are the same. They could not be more different. Also, I am of the opinion that commons chain is not a Chain of Responsibility Pattern even if it is interesting and helpful. I will say more about on a rainy day. ///;-) Pace Vobiscum and Capre Diem -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Simon Chappell wrote: Back when I was a young programmer we used to have to think. THINK! Oh the humanity. No patterns for us. Just endless cups of tea, a pad of paper (or the back of long listings on greenbar) and your flowchart Too funny; I remember when my 'IDE' was a sheaf of butcher's paper and a pencil. I could debug a program by writing a list of variables down the left side of the page, and enumerating their values in columns as I single stepped through (i.e. 'read') the souce code on an adjacent page. The 'edit' phase was where I transcribed the code from paper into the computer or editted the progam interactively (imagine!) in an editor. I was working in BASIC back then, so I didn't have to worry about compiling or linking -- I cut my teath on a 'dynamic programming language', bet you never thought of BASIC that way before! I have to admit that refactoring on butcher paper was a bitch though! :-) L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
(yes, my school actually had Fortran, COBOL and Pascal classes!)
Your *high school* had multiple courses on different programming
languages? My high school ('secondary school' actually, I'm originally
from England) had exactly one 'O'-level computer course and one
'A'-level course. There might bave been a pre--'O'-level required course
too...
Any which way, my first computer related course in school was so basic I
walked away and never looked back until I got to university and realised
that I was skipping too many physics classes to play around in the
computer labs :-)
I'm guessing (from other posts in this thread) you're a little older
than I am. That would make your high school pretty impressively
forard-looking...!
L.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Business Layer Ideas
-Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] ==== I should have added that Rod (Johnson) in the book cited pointedly advocates extensive use of the Strategy Pattern, see pp. 421 ff. The use of CoR in Struts 1.3 for the extensible RequestProcessor is not a feature but is a way of solving the problem created by the original use of the Template Method Pattern in that context. Had the Strategy Pattern been used in the first instance, everything would have worked better, in my opinion. In many ways, I think in the future the Template Method Pattern may be seen as an Anti-Pattern. Just to forestall flamethrowers, I want to emphasize that others probably think differently and even the majority, i.e. by definition the members ipsa facto of the meritocracy, may think differently. But, Rod Johnson is no slouch on these matters. He thinks the use of Strategy Pattern is one of the reasons [Spring] is such a flexible and extensible framework. Hello Jack It can be shown that ``Chain of Responsibility'' pattern can be metamorphed into the ``Strategy'' pattern. The first proviso is that one of your commnds becomes a catalogy factory or invoker of other generic commands itself. The second proviso is you must pass all your information back and forward the ``strategy command'' using a general context object. fyi On 5/27/05, David Whipple [EMAIL PROTECTED] wrote: This is an off topic post, but there seem to be a lot of people with good opinions here. I am trying to provide a framework (based on Stuts and Spring) for our company to use. I'd like to make a reinforcement of the business layer in applications. We do not use EJBs, so a lot of the patterns that are out there do not seem to apply. I have not been able to find any references I like. The goal is to encourage better program design and development by having a clear definition of what are the business objects in the program. We want to come up with a way through patterns to help programmers avoid poor programming practices. Clear separation into layers is one basic idea behind this. We want to come up with some interface to the business layer which will force programmers to know what are to be the business objects in their architecture. Does anyone have any ideas and/or know of any references for this? Thanks, Dave ==== -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, Credit Suisse, its subsidiaries and affiliates (CS) do not waive any confidentiality or privilege. CS retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CS until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
Hi, Peter,
I am not sure what you are saying here. I had trouble following you.
The Strategy Pattern is roughly the following:
public class DefaultStrategyInterface implements StrategyInterface {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doWork() {
// Do business logic
int value = hleper.calculateSomething(params);
// Do more business logic
}
}
The Template Method Pattern used in Struts which necessitates the use
of the Chain of Responsibility Pattern, cf.
http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html, is
roughly the following:
public abstract class AbstractMethodInterface implements MethodInterface {
public void doWork() {
// Do some business logic
int value = calculateSomething(params);
// Do more business logic
}
protected abstract int calculateSomething(params);
}
So, in a real sense, the Strategy Pattern advocates, in comparison to
the Template Method Pattern, composition over inheritance allowing for
ease of testing and a host of other good results.
Struts is based on the Template Method Pattern which Sigglelow rightly
sees is rescued by the Chain of Responsibility Pattern. This is the
context in which I was addressing the Strategy Pattern. Can you give
a little demo of how CoR metamorphasis's into this? I find your not
interesting but cannot see what it means.
Thanks
On 5/31/05, Pilgrim, Peter [EMAIL PROTECTED] wrote:
-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
====
I should have added that Rod (Johnson) in the book cited pointedly
advocates extensive use of the Strategy Pattern, see pp. 421 ff. The
use of CoR in Struts 1.3 for the extensible RequestProcessor is not a
feature but is a way of solving the problem created by the original
use of the Template Method Pattern in that context. Had the Strategy
Pattern been used in the first instance, everything would have worked
better, in my opinion. In many ways, I think in the future the
Template Method Pattern may be seen as an Anti-Pattern.
Just to forestall flamethrowers, I want to emphasize that others
probably think differently and even the majority, i.e. by definition
the members ipsa facto of the meritocracy, may think differently.
But, Rod Johnson is no slouch on these matters. He thinks the use of
Strategy Pattern is one of the reasons [Spring] is such a flexible
and extensible framework.
Hello Jack
It can be shown that ``Chain of Responsibility'' pattern can be
metamorphed into the ``Strategy'' pattern. The first proviso is that one
of your commnds becomes a catalogy factory or invoker of other
generic commands itself. The second proviso is you must pass all
your information back and forward the ``strategy command'' using
a general context object.
fyi
On 5/27/05, David Whipple [EMAIL PROTECTED] wrote:
This is an off topic post, but there seem to be a lot of
people with good
opinions here.
I am trying to provide a framework (based on Stuts and
Spring) for our
company
to use. I'd like to make a reinforcement of the business layer in
applications.
We do not use EJBs, so a lot of the patterns that are out
there do not seem
to
apply. I have not been able to find any references I like.
The goal is to encourage better program design and development by
having a clear definition of what are the business objects
in the program.
We want to come up with a way through patterns to help
programmers avoid
poor
programming practices. Clear separation into layers is one
basic idea
behind
this. We want to come up with some interface to the
business layer which
will
force programmers to know what are to be the business
objects in their
architecture.
Does anyone have any ideas and/or know of any references for this?
Thanks,
Dave
====
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, Credit Suisse, its subsidiaries and affiliates (CS) do not
waive any confidentiality or privilege. CS retains and monitors electronic
communications sent through its network. Instructions transmitted over this
system are not binding on CS until they are confirmed by us. Message
transmission is not guaranteed to be secure.
==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: [OT] Business Layer Ideas
I meant I find your note interesting and not I find your not interesting.
On 5/31/05, Dakota Jack [EMAIL PROTECTED] wrote:
Hi, Peter,
I am not sure what you are saying here. I had trouble following you.
The Strategy Pattern is roughly the following:
public class DefaultStrategyInterface implements StrategyInterface {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doWork() {
// Do business logic
int value = hleper.calculateSomething(params);
// Do more business logic
}
}
The Template Method Pattern used in Struts which necessitates the use
of the Chain of Responsibility Pattern, cf.
http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html, is
roughly the following:
public abstract class AbstractMethodInterface implements MethodInterface {
public void doWork() {
// Do some business logic
int value = calculateSomething(params);
// Do more business logic
}
protected abstract int calculateSomething(params);
}
So, in a real sense, the Strategy Pattern advocates, in comparison to
the Template Method Pattern, composition over inheritance allowing for
ease of testing and a host of other good results.
Struts is based on the Template Method Pattern which Sigglelow rightly
sees is rescued by the Chain of Responsibility Pattern. This is the
context in which I was addressing the Strategy Pattern. Can you give
a little demo of how CoR metamorphasis's into this? I find your not
interesting but cannot see what it means.
Thanks
On 5/31/05, Pilgrim, Peter [EMAIL PROTECTED] wrote:
-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
====
I should have added that Rod (Johnson) in the book cited pointedly
advocates extensive use of the Strategy Pattern, see pp. 421 ff. The
use of CoR in Struts 1.3 for the extensible RequestProcessor is not a
feature but is a way of solving the problem created by the original
use of the Template Method Pattern in that context. Had the Strategy
Pattern been used in the first instance, everything would have worked
better, in my opinion. In many ways, I think in the future the
Template Method Pattern may be seen as an Anti-Pattern.
Just to forestall flamethrowers, I want to emphasize that others
probably think differently and even the majority, i.e. by definition
the members ipsa facto of the meritocracy, may think differently.
But, Rod Johnson is no slouch on these matters. He thinks the use of
Strategy Pattern is one of the reasons [Spring] is such a flexible
and extensible framework.
Hello Jack
It can be shown that ``Chain of Responsibility'' pattern can be
metamorphed into the ``Strategy'' pattern. The first proviso is that one
of your commnds becomes a catalogy factory or invoker of other
generic commands itself. The second proviso is you must pass all
your information back and forward the ``strategy command'' using
a general context object.
fyi
On 5/27/05, David Whipple [EMAIL PROTECTED] wrote:
This is an off topic post, but there seem to be a lot of
people with good
opinions here.
I am trying to provide a framework (based on Stuts and
Spring) for our
company
to use. I'd like to make a reinforcement of the business layer in
applications.
We do not use EJBs, so a lot of the patterns that are out
there do not seem
to
apply. I have not been able to find any references I like.
The goal is to encourage better program design and development by
having a clear definition of what are the business objects
in the program.
We want to come up with a way through patterns to help
programmers avoid
poor
programming practices. Clear separation into layers is one
basic idea
behind
this. We want to come up with some interface to the
business layer which
will
force programmers to know what are to be the business
objects in their
architecture.
Does anyone have any ideas and/or know of any references for this?
Thanks,
Dave
====
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, Credit Suisse, its subsidiaries and affiliates (CS) do not
waive any confidentiality or privilege. CS retains and monitors electronic
communications sent through its network. Instructions transmitted over this
system are not binding on CS until they are confirmed by us. Message
transmission is not guaranteed to
Re: [OT] Business Layer Ideas
Just one last little thing, Peter, so that there is no misunderstanding. It is absolutely critical in the Strategy Pattern that we deal with a Java Bean. A great proportion of the fruits of the Strategy Pattern rely on that so that if your metamophasis does not retain this feature, it is not a true metamorphasis. On 5/31/05, Pilgrim, Peter [EMAIL PROTECTED] wrote: -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] ==== I should have added that Rod (Johnson) in the book cited pointedly advocates extensive use of the Strategy Pattern, see pp. 421 ff. The use of CoR in Struts 1.3 for the extensible RequestProcessor is not a feature but is a way of solving the problem created by the original use of the Template Method Pattern in that context. Had the Strategy Pattern been used in the first instance, everything would have worked better, in my opinion. In many ways, I think in the future the Template Method Pattern may be seen as an Anti-Pattern. Just to forestall flamethrowers, I want to emphasize that others probably think differently and even the majority, i.e. by definition the members ipsa facto of the meritocracy, may think differently. But, Rod Johnson is no slouch on these matters. He thinks the use of Strategy Pattern is one of the reasons [Spring] is such a flexible and extensible framework. Hello Jack It can be shown that ``Chain of Responsibility'' pattern can be metamorphed into the ``Strategy'' pattern. The first proviso is that one of your commnds becomes a catalogy factory or invoker of other generic commands itself. The second proviso is you must pass all your information back and forward the ``strategy command'' using a general context object. fyi On 5/27/05, David Whipple [EMAIL PROTECTED] wrote: This is an off topic post, but there seem to be a lot of people with good opinions here. I am trying to provide a framework (based on Stuts and Spring) for our company to use. I'd like to make a reinforcement of the business layer in applications. We do not use EJBs, so a lot of the patterns that are out there do not seem to apply. I have not been able to find any references I like. The goal is to encourage better program design and development by having a clear definition of what are the business objects in the program. We want to come up with a way through patterns to help programmers avoid poor programming practices. Clear separation into layers is one basic idea behind this. We want to come up with some interface to the business layer which will force programmers to know what are to be the business objects in their architecture. Does anyone have any ideas and/or know of any references for this? Thanks, Dave ==== -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, Credit Suisse, its subsidiaries and affiliates (CS) do not waive any confidentiality or privilege. CS retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CS until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On 5/27/05, Duong BaTien [EMAIL PROTECTED] wrote: We use Chain of Responsibility (CoR) implemented by commons-chain and its Agility to construct a Request/Response framework to connect a request to its designated service, whether the designated service is in a web-application service container, a portlet container, auth for authentication/authorization, or a Jcr container. I'm also finding that, for my applications, a service orientated architecture based on a Chain of Responsibility works quite well. I've started work on a framework that pushes a lot of what we do now in Struts into the business layer. It's in C# now, because that what we are using at work, but it's all plain old objects and should be an easy port back to Java. * http://wiki.apache.org/struts/StrutsOverDrive We're using a nearly-complete prototype at work, so I've a good handle on where this is going. It's just hard to find the time to clean it up for public consumption :) The essential idea is that the presentation tier should focus on collecting and display values, and leave the rest to the business layer. Right now, a lot of us slide down a slipperly slope that pushes too much code into the presentation layer, where it is difficult to test. And, by test, I really mean share with other presentation layers. Unit tests are a presentation layer too :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Business Layer Ideas
http://www.whitesandsolutions.com/wssBase-Framework%20Architecture.htm http://www.whitesandsolutions.com/wssBase-Patterns.htm (Two images here. Use navigation in left frame.) View the above links with Microsoft Internet Explorer so you can use the pan and zoom features. -Original Message- From: David Whipple [mailto:[EMAIL PROTECTED] Sent: Friday, May 27, 2005 2:00 PM To: Struts Users Mailing List Subject: [OT] Business Layer Ideas This is an off topic post, but there seem to be a lot of people with good opinions here. I am trying to provide a framework (based on Stuts and Spring) for our company to use. I'd like to make a reinforcement of the business layer in applications. We do not use EJBs, so a lot of the patterns that are out there do not seem to apply. I have not been able to find any references I like. The goal is to encourage better program design and development by having a clear definition of what are the business objects in the program. We want to come up with a way through patterns to help programmers avoid poor programming practices. Clear separation into layers is one basic idea behind this. We want to come up with some interface to the business layer which will force programmers to know what are to be the business objects in their architecture. Does anyone have any ideas and/or know of any references for this? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
On Fri, 2005-05-27 at 16:00 -0400, David Whipple wrote: This is an off topic post, but there seem to be a lot of people with good opinions here. I am trying to provide a framework (based on Stuts and Spring) for our company to use. I'd like to make a reinforcement of the business layer in applications. We do not use EJBs, so a lot of the patterns that are out there do not seem to apply. I have not been able to find any references I like. The goal is to encourage better program design and development by having a clear definition of what are the business objects in the program. We want to come up with a way through patterns to help programmers avoid poor programming practices. Clear separation into layers is one basic idea behind this. We want to come up with some interface to the business layer which will force programmers to know what are to be the business objects in their architecture. Does anyone have any ideas and/or know of any references for this? Thanks, Dave Greetings: We use Chain of Responsibility (CoR) implemented by commons-chain and its Agility to construct a Request/Response framework to connect a request to its designated service, whether the designated service is in a web-application service container, a portlet container, auth for authentication/authorization, or a Jcr container. At the business layer, the designated service may use other services in other containers. e.g. the personalization of auth container uses UserDaoImpl of DAO container. We use Spring IoC to assemble chain Catalogs and their commands. Hence the request/response framework is based on CoR/IoC integrated with your presentation engine at the front. We use Jsf+Tiles as our presentation engine. The good thing is that available infrastructure takes care of detailed connections while isolating the dependencies of itemized services within 1 container and among containers. Developers just need to plug in the required specified functionality based on design contract. We integrate the Request/Response with workflow using Shale Dialog and Spring WebFlow to produce Request/Response/Workflow Business Application Framework. More detailed discussion is in the following link, which will be updated by 2nd week of June after the release of RedHat Fedora 4. http://www.dbgroups.com/docs/architecture.html#BusinessApplicationsFramework Hope this may help. BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
A really wonderful book is J2EE Development without EJB by Rod Johnson, the original architect for Spring.On the whole, however, outside the issues associated with EJBs, there is a dirth of buisness layers patterns, so far as I know. I think some thought about developing a separate framework for the business layer alone would be worthwhile. I have been thinking and trying to get discussion going on this a long time. I like the way you think. On 5/27/05, David Whipple [EMAIL PROTECTED] wrote: This is an off topic post, but there seem to be a lot of people with good opinions here. I am trying to provide a framework (based on Stuts and Spring) for our company to use. I'd like to make a reinforcement of the business layer in applications. We do not use EJBs, so a lot of the patterns that are out there do not seem to apply. I have not been able to find any references I like. The goal is to encourage better program design and development by having a clear definition of what are the business objects in the program. We want to come up with a way through patterns to help programmers avoid poor programming practices. Clear separation into layers is one basic idea behind this. We want to come up with some interface to the business layer which will force programmers to know what are to be the business objects in their architecture. Does anyone have any ideas and/or know of any references for this? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
I should have added that Rod (Johnson) in the book cited pointedly advocates extensive use of the Strategy Pattern, see pp. 421 ff. The use of CoR in Struts 1.3 for the extensible RequestProcessor is not a feature but is a way of solving the problem created by the original use of the Template Method Pattern in that context. Had the Strategy Pattern been used in the first instance, everything would have worked better, in my opinion. In many ways, I think in the future the Template Method Pattern may be seen as an Anti-Pattern. Just to forestall flamethrowers, I want to emphasize that others probably think differently and even the majority, i.e. by definition the members ipsa facto of the meritocracy, may think differently. But, Rod Johnson is no slouch on these matters. He thinks the use of Strategy Pattern is one of the reasons [Spring] is such a flexible and extensible framework. On 5/27/05, David Whipple [EMAIL PROTECTED] wrote: This is an off topic post, but there seem to be a lot of people with good opinions here. I am trying to provide a framework (based on Stuts and Spring) for our company to use. I'd like to make a reinforcement of the business layer in applications. We do not use EJBs, so a lot of the patterns that are out there do not seem to apply. I have not been able to find any references I like. The goal is to encourage better program design and development by having a clear definition of what are the business objects in the program. We want to come up with a way through patterns to help programmers avoid poor programming practices. Clear separation into layers is one basic idea behind this. We want to come up with some interface to the business layer which will force programmers to know what are to be the business objects in their architecture. Does anyone have any ideas and/or know of any references for this? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Business Layer Ideas
http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764558315,descCd-download_code.html On 5/27/05, David Whipple [EMAIL PROTECTED] wrote: This is an off topic post, but there seem to be a lot of people with good opinions here. I am trying to provide a framework (based on Stuts and Spring) for our company to use. I'd like to make a reinforcement of the business layer in applications. We do not use EJBs, so a lot of the patterns that are out there do not seem to apply. I have not been able to find any references I like. The goal is to encourage better program design and development by having a clear definition of what are the business objects in the program. We want to come up with a way through patterns to help programmers avoid poor programming practices. Clear separation into layers is one basic idea behind this. We want to come up with some interface to the business layer which will force programmers to know what are to be the business objects in their architecture. Does anyone have any ideas and/or know of any references for this? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
