anti-patterns

Does anyone know the best way to refactor a God-object? Its not as simple as breaking it into a number of smaller classes, because there is a high method coupling. If I pull out one method, i usually end up pulling every other method out. It's like Jenga. You will need patience and a steady hand, otherwise you have to recreate everything from scratch. Which is not bad, per se - sometimes one needs to throw away code. Other advice: Think before pulling out methods: on what data does this method operate? What responsibility does it have? Try to maintain the interface of the god class at first

I'm a bit confused about how to best refactor my code into something more readable. Consider this piece of code: var foo = getfoo(); if(foo!=null) { var bar = getbar(foo); if(bar!=null) { var moo = getmoo(bar); if(moo!=null) { var cow = getcow(moo); ... } } } return; As you can see, lots of nested if blocks, needed because each nested if is dependent on the previous values. Now I was wondering how to make my code a bit cleaner in this regard. Some options I have thought of myself would be to: return after each if clause, meaning I'd have multiple places where I leave my method throw

This question relates to behaviour of old Java versions and old implementations of the double checked locking algorithm Newer implementations use volatile and rely on slightly changed volatile semantics, so they are not broken. It's stated that fields assignment is always atomic except for fields of long or double. But, when I read an explaination of why double-check locking is broken, it's said that the problem is in assignment operation: // Broken multithreaded version // "Double-Checked Locking" idiom class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null)

I have two parallel inheritance chains: Vehicle <- Car <- Truck <- etc. VehicleXMLFormatter <- CarXMLFormatter <- TruckXMLFormatter <- etc. My experience has been that parallel inheritance hierarchies can become a maintenance headache as they grow. i.e. NOT adding toXML(), toSoap(), toYAML() methods to my principal classes. How do I avoid a parallel inheritance hierarchy without breaking the concept of separation of concerns? I am thinking of using the Visitor pattern. public class Car : Vehicle { public void Accept( IVehicleFormatter v ) { v.Visit (this); } } public class Truck : Vehicle {

A lot of people seem to agree, that the Singleton pattern has a number of drawbacks and some even suggest avoiding the pattern entirely. There's an excellent discussion here . Please direct any comments about the Singleton pattern to that question. My question : Are there other design patterns, that should be avoided or used with great care? Spoike Patterns are complex All design patterns should be used with care. In my opinion you should refactor towards patterns when there is a valid reason to do so instead of implementing a pattern right away. The general problem with using patterns is that

What is the most evil or dangerous code fragment you have ever seen in a production environment at a company? I've never encountered production code that I would consider to be deliberately malicious and evil, so I'm quite curious to see what others have found. The most dangerous code I have ever seen was a stored procedure two linked-servers away from our core production database server. The stored procedure accepted any NVARCHAR(8000) parameter and executed the parameter on the target production server via an double-jump sp_executeSQL command. That is to say, the sp_executeSQL command

My question is a bit regards concept. A lot of times there is this such situation: if(something){ someAsyncAction(); }else{ someSyncAction(); } // Continue with the rest of code.. var a = 5; The problem with this such case is clear, i don't want the var a = 5 to be call unless someAsyncAction() or someSyncAction() will done, now, cause soAsyncAction() is asynchronous the only way (i can think of) to solve this situation is something like that: var after = function(){ // Continue with the rest of code.. var a = 5; } if(something){ someAsyncAction(after); }else{ someSyncAction(); after (); } BUT