Slashdot Mirror
Manning's Struts in Action
What's Needed So it is generally acknowledged that using the MVC pattern is the proper way to build web applications, but with the large number of technologies and frameworks it can be a long road to figure what is the best solution for your application. What we need is a book that covers the best practices of web application design and development from both a technology/architecture perspective, and is written by a few folks who have deep understanding of the underlying problems of building robust web applications.
That's what I love the most about this book, it doesn't just talk about how to configure and develop with Struts. It's a web application manifesto. Anyone can write a book about how to use Struts to build a web application. That's not the point. This book is ~8 people-years worth of first-hend developer knowledge (4 authors x ~2 years of working on the Struts project) condensed down into 630 pages. It doesn't just teach you how to use Struts (and Velocity and Taglibs and Tiles), but why you should use them. That's the most important thing this book has to offer. If your project is looking at using Struts & other Jakarta technologies, you need this book. If your project is currently using Struts & other Jakarta technologies, you need this book.
What's Bad?The Velocity coverage is pretty light. If you are more comfortable building logic with a quasi-shell script language instead of using markup tags, then you should look to the project's documentation for further reference before embarking on a prototype. The Jakarta Lucene project, is touched on in the sample application they build, but are left as an exercise for the reader to investigate. While it's good to bring in related technologies to flesh out your sample apps, you have to be careful not to get sidetracked from the primary topic. You could easily write several books about the other components developed by the Jakarta project.
What's Good?The best part is that the 4 authors are all Struts authorities (one Jakarta project manager, 2 Struts committers, one principal consultant), so they know Struts and the other Jakarta web frameworks inside and out. More than that, these guys have been solving the problems involved with web applications for several years now. They have deep experience in the patterns and best practices of building robust and flexible web applications, and this book passes on their experiences to the reader.
So What's In It For Me?With this book and a little bit of effort on your part, you will be a competent Java web application developer. With a little bit more effort, you will become a Java web application architect. It's worth the extra effort. This is a tremendous book that will set the standard for web application references and will continue to be useful for years to come. It reminds me of the first Manning book I read, Neward's Server-Based Java Programming in terms of it's scope. approach and usefulness.
You can purchase Struts in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
People considering using structs might want to take a look (as you always should) at alternate technologies... The one I might suggest would be Tapestry with IDE integration with Eclipse through Spindle.
Platform independent bug tracking software
www.cgisecurity.com/lib
MVC is about design, its about knowing that your application will be maintained by other people. Its about seperating the various elements so multiple people can work on your project. Its about ensuring that elements are re-used effectively so testing effort is used more effectively.
MVC is about projects that work well. So to all those people who just "hack it together on my own", please remember that there are some people out there who do this for a living on sites and system that will still be maintained in 5, 10, 15 years or even longer. That is why you choose MVC, because you realise that Go-Live is only a small part of TCO.
MVC is great, and MDA is even better because it uses similar patterns at an even higher level.
Design is good, design works, patterns work. Just because you can "write 1,000 lines in a day" doesn't mean that in 6 months time even YOU will be able to maintain it. Don't knock it until you've been on a project with 10 people where they all thought they could do it their own way.
Be an engineer, not a script kiddie.
An Eye for an Eye will make the whole world blind - Gandhi
Random MVC joke. Saw a cartoon in a Java mag once where a project manager is saying to his engineers, "For this part of the user interface we can either go with a Swing applet, or ActiveX control." Engineers all chant "Swing!Swing!Swing!" Project manager says, "If we go with Swing, it will require substantial work with JTree." Engineers all chant "ActiveX! ActiveX! ActiveX!"
:) Duane
www.HearMySoulSpeak.com
Everytime I go back and consider using struts.. I keep realizing I already use the MVC. Struts too me seems like extra bloat.
:)
Basically I have a master url such as: http://mywebsite/servlet/IndexServlet (lets just say).
The master servlet always takes in an "f" parameter to determine state. f=login , f=mainmenu, f=saveform, etc...
It uses that f parameter to pull out the proper "Action Object" (or control) from a stored hashtable that is initialized once. Then it executes that ActionObject (or whatever you choose to call it) which handles the other parameters (other than f), does what it needs to, and pushes out the proper JSP "view" of your choosing.
This could be simply displaying a form, saving a form to database and displaying a success page, yadda yadda yadda. Of course some actions can be used for more than one thing if you code smartly.
I have saved eons of time doing this this way, making my "ActionObjects" as reusable as possible.
All along security is maintained via sessions.
It's easy, and you don't need third party libs to do it.
Commentary and questions are welcome of course. I expect half of you have come up with some flaws
--Zuchini
Could someone give a quick overview of what Struts is/are? Is it a technology, a language, or just a term given to a way of doing things?
Waltz, nymph, for quick jigs vex Bud.
There's a site called JavaRanch, which has some useful forums for the serious Java developer. If you participate in their "Open Source Projects" forum, you'll be entered into a draw to win a copy of the book.
Also, one of the authours (Ted Husted) will be on-line to answer questions. Note that you need to register - No Anonymous Cowards!
FYI - Struts is quickly becoming the framework of choice for all J2EE coding houses. Having struts experience is a huge plus on your resume. The other Java tech to watch out for is portals (ie - jakarta's portal engine, or WebSphere's portal engine).
I digress, but I've used struts and the MVC pattern plenty at my job, and it just makes life so easy when adding in new functionality, fixing bugs quickly, and overall maintainability.
Those that say "its good in theory, not in practice" haven't used it correctly in practice.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
IS MVC really the best way to build web applications? It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?
Does Slashdot use an MVC pattern? MSN? Yahoo?
"For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
Yeah, but do you write commercial web-apps? Ones that are complex? What's your definition of "Good"?
I have this book, and JSTL In Action and both of them are truly excellent books. The 11/10 rating is quite appropriate. I have been attempting to convince myself to buy the Manning Ant book as well - just for the documentation on all of the Ant extensions that it includes.
Additinally, Manning Press has experimented with releasing PDF versions of books (in read only if you use acroread or windows, but not otherwise) and this was how I first met their books. (The books were hosted over at The Server Side). Anyway, this was my first intro to Manning Press. I now look over their books before any other.
The think I like most about Manning books is that they are written for smart people who have clues. Many tech books feel the need to explain basic concepts of programming in every single one, Manning doesn't bother - they stick to the topic on hand, they write as if the audience has a clue, is intelligent, and has real work to get done.
IMHO using Struts (and web applications in general) you cannot build true MVC based applications.
The MVC model defines more communication options and knowledge between objects that Struts is able to provide. MVC is event driven, a Struts application is driven by actions (post or get).
The Structs framework, as I understand it, in general works like this:
- A http request is sent to some dispatch. This dispatch converts the request into an 'action'.
- The action is executed and returns a new request, either for a JSP or some other Template to be rendered or a new action.
Using MVC a view contains components that have corresponding controllers. The view is usually a predefined API to a collection of widgets (like AWT, Swing, etc.). The controller is built of events bound to the widgets.
Struts calls the jsp's the view, the actions the controller and the back-end or business logic you define the model.
However MVC allows the model to interact with the view, and there is no way you can be sure you will be able to do so with a web page, because HTTP only supports polling and not pushing if you want to keep things browser independant.
Well that's why I would not dare to say Struts implements MVC for web applications, but I must admit it provides a very nice framework.
giel.y contains 2 shift/reduce conflicts
I was a jump-in-and-hack coder (self-taught, used to program as a hobby, etc.) and they finally convinced me that design works. The only problem with a lot of patterns is that they don't apply that well to a non-OO language. Hence, the rise of Java, which is designed, as a language, around patterns.
I still call myself a programmer, though, not an "engineer". Engineers build bridges, I just write programs.
I really like the O'Reilly book that just came out. Most of the chapters of this book went through public review, if I remember correctly. The book is very solid.
The real advantage of struts for me comes from its ability to handle forms. Regular expression checking of input is a great way to make sure you don't take in bad data. Not having to write this code, and code to handle and repost the page when errors occur, takes away a lot of the tedium of development.
What I don't like about struts is all the abstractions. New developers should start with the basics and work up. But no one has the time for that. So figuring out what is going on under the covers is hard to do. The O'Reilly book is pretty good at trying to explain some of this stuff. But there's no substitute for actually doing it.
And is it just me, or has 'real' coding started to go away? I spend half my time messing with xml config files anymore. I get more done, but it isn't as much fun.
Yeah, for personal websites and such, no major MVC and EJB and other J2EE is necessary, but if you have a enterprise size 50+ page site that requires all the wizbangs and is complex (like online banking), good luck designing all that perl.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
I don't think anyone will claim you have to use third party applications to create an MVC-based web app. In fact, if you look at the core of Struts, it's rather simple (which IMHO is what makes it so nice). Any decent java developer could write something similiar and many have.
I think the point is, why go it alone? When you can have hundreds of developers all working on and testing the same framework you end up with a lot more features and much more stable code. Sure I could write my own controler servlet (which is what Struts mostly is), but personally, I don't really want to have to write up the validation scheme, the internationalization features, the tag libs that make it easier to work with, and so on. With Struts, it's all there to begin with and it works. Additionally, when I hand over a Struts project to another developer or team, I can just say, "Oh, it's Struts based" and immediately they have access to host of documentation and an entire user community for support. I don't have to sit down and teach them how my special MVC magic works.
I could go on, but I really find using a popular stable project like Struts has a lot of advantages. And yes, Struts is not perfect. There are lot of other good frameworks out there. It just so happens that Struts is very close to how I and my coworkers developed web apps to begin with, so the convertion factor was minimal and the gain was incredible.
Who said Freedom was Fair?
In the eighties? Xerox PARC published a series of books edited/written by Adele Goldberg and others that were supposed to be the definitive description of Smalltalk. IIRC three volumes were published. Checking Amazon, I see "Smalltalk 80: The Interactive Programming Environment," "Smalltalk 80: The Language and its Implementation," not sure about the third.
Well, the fourth was supposed to describe the Model-View-Controller paradigm. IIRC the covers of the earlier volumes listed it as being fourth in the series, but it mysteriously just never appeared.
I heard that it had actually been suppressed by Xerox, which felt it was too proprietary to disclose, or something.
It's a pity, because all the descriptions of MVC I've seen have been sorta loosey-goosey and I've never seen a real technical description of MVC as the Xerox PARC envisioned and implemented it.
Anyone know anything more about this? Was the book ever published?
(Has anything about MVC been patented? THAT could get interesting... It's certainly a lot more worthy of patent protection than a lot of software patents...)
"How to Do Nothing," kids activities, back in print!
WTFever people. From the Velocity (which I prefer to Struts) site:
Velocity is a Java-based template engine. It permits anyone to use the simple yet powerful template language to reference objects defined in Java code.
When Velocity is used for web development, Web designers can work in parallel with Java programmers to develop web sites according to the Model-View-Controller (MVC) model, meaning that web page designers can focus solely on creating a site that looks good, and programmers can focus solely on writing top-notch code. Velocity separates Java code from the web pages, making the web site more maintainable over the long run and providing a viable alternative to Java Server Pages (JSPs) or PHP.
Velocity's capabilities reach well beyond the realm of web sites; for example, it can generate SQL and PostScript and XML (see Anakia for more information on XML transformations) from templates. It can be used either as a standalone utility for generating source code and reports, or as an integrated component of other systems. Velocity also provides template services for the Turbine web application framework. Velocity+Turbine provides a template service that allows web applications to be developed according to a true MVC model.
---------------------
Velocity is dead simple to use, as it is not some kind of entire 'framework' that wants to manage your DB connections, life, etc. It makes using JSP look like masochism. If you really feel like recreating the wheel though, and are convinced that you know better, etc. then feel free to waste your time. I pity the fool who has to maintain your cruft though.
(Would like to be posting more thoroughly on this, but it ain't happening this morning...)
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
If you come from a Swing background, Tapestry is way more intuitive than Struts. You have components in both, and building your gui involves putting components in components, and finally into a frame (Swing) or a page (Tapestry). You don't have to care about how the JTable (Swing) or Table (Tapestry) components are implemented, you just follow the API and use them. I really don't see the similarity between this and JSP or Struts.
I think Tapestry is the only free Java framework out there that actually allows you to really build components rather than pages (as it is in most of the rest). You can build a component to edit the user preferences, for example, and it really does not matter which page or another component you put it in, how you put it in, and what the layout is. It IS Swing for the web.
It also has a lot of other things that are worth using, but for those check the Tapestry home page.
You obviously don't know what struts is.
Struts is a set of server side components for implementing the MVC pattern, that come with some JSP tag libs as a convenience.
Struts can be used with Velocity. Velocity can only replace JSP, not struts.
FWIW, I love velocity as well. I use it in stand alone applications as well as web applications.
I don't have a sig...Do you??
If you're building an enterprise app, however, basing your app on Struts (or any other "web application" technology) isn't a good idea. Why? You wind up mixing your app's functionality with its implementation. Using an MVC framework like Struts alleviates this problem to a great deal, but when it comes down to it you still have a big pile of servlets that does everything from database access to presentation.
That approach isn't scalable, it's not adaptable to different technologies (there's a new webapp framework every week, it seems), it's not easy to integrate with other applications, and so on.
What's really needed is a way to define an application independently of the implementation details. Once you've defined the application, you can generate whatever interfaces it needs - like a Struts UI, an EJB persistence engine, etc. This is where my shameless plug begins: check out the Sandboss project for a way to define your enterprise app without being chained to a particular implementation detail like Struts or EJB.
While the techniques used in Sandboss are designed for the enterprise world, they're useful for web apps, too. I think it makes much more sense to over-engineer an application than it does to under-engineer it; overengineering takes more time up front but saves you 10x as much or more once development starts, since the well-don overengineered solution is more flexible and capable of responding to marketing's feature of the week. By picking Sandboss you get the best of both worlds - a robust framework where someone else has already done the engineering. You just define your app, and bam! Persistence, communication, control, the UI are all done for you.</shameless plug>
Enough of that silly Java stuff.
Get Twisted.
I obviously didn't make any statements about what Struts is. All I said is that I prefer using Velocity. The reason is that I didn't/don't need the additional functionality that Struts offers. Jeez.
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
Struts is but one presentation framework. A discussion comparing Struts and other frameworks is informative, and, indeed, there is an entire website devoted to such a comparison. For Struts links, try the home page of Ted Husted, the lead Struts developer.
A lawyer & digital forensics examiner. Also an expert on open source software (OSS).
That's where MVC comes in. It forces to you think about your implementation instead of blindly charging forward. That's overkill for some projects, but IMHO it's absolutely necessary for others (i.e. any project where more than about 2 people need to touch the code). Otherwise you wind up spending more and more time on maintenance/adding features.
FWIW, Slashdot uses more of the spaghetti pattern than anything else...
How does Struts compare to Apple's WebObjects?
Mike van Lammeren
It will challenge your head, your brain, and your mind.
It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?
This comes up from time to time and I think it's a good question. There was an good discussion about this on the jakarta-general mailing list. It's a long thread, but if you'd like you can start reading at this point. The best part of it I think is this response by Jon Scott Stevens:
Java is not the fastest technology to develop in, however, it produces the best code for the long term.
PHP is the fastest technology to develop in, however, it produces the crappiest code for the long term.
I develop Scarab in Java because it is going to live far longer than I do and needs a solid base to work from.
I develop my bar's website in PHP because I just needed to get the job done quickly and was not concerned with code quality.
Remember, PHP originally stood for Personal Homepage Parser. Java's web application technology was designed from the start to be a solution for a large "enterprise" class web site. You can do more with Java but you definitely take a hit in initial development time. Personally I feel that in the end, Java is easier to maintain and extend (but you may disagree).
By the way, Yahoo! didn't go with Java because of the Java threads implementation on FreeBSD. It didn't have anything to do with the merits of the java language. (See Why not JSP, Servlets, or J2EE?)
Who said Freedom was Fair?
Velocity is still very much alive. Watch the mailing lists for a while if you want to see what's going on.
Who said Freedom was Fair?
Most programmers at least combine the View and Controller--Java supports this rather effectively--and some distinguish between domain and applications models (Visual Proxy pattern).
Perl coders may also be interested in CGI::Application, for a similar MVC approach. I've done a few JSP apps which had a framework similar to Struts (too bad I didn't know about it beforehand), and now I hate to write perl CGI's in the unplanned, ad hoc way I used to do.
> MVC is about projects that work well.
The M is fine, the V I have no problem with. It's the "C". Frankly I haven't seen a decent tutorial treatment of the awful mess that is the "controller". Is it business rules? Is it input events? Is it update events? Is it a mediator? Is it just everything that doesn't seem to fit in the other two categories? Everywhere I look to read up on MVC, I see a lot of handwaving about how it's God's Own Architecture, but aside from basic "duh factor" things like "decouple the view of the data from its underlying representation", I really have yet to see anything that gives a clean design for this mysterious "controller".
Doesn't help that MVC for widget sets has been abandoned for Morphic in Smalltalk, at least the research variant of it that Smalltalk's founders still follow.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Dead tree ver. from publisher: $44.95 +s/h
eBook version from publisher: $22.47
Dead tree ver. from B.A.M. $33.49
Publisher site is here.
Who still uses structs?
Yeah, I sure do. They bolted some syntactic sugar on top of good old structs and now they are called classes instead.
OK, I'm NOT a software engineer. That said...
.NET ones!
How the heck can you keep up with all this dang Java stuff? "You can use Bluelegs to support CowBerries for n-tiered enterprise apps under COW2BITEME from a UML converter."
In the time it has taken me to read up on Application Servers, JSP, J2EE, beans, UML, struts, etc., I could have written about 20 PHP applications...or 20
If Java is so cool, why is Yahoo moving to PHP?
All this structure to build what? Web apps move content from user to DB and back to user, occasionally doing some math in-between.
Then there is stability. 200 blades and a layer 4 switch, I say! Call me when more than 50 blow up.
I know this sounds like a troll, but what is the deal? Haven't there been enough books written?
... to speak for myself, I tend to work in environments where TTM (Time To Market) is crucial, the "team" tends to be me and maybe another engineer, completing the required feature set in the alotted (and fairly short) time span is mandatory, and maintability is placed on the sacrificial altar of needing everything and needing it yesterday.
Elegant design is a wonderful thing and, personally, I prefer to take my time, weigh my options, come up with a design, and attack. However, typically, most of that time I would like to be spending on design is usually better spent building the product and fufilling that feature set.
I can't say that I've spent a lot of time on Struts. I had a go at it on my last job for about six months. Ultimately, given the above constraints, I developed the perspective that for a product that will move through multiple maintainers hands, that will be around for a while, and will have to mature over time, it's wonderful. However, when you need your product written yesterday, Struts will just slow you down with all of the added abstractions that the architecture enforces.
...the soiled nappy of the bastard spawn of Satan.
Sure, the custom tags make your JSPs look sweet. But what a mess underneath. I think it was something like five or six hops from one file to the next for every request, coming back to the main struts-config.xml file at least twice. That file quickly becomes unmanageable in anything other than the Greatest XML Editor Ever (i.e., not JBuilder!), and I spent around half of my time scrolling through thousands of lines of near-identical XML looking for the bit I had to change.
There might come a point at which all this unnecessary complexity actually starts to make life easier - but it'd have to be one huge project.
Saw it, tried it, hated it, ran away.
I bought one of the early Manning PDFs that was reviewed here on /. a couple of years back, good writing and convenient to be able to purchase an inexpensive yet quality piece of writing. Dead tree format is nicer but sometimes you gotta stay under budget while expanding that (virtual) bookshelf.
Bleh!
If you are currently using Struts 1.1, you should consider the upcoming changes to it vis-a-vis Sun's JavaServer Faces specification.
A recent and good introductory article about JSF is A First Look at JavaServer Faces
Craig McClanahan mentioned the transition to using JSP Faces in one of his Struts presentations at the recent ApacheCon and it has been discussed on the Struts mailing lists (e.g. http://www.mail-archive.com/struts-dev@jakarta.apa che.org/msg08457.html
See response to other comments above
11*43+456^2
I'm annoyed that moderators have called me flamebait yet again for a valid opinion, and that the responders assume that I must not know what I'm talking about.
I'm just now going through QA testing on a commercial web application load-tested for 1000's of users, all highly secure, handling sensitive medical transactions. It backends to a complex postgreSQL database tracking user transactions and security audit trails, etc, etc...
It's well beyond a web banking interface or anything as trivial as that (referring to the other reply to parent). And yes, I can read my code after the holidays are over. The only practical consideration is that most of the world's web programmers are Java now, so if we ever sell the source/company nobody will buy it for fear of not finding an adequate person to maintain it perhaps. But as long as it's our company and we can hire replacement Perl programmers, it's all good.
11*43+456^2
Actually online banking shouldn't need to be that complex. Complex = more likely for security problems. Keep it simple. Sure the bank's actual backend could be a mess, but that doesn't mean the online banking webapp has to be. Hmm actually perl is pretty good at gluing messes together. Like with like perhaps ;).
;).
BTW not sure why many banks use tons of javascript here and there on their website, pop up windows, pages that rewrite themselves, etc. That style worries me - almost everytime I see a website doing that, I've found easy to exploit problems.
So far I've found security probs in 2 out of 3 online banking sites I've looked at. The 3rd had so much javascript you could barely see the HTML so I didn't bother - I could use a proxy in between to transalate and send custom data to the site, but nah - not like I'm really trying to exploit things.
Now something like windows update is probably complex (more client side complexity tho) and needs the whizbangs. I couldn't update for a couple of weeks and I thought my Windows installation was broken, then one day the Windows Update website looked different and it worked. Doh. Too bad with Windows you can't synchronise sources and make buildworld, etc...
How big is the plug in? How long to download over 30-50Kbps?
:).
Hmm, this thinlet stuff actually looks thin
I remember a client's contractor trying to do this sort of thing years ago. Regular multimegabyte downloads due to bugs - in both Java and the apps.
I would have said it didn't work, but they seemed to have managed to adjust client expectations. It was for the client's clients tho, so I'm not sure how it really turned out in the end - I was there for the firewalls.
The best explanation of MVC from a "systems" perspective is in Buschmann et al's Pattern Oriented Software Architecture Vol 1: A System of Patterns, which explains "Presentation-Abstraction-Control (PAC)".
The real reason MVC never has been explained the way PARC envisioned it is that no other Smalltalk implementation actually USED pure MVC. Original MVC used to imply that the controller was the code that handled the user input. Eventually this just got embedded into the widgets themselved -- most commercial Smalltalk implementations combined the View and the Controller together.
Now on a larger framework level, the spirit of MVC prevailed but evolved the controller into either a layer of event handlers (the Mediator approach) or a rich declarative binding model (the AspectAdaptor/ApplicationModel approach taken by VisualWorks).
From my perspective, Struts tends to embody the VisualWorks approach pretty well for web applications, with some minor thorny problems intrinsic to web development that haven't really been solved effectively yet: validation, distinction between "client model" and "business object model", and dependencies on the web request-response lifecycle (i.e. scopes of variables are tied to requests or sessions).
-Stu
Only $25k more expensive :D
-Stu
Struts turns web screen flow & actions into potentially reusable state machines. It enables quick validation of forms, tremendous flexbility in how you wish to actually code your application's logic -- in stored procedures, in basic Java procedures, or a fully blown object model.
:D
The popularity of Struts can be attributed to many things
- It's what most projects would write themselves anyway
- The source code is extremely clean.
- It is very simple
- It really helps speed maintenance
For me, Struts is the first embodiment of the potential exhibited by Apple's WebObjects Framework. Struts still has a ways to go to get there, but it's getting there fast. Combined with an object/relational framework, we may finally have in 2003 what WebObjects offered in 1996
ASP.NET also exhibits a lot of this potential, and IMHO you can't hope for J2EE to compete with the productivity of ASP.NET without an MVC framework like Struts. I really hope Sun realizes this, fast. JavaServer Faces is long, long over due. And if ADO.NET ObjectSpaces gets released, the Sun may have to stop treating JDO as a second class citzen, fast.
-Stu
Interesting. I don't have any experience with Python, but having used many, many other platforms over the years, I know how much one's opinion about a tool can change after a year or so of intense effort. I'm always interested to hear from those who have gone through it, especially when the whole team eventually reached the same conclusion (as usually happens, in my experience).
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
That article was woeful
"Get and set are evil"
Set should always perform validity checking but is a mirror of the real world.
Take a watch, you "get the time" from the watch and are able to "set the time" of the watch. The watch then tracks the time. Some of the comments are fine, some are indicative of someone who thinks they _really_ know OO but in fact just hasn't thought it over properly.
Unguarded sets are bad, but gets are standard object functions in the real-world. You "get the speed" from your dashboard, you don't "set" the speed on the dashboard you press the peddle, which has the resultant effect.
An Eye for an Eye will make the whole world blind - Gandhi