Anti patterns

The sacrifice object pattern - a way of turning anti patterns into a pattern

While working with legacy applications and inherently dirty code you have to find creative ways to make things better. Rewriting / major re-factoring are usually not an option as team does not get enough time to do even basic housekeeping, what do you do then?

I have seen sphagetti code way too many times in my life not to call it an anti pattern. One of the main reasons for sphagetti code is allowing any object in the codebase to talk to any other object. In addition it comes hand in hand with usage of global/static scope and leaking information between application layers.

I recently realised that i have been applying the same pattern for a while now. The pattern i propose is an effort to cluster ugliness and relief rest of the code-base from exploding dependencies.

Why are setters and getters bad for Object Oriented design

I have had this discussion like a dozen times already so I thought I could write it all down.

In many cases it is not that big deal. The problem is that people seem to be blind and ignore the fact that accessors can cause design issues. Its more about principles and overall rules. You wont get swine flu and die if you keep on using getters and setters. So don't panic! But your code may be cooler and more coherent if you stop for a minute and consider should they be there.

Syndicate content

About the author

Artur Ejsmont

Hi, my name is Artur Ejsmont,
welcome to my blog. I am a passionate software engineer living in Sydney and working for Yahoo!

Web Scalability for Startup Engineers

If you are into technology, you can order my book Web Scalability for Startup Engineers on Amazon. I would love to hear what are your thoughts so please feel free to drop me a line or leave a comment.

Follow my RSS