anti-patterns

Do you think it is ok to use error codes within exception to specify error type? Please take a look on this code: public class MyException extends Exception { public static final String ERROR_CODE_INVALID_NAME = ""; public static final String ERROR_CODE_INVALID_ID = ""; ... private String errorCode; public MyException(String message, String errorCode) { super(message); this.errorCode = errorCode; } public String getErrorCode() { return errorCode; } } I know that it is better to use enum instead of Strings in this example, but I'm actually concerned about the concept of error codes. Do you

I am currently working for a client who are petrified of changing lousy un-testable and un-maintainable code because of "performance reasons". It is clear that there are many misconceptions running rife and reasons are not understood, but merely followed with blind faith. One such anti-pattern I have come across is the need to mark as many classes as possible as sealed internal ... *RE-Edit: I see marking everything as sealed internal (in C#) as a premature optimisation.* I am wondering what are some of the other performance anti-patterns people may be aware of or come across? The biggest

I'm trying to figure out if my usage of passing Akka ActorRef around to other actors is not an anti-pattern. I've a few actors in my system. Some are long lived ( restClientRouter , publisher ) and some die after that they have done the work ( geoActor ). The short-lived actors need to send messages to the long-lived actors and therefore need their ActorRef s. //router for a bunch of other actors val restClientRouter = createRouter(context.system) //publishers messages to an output message queue val publisher: ActorRef = context.actorOf(Props(new PublisherActor(host, channel)), name = "pub

Closed . This question needs to be more focused. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it focuses on one problem only by editing this post . There has been talk of Enums in general violating Clean Code-principles, so I'm looking for people's favorite Enum anti-patterns and alternative solutions for these. For example I've seen code like this: switch(enumValue) { case myEnum.Value1: // ... break; case myEnum.Value2: // ... break; } It's one step better than switch-statements with magic strings, but this probably could have been

I'm trying to explain to my team why this is bad practice, and am looking for an anti-pattern reference to help in my explanation. This is a very large enterprise app, so here's a simple example to illustrate what was implemented: public void ControlStuff() { var listOfThings = LoadThings(); var listOfThingsThatSupportX = new string[] {"ThingA","ThingB", "ThingC"}; foreach (var thing in listOfThings) { if(listOfThingsThatSupportX.Contains(thing.Name)) { DoSomething(); } } } I'm suggesting that we add a property to the 'Things' base class to tell us if it supports X, since the Thing subclass

In my never ending quest to do things the "proper" angular way, I have been reading a lot about how to have controllers observe the changes in models held in angular services. Some sites say using a $watch on a controller is categorically wrong: DON'T use $watch in a controller. It's hard to test and completely unnecessary in almost every case. Use a method on the scope to update the value(s) the watch was changing instead. Others seem fine with it as long as you clean up after yourself: The $watch function itself returns a function which will unbind the $watch when called. So, when the $watch

Martin Fowler considers Anemic Domain Model as an anti-pattern. Rolling the Persistence Model as the Domain Model seems severely off too due to Object Relational Impedence Missmatch . For persistence and normalization sakes, we tend to break down classes to very small tiny pieces, slapping methods on top of these classes is silly. Plus persistence rarely changes, but business logic changes a fair bit. So we need a DomainModel that builds on the persistence model (instead of being one and the same). This Domain Model will then contains business logic properties and method. But now these Domain

A typical problem in OO programming is the diamond problem. I have parent class A with two sub-classes B and C. A has an abstract method, B and C implement it. Now I have a sub-class D, that inherits of B and C. The diamond problem is now, what implementation shall D use, the one of B or the one of C? People claim Java knows no diamond problem. I can only have multiple inheritance with interfaces and since they have no implementation, I have no diamond problem. Is this really true? I don't think so. See below: [removed vehicle example] Is a diamond problem always the cause of bad class design

I'm working in a web app framework, and part of it consists of a number of services, all implemented as singletons. They all extend a Service class, where the singleton behaviour is implemented, looking something like this: class Service { protected static $instance; public function Service() { if (isset(self::$instance)) { throw new Exception('Please use Service::getInstance.'); } } public static function &getInstance() { if (empty(self::$instance)) { self::$instance = new self(); } return self::$instance; } } Now, if I have a class called FileService implemented like this: class FileService

I've seen many times Zend Framework using return $this; pattern style - and from my point of view: Pro: seems its quite not bad pattern style for chaining many actions on the same object and making your code shorter. Con: code looks a bit weird when you see that object returns itself in the method, which does something else (e.g. setter for some property) Is it really good pattern practice or maybe an anti- pattern practice? EDIT: well it was a little too much from my side to call it "pattern", thanks everyone for pointing me to right direction! Returning this allows you to chain calls and set