As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I like reading open-source code to see how particular problems have been solved, or simply to study how to create nice and clean code.
I was wondering if there actually was any good book out there that goes through excerpts of different (preferably in Java) open-source projects to show how patterns have been used and implemented, some nifty tricks, etc.?
Update: I took design patterns as an example, but it’s not really what I am after. I read a lot of open-source code, and I often find interesting ways of doing things which I didn’t think of before – my question is whether there is a book that shows some “cool” open-source code, a bit like how Clean Code uses FitNesse code to illustrate refactoring and other points.
Well, you can read just book about open source project, and authors can show what and how. E.g. I read Pro Spring 2.5 and there is even chapter called "Spring Patterns" with explanation of why and how they call files, directories, design patterns they use and invite you to use etc. Probably take a look at the books about open source projects you investigate.
UPDATE (just that paragraph insert to extend answer:) : as I told previously, you can look through the books about open source projects and find there information how this project is developed, architectural issues etc. Once I looked for real good example of "Open/Closed Principle" using, theory is nice but I would not say that it is so clear how to use it. The only book which helped me was Expert Spring MVC and Web Flow (I already pointed you to google books with that chapter I read). I didn't read the whole book, but I am sure it contains a lot of such things (what and how was used to make Spring done). From book Clean Code: A Handbook of Agile Software Craftsmanship I remember that there is a chapter, when they take a code from one open source project and make it better (unfortunately open source does not mean that it is good enough); that book also contain reference to how some other projects where written (e.g. jUnit). I don't know any book, which is completely dedicated to any project, there are just books where is "theory", and books about project which can have some explanation of what is inside. I would recommend books from APress (Pro and Expert series, afaik "beginning" books does not contain such explanation), and Packt Publishing - their main topic is open source.
UPDATE 2 (just can't stop :) Just remembered new series of books from OReilly "Beautiful ...." - I never read it, but I looked through. It actually consists of different stories behind development, real stories from life. I see there is also Beautiful Code: Leading Programmers Explain How They Think - I should contain what you need. Other "beautiful" books can be worth of your time too.
About patterns in general there are a lot of good books, and it depends on what exactly are you looking for. E.g. Head First Design Patterns is quite good to explain common patterns in fun way. If you need more, you can take a look at Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions to see how different applications, systems etc. can be integrated (and how open source projects do it too). Etc. Just specify what patterns or tricks do you want to read about, community will make its suggestion ;)
Some web links out of my bookmarks:
Anti Patterns Catalog - know what you are not going to do!
Design Patterns and Martin Fowler's Catalog - that's shortly about what is good to use and know about
SOA patterns - community site for SOA patterns (integration etc.)
And few more books to take a look at:
Head First Object-Oriented Analysis and Design
Agile Software Development, Principles, Patterns, and Practices
Code Complete - this book is just a bible of how to write code...
people, who develop open source definitely know what are those books about ;)
Hope that helps
UPDATE (25-05-2011) Just found one book, which I definitely going to buy, and I think it perfectly fits your question:
The Architecture of Open Source Applications
Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well — usually programs they wrote themselves — and never study the great programs of history. As a result, they repeat one another’s mistakes rather than building on one another’s successes. This book’s goal is to change that. In it, the authors of twenty-five open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to this book provide unique insights into how they think. Electronic versions of The Architecture of Open Source Applications for e-readers will be available for download soon.
Good question. But I doubt if there is a book based on a real project.
But to answer your "nice and clean" part, Josh Bloch's Effective Java is the right book.
I'm not sure if there's any Java examples (I own the books, but didn't bring them to school), but if you are looking for general advice on how to read code and assess its quality, you might be interested in Code Reading and Code Quality by Spinellis. Based on your question, I would suspect that Code Reading is more along the lines of what you want - it looks at how you can read unfamiliar code effectively before editing it, comprehending complex code, and so on.
Not a book, but might be helpful.
http://www.java2s.com/Code/Java/Design-Pattern/CatalogDesign-Pattern.htm
Best Java book out there is absolutely Head First Java, I have never seen/read a book as funny as this + it explains difficult things in the simplest and funniest form. But this book is a bit old, but I think it's okay if you're learning the basics of Java
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've googled a lot and can't find what I look for.
I look for some architecture practice. I mean there are a lot of books about Design Patterns, but I want something like analysis of common mistakes in architecture of EE applications. All I've found - antipatterns like string concatenation or something else that can be found with help of FindBug or Sonar.
How I figure it out:
Book with next steps: task definition, wrong decision, why it is bad, right decision.
Educational resources. I heard there are such resources for testers. Some applications are opened for testing and each who want to learn testing can test it; and after some period discuss own result with other people or see the percent of bugs he has found.
Maybe other ideas?
Why I think Design Pattern books are not suitable for me:
A developer may know many design patterns from such books, but can be incapable of selecting the correct one for the specific situation. IMHO, this is because these books don't give you any practice, and fail to educate the reader as to which design pattern(s) should be applied to any situation. Those books just get you a ready solution.
EDIT:
There aren't any answers any more. So I want to expand my question:
I believe, no I'm certain that exist courses dedicated to improve architecture skills, show the common mistakes in designing of web applications and so on. Also I know that there are a lot of conferences linked with this subject.
Advice me where should I look for them, please.
Holub on Patterns is a fresh and interesting perspective on design patterns.
Lots of code. Lots of pro and cons, very hands-on and practical. I learn something new every time I re-read it.
It has been my go-to book as the "next step after GoF and Head-First Design Patterns". I love it, and it has been very well recieved by the ones who have tried it.
Can I assume that you know how to create independent objects using Dependency Injection? If not, this would be an excellent are in which to cultivate reuse and create a more robust architecture. Using DI would be an excellent way to re-architect an existing solution. (Contrast that with much evolved code, which becomes brittle because of interdependency.)
While you're not looking toward Design Pattern books, I'd ask you to glance at Refactoring to Patterns by J. Kerievsky.
Kerievsky takes you through some real-life refactorings which have titles like "Move Creation Knowledge to Factory." (It's "real-life" in that he uses actual code, not a contrived example.)
Finally, I have been encouraged in our recent use of Spring Integration as an Enterprise Integration Pattern. If you architect and implement even a modest project in Spring Integration, you'll get quite a lot of experience with both DI and EIP.
If you're writing enterprise applications, I'd recommend Patterns of of Enterprise Application Architecture when you're done with the basic design patterns.
It was written about ten years ago and some of the more modern things about how to shard tons of big data across cheap servers you will not find in there. The cloud did not exist when it was written. But it seriously discusses a lot of things that you won't find discussed elsewhere, and coins names / patterns for elemental building blocks of applications. I'd call it a classic rather than old.
See http://www.martinfowler.com/eaaCatalog/ for an index of the patterns that are discussed.
In my experience, the role of an architect is defined differently for different companies and often has less to do with code structure and patterns and more to do with your business requirements and practices. Employers seem to be more interested in what systems you might integrate into your solution or how you expect to interact with varous customers under conditions imposed by your company.
Correctly using a DI framework or design patern is something ever programmer should be able to without specific guidence from an architect, but researching and choosing which DI framework to use that might best fit your task is something an Architect might do.
They also tend to do more advanced impelementations--One of the better architects I worked with implemented the more difficult parts of our system, he wrote a custom Java classloader that loaded classes from a database and designed how it interacted with a GUI builder he designed so our customers could edit a GUI with Drag and Drop and we would save a .class file into the DB so it could instantly be loaded by all the client machines hooked to that server.
Some companies have different definitions than others--a company I worked with that did set-top cable box software had some architects that hardly programmed or had anything to do with software design, they were responsible for things like decomposing communication protocols and interacting with customers to help understand their problems (I viewed this more as Analyst work than Architect, but it was much more technical than most Analyst work I've encountered)
I guess I'm saying that an awful lot depends on the company you are working with. I suggest you go to your manager (or an existing Architect) and tell him you are interested in such a path and ask how you should progress.
When asked pretty much this question, one of the Architects I've worked with said that it's something you are always working at--you don't study up and finish, keeping up to date all the time on as much as you can is your new job--Where others might read a book or play a video game, you should be reading articles about software design, installing and playing with new software languages/tools/libraries and learning more about the specifics of your business.
In my views what I think going through the Class Diagrams of the Design pattern will help you a lot.
What more i will suggest is to take a brief of the Book "Head First Design Patterns". As per my experience this book has some very good example related to every Patterns which will help you in the pattern selection.
As per the selection of Design Pattern is concerned you can develop it by implementing more and more pattern in different scenario.
Take a look at Adam Bien's book
Real world java EE 6 Patterns
You can download an introduction based on this book at java.net
Real world java EE Patterns (pdf)
The first step is learning general good practices for developing applications. Knowing design patterns is very useful as it is a type of a language, so if you call something a "Controller" or "Request/Response" that automatically tells other developers the patterns you are applying and how to use it/work with it. Also, large software is typically built using them, so you have to know design patterns. Doesn't mean you need to squeeze every single one into every application, just saves you the trouble of solving problems others have already solved. As far as best practices at code level, Sonar is a good code analysis tool that taught me tons of do's and don't's.
Second, you need to narrow down the context and determine what types of applications are you planning on architecting. For example, web applications have different architecture from embedded applications, if you specialize in one you don't necessarily need to know all the ins and outs of the other.
Third, read up on Enterprise Integration Patterns.
Fourth, do hands on work with Apache Camel. It's a Java enterprise integration framework, great documentation and really easy to get up and running.
To me design patterns look like solutions to isolated problems. In real practice we have to deal with combinations of problems, which are highly dependent. I have never seen any pattern used purely. I can recommend one book which gives a wider view of software architecture: Domain-Driven Design: Tackling Complexity in the Heart of Software. It says how to approach to software design, instead of giving a set of common tools. With some examples it explains how to solve a set of problems in combination.
One more book gives an explanation on how to design classes and their collaboration: Interface Oriented Design: With Patterns. To write good understandable and maintainable code. It explains a lower level approaches rather then DDD.
My two cents :)
I agree with your observation that simply learning design pattern is of little consequence. A typical thing which generally occurs after learning design patterns is that the developer tries to map the a ready made solution (pattern) to a problem which is not the right way and will create more problems than what it solves.
IMHO, being an architect is more a matter of experience than academics. An architect is at core a Problem Solver or Solution Provider. By problems, I mean the large scale design problem and not the day today programming problems.
The problems could be from whether to use OR mapping tool or not to larger and more profound problems like whether to go for SOA or not and likewise. Its not about WHAT to do but HOW to do.
These things are a matter of experience. A problem can be solved by thousand different ways but while designing a system, due consideration should given to technical feasibility, performance, scalability, deployment, maintenance, extensiblility and many such non-functional requirements. Now unless you have been-there-done-that, its difficult get hold of these things which are very vital for today's software system .
Nobody can deny the importance of books(apologies for not introducing to new books as people here have already suggested wonderful books). They are written by very intelligent, sharp and most important experienced, people. I view this as a way of sharing once's experience and view point and they help you in chalking your path.
Apart from books, the other very important way to understand or learn about system design is ability to dissect the existing systems. For example, you might want to explore how a typical web server like Tomcat works or a DI framework like Spring works. Open source makes these things possible.
The best single way to be a great software architect, developer, or programmer is to work.
Get the basics down, and then work on something - especially something you are interested in. Hard work will pay dividends in the form of experience.
Surround yourself with people smarter than you, and listen to what they have to say. Trust that their experiences can help lead you into a better understanding.
Wisdom is not something that can be bought with a $50 book, or even a $100K college degree. Software craftmanship is something that you must earn.
If you have free time, working on a popular and successful open source project will help you gain great experience.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
so I have been through all the courses on programming, algorithms, etc. and did a lot of coding and some small projects.
Now, I may start working on a real project, real java SE program with gui and everything, not big, but much more complicated than average school project. My experience says that when I'm having more classes in my project (say 10), it kind of gets difficult to decide from where this constructor should be called, if I should pass this parameter here or create it later and how the whole thing should work together.
can you recommend me some resources on this? Should I go the way of studying the design patterns or how do I get to design apps that have nice architecture?
what is the procedure when developing an app with lots of classes and gui and so on?
thanks a lot
Design patterns usually help in making an application more maintainable and also more flexible. Although which design patterns to use relies essentially on what type of problem you have.
I did go through this book, which provided me with a quick and easy way to grasp what design patterns are and how they work.
Since you are dealing with GUI related applications, my only recommendation would be to try and make your GUI and Logic seperate. This should reduce clutter and should make your code more understandable since each class deals with items related to its layer (GIU or Logic).
Breaking things down also makes your application more flexible and reusable. Cohesion vs Coupling should also be another thing which you should keep in mind.
For design patterns : Head First Design Patterns & Design Patterns: Elements-Reusable-Object-Oriented
For Effective Programming Guidelines : Recommended reading Joshua Bloch's Effective Java
I personally like to thing in a TDD approach and love to read this blog Writing Testable Code by Misko Hevery.
It explains how should we focus on making code loosely coupled and testable.
And lastly keep exploring open source libraries and projects they will keep you up to date with latest trends and coding styles.
Head first Design Patterns or even the original Design patterns book from the Gang of Four (if you are the kind of person who likes more direct theory) for application design and I think it may be useful for you to have some knowledge of enterprise design patterns (Enterprise Integration Patterns from Hohpe and Wolf) will help you to understand how to implement flexible communication even in small SE projects. (Even these systems needs sometimes some kind of interprocess communication).
Additionally, the answers of Narendra and npinti are very good advices as well.
Have fun!
I have a student working on his high school senior thesis. He is interested in the history of programming languages, specifically Java, and he's looking for resources detailing that history. He's looking to answer these kinds of questions:
Why was Java created? What problems was it meant to address?
Did it successfully address those problems? How so/why not?
Whether or not it addressed the problems it was designed to solve, why did Java become so popular?
What problems, if any, did Java create? What are its shortcomings and/or deficiencies?
Where and in what contexts is Java still relevant?
Where has it lost its relevancy? Why, and to what?
By the (admittedly arcane) school rules of writing one's senior thesis, he is allowed at most two web-based resources, and he must have at least five resources total (so at least three must be printed-on-paper resources, whether they be books or journal articles). Any recommendations?
Please do not hesitate to recommend online resources, especially since well-written sources can often help point the way towards the next avenue of exploration. But we're having the most trouble trying to find printed resources, so any help along these lines would be most appreciated.
To be clear, I'm not asking here for answers to these questions (sadly, my school does not consider SO to be a valid resource), and I'm decidedly not asking "Why is Java awesome/terrible?". I'm looking for resources I can point my student to so that he can do some research that the school will recognize as valid.
Thanks in advance for any and all help.
I don't know if you've already tried this but wikipediaspiece of the history of java would be a good starting point.
The HOPL conference produced
proceedings with papers from a bunch
of really top guys, but unfortunatly
none of the three editions contain
any history on Java. However, the
articles may still be of great use,
as they provide a lot of insight
into competing languages, which may
help your student understand why
Java is where it's at today.
The first chapter of Programming
Languages - Principles and
Paradigms consists of a very
nice time line describing the
evolution of the different languages
and paradigms. This book is very
easy to read and comprehend, so it
might be a very good starting point.
Although I've not read The History of
Programming Languages myself,
I know the authors of it, Bergin and Gibson, are both
really good, so that might also be
something of interest to your
student.
For a nice overview, even if probably won't work in a reference list, I would recommend checking this little article out.
Finally, I want to recommend this article, mainly because it's both light and brief, but still to the point and comprehensive. It's probably also a good place to mine for references, which is always a good thing to learn how to do.
Good luck to you and your student!
Rod Johnson in his Java: Expert One-on-One J2EE Design And Development, despite hasn't archeological intentions, addressed some relevant issues on the language itself. He contrast it with .NET and stored procedures paradigms. But, I repeat, is a Java Developer book...
In addition, here is a java timeline
And the java's father, James Gosling, blog
Here's one place to start:
http://ei.cs.vt.edu/book/chap1/java_hist.html
One point to consider - some people make the distinction between Java as-a-platform (i.e., the JVM) and Java as-a-language. Your student might find some divergent perspectives answering the questions from those different angles.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
So I apologize if I'm posting this in the wrong place but I thought asking the coding crowd would be best.
So I'm building a website with 3 developers. One dev is on front-end, one on PHP back-end and one on the database design. The core application of the website is actually much more complicated than i/we (the devs here) originally imagined it would be. The hardest part is in the database design and the design and development of the CMS to manage the database. Working closely with one dev, we have created the final version of the database. This is good news. Meanwhile, the rest of the site is being built with Zend with the other 2 developers.
Essentially what has happened is that the database designer that I have been working with has all the knowledge in his head because he worked with me consistently to design the DB by learning about the technicalities of the domain, industry terminology, the system requirements and so forth. He has also designed the CMS to manage the products that we will insert as per his data structure. Logically, he should really be the one then to code the core application because he knows deeply what he designed. However our system is in PHP and he's a Java dev. So I'm pondering what do to. He has agreed that he could learn PHP in about 2-3 weeks he estimated but admits that at the start, coding would be quite slow while he falls over a few times.
The lead developer on the other hand knows little about the requirements of the core app, the design of the database, the products and the business domain and would therefore take a long time to go through the same process of transferring all this knowledge until he's intimately familiar with everything. So its really a question of time. Would it be faster for a 6 year Java dev to learn PHP and build the core app or would it be faster for the 6 year PHP dev to pick up the knowledge from myself and the database dev?
Is it a close call? Is there a clear winner?
Any advice/suggestions?
Thanks
In essence I think that having experience of design and a good knowledge of how systems work is the most important thing.
Individual languages can be learned (and yes, there is a learning curve, while the syntax is absorbed, then the idioms, etc) and whilst having someone who knows a language when they start makes them a little quicker off the mark, I would choose someone with good design skills over someone with weaker design, but more knowledge of the language.
Language skills can be learned much more quickly than design principles.
In your situation, you have a problem. Two good people with different skillsets. Surely the ideal solution (if it's financially viable) is to have them work as team. Then both will learn much more quickly from the other where they are weak - and they'll be able to discuss design issues and rational. You should end up with a vastly superior product, and two developers whith enhanced skillsets and expanded experience. A win-win, if they can work well togther.
I agree with #Ragster - get the database guy and the UI guy to work together. There's even a buzzword for this - it is called pair programming.
But I'd add one thing. It sounds like a significant part of the problem is that the database guy has all of the knowledge in his head ... and there is nothing written down. This is not good. What happens if the database guy is run over by a green bus?
Maybe you need to make the database guy's number one priority to document the database design in a form that the UI guy can assimilate.
I would vote for using the experienced PHP dev rather than one new to PHP. Any experienced PHP dev should be able to take a brief from you and your colleague on what is needed and utilise the db design work already done.
A dev new to PHP will not produce code that is as well written as an experienced dev and that could cause you problems in the future.
The other solution would be to use Java for this application even if some of your other apps are PHP based. The two can live pretty well side by side.
I'd vote for the PHP-dev, working alongside the database/java dev.
That way, the database/java dev begins to get exposure to PHP, which will help his learning curve; while the PHP-dev will pick up the database structure and the all-important business rationale/details from the database/java dev.
You shouldn't create a dependency on any one person if you can help it, but distribute the application knowledge across your team. This way, you'll end up with a stronger team overall.
You should also ensure that the knowledge isn't maintained purely in anybodys head, but is documented. Always consider the dangers of a number 17 bus when all the knowledge is in somebody's head.
The nature of your question implies that you expect your programmers to develop in single-user mode throughout. I have honestly never met a situation where that was less appropriate than for you right now. Allow/instruct the obvious candidates to use pair programming, and the problem will simply dissolve into thin air. You will get better understanding within the team, faster results, better code, more unified solutions all around...
I am not being flippant here. If you have any historical or even ideological aversions to pair programming, please please please try to just get over them. It just is that much more efficient.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
One of the major challenges for any java developer is try to keep in pace of development of the language and new tools. Java is evolving all the time and it happens often that I hear from a friend or colleague about some useful tool I had never heard of before.
I'd love to hear about how people find out when new java specs come out or an interesting, new tool is released? For example, what java blogs do you follow?
Listen to the Java Posse podcast. It is fun, it is relevant and gives a great feel of the Java (and wider JVM) community. It also has sections on Scala, Groovy, Android and (from time to time) Clojure.
Look for it on iTunes or your other podcatcher of choice.
Keep reading questions and answers on Stackoverflow. You'll learn something new almost daily.
Another blog I can recommend: http://infoq.com/
In general blogs and twitter are very good, if you come across a good coder or project, start following his/it's blog or twitter. To get you started, here's whom I follow on twitter for computer related stuff
I tend to browse directories like http://java-source.net/ and http://www.manageability.org/blog/java regularly.
Finally, I follow RSS feeds of http://freshmeat.net/tags/java-libraries and http://freshmeat.net/tags/java
HTH
http://www.theserverside.com/ has daily updates on new java/j2ee tools, resources and useful features/tutorials once in a while. That and SO are my daily visits.
and on a lighter note - http://thedailywtf.com/ :)
Attend your local JUG meetings.
Find your group here:
http://java.net/jugs-list
I follow articles on Dzone.
I find IBM developerWorks specifically the Java zone a good place to keep up with Java and the broader developerWorks site useful in keeping up with IBM related technologies.
my favorites :
Dzone Refcardz
java specialists
i hope these can help you , i got a lot from them
javablogs.com is quite helpful. It's some kind of blogs aggregator, 'blog community' for blogs which discuss Java technology regularly
Yes, you should follow blogs. Search for Java blog feeds with for example Google Reader, and add them. Then you'll get the latest news in one place.
I follow In Relation To actively. It contains the blogs from JBOSS employees. Following Oracle blogs makes also sense.
To keep updated your self with new technologies or tools, you can subscribe to RSS feed.
Can subscribe to any tool new letters, google news. Follow some bolgs. Use google reader.
you can participate in any mail group. This will keep you updated.
JavaOne is a great conference if your employer will spring for it (it's rather expensive, esp. if you're not already located on the west coast). It has a good mix of practical and higher-level, five-years-in-the-future stuff. It helps me to have a solid block of time away from the details of work, so I can focus just on exploring new technologies and ideas.
They're also planning some worldwide JavaOnes in places like India this year.
Coolest single bit of technology I found out about there: http://www.lambdacs.com/debugger/
A bit ancient, not network based:
spend time (have lunch) with fellow workers, speak about your duties, his problems, any hidden features of the used programming language you/he came across (from SO maybe), about the best IDE, ..., new games (ups, not working the whole time :-) )