What is the difference between aggregation and composition?

This question has bothered me for some time and I always forget. So I wrote it down here and added an answer.

Composition : An object contains another object. When the container object dies, so does the composited objects.

Aggregation : An object pseudo-contains another object (contains a pointer to it). When the container object dies, the containees do not.

Sometimes aggregation is called composition when the difference doesn’t matter.
Note: In UML, aggregation is an unfilled diamond, whereas composition is a filled diamond.

References:
http://en.wikipedia.org/wiki/Object_composition#Aggregation

Things you can do to make your code better

I got most of this list from some other place on the internet, but I felt there could be more added to it.
I’ll continue to add to this list as I think of things or come across things.

  1. Test Driven Development Really Is Worth It
  2. Don’t Rely On Comments Too Much: Make Your Code Self-Explanatory
  3. Don’t Let Exceptions Disappear Into A Black Hole
  4. Don’t reinvent the wheel. Use libraries when possible because you know they work.
  5. Code like you will reuse the code for other projects.
  6. Learn what good design should look like an emulate it until you see why it is good design (and what you dislike about it).
  7. Too many newbies like to over-engineer just to pretend to be smart or having fun with resume-driven-development. In other words, implementing every pattern in the book or putting bayesian filters in every corner of the code should be avoided if they aren’t needed. Debugging, testing, maintenance will be all easier, not mentioning performance.
  8. Have your code reviewed often.
  9. Be wary of code smells (Class too big, method too big, method with too many arguments, Ask don’t Tell etc).
  10. Enforce standards by using checkstyle / PMD, cobertura / emma, findbugs, etc within maven build cycle to make sure code in repository is adhering to a certain quality standard.
  11. Make sure it meets the quality standard for the project.
  12. Just keep it simple. Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80×24, as we all know), and do one thing and do that well.
  13. Test, test, test.
  14. You will see how many times you will have to tradeoff between design and schedule. Forgive yourself but remember to refactor whenever possible.
  15. Use Standard Annotation Language (SAL) if you are using C or C++, to prevent bugs and make your code robust. It is found in the book “Writing Secure Code for Windows Vista.”
  16. Code with contracts (partially enforced with SAL).
  1. Avoid global mutable state, such as static variables and static singletons.
http://misko.hevery.com/2008/11/11/clean-code-talks-dependency-injection/
http://misko.hevery.com/2008/11/21/clean-code-talks-global-state-and-singletons/
  1. Make your methods small and well named.
http://c2.com/ppr/wiki/WikiPagesAboutRefactoring/ComposedMethod.html
http://tottinge.blogsome.com/meaningfulnames/
  1. Simple Design
http://jamesshore.com/Agile-Book/simple_design.html
  1. Adhere to SOLID Principles
http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Misc Useful Links

These are miscellaneous useful links that don’t really fit into any of the other categories I have.

Essential Mathematics Book Website
Gallery of Processor Cache Effects
Easy Git
IEEE-754 Floating Point References

Programmer Fonts
Design Patterns