Tag Info

Hot answers tagged

26

For methods of a class which are solely for testing purposes, I have seen the name maintenance hatch in the past. And similar to real maintenance hatches in physical machines, those methods sometimes have their purpose. For example, if you are going to make some legacy code testable when it has grown too big after some years of evolving, maintenance hatches ...


16

It was added purely to test this class, and will make its way into production code. This is shortsighted... Having a constructor to pass in dependencies isn't done just to test the class. It's done to make your class flexible. The parameterless constructor that has a hard dependency on a concrete Something is more of the anti-pattern due to the tight ...


12

It's called "production code included for the sole purpose of facilitating testing." If you're using it a lot, I'd say it's an anti-pattern. The way you mitigate it is to write your classes using dependencies which conform to an Interface and are supplied using Dependency Injection, and then use stubs and mocks to isolate the class for testing. But the ...


12

When you encounter exceptions within the logger itself, you shouldn't use the logger to log its own exceptions. The reason for that is that: You may be stuck in an infinite loop. Imagine that within your logger, you have a conditional branch which wasn't tested (and generates an exception). Imagine that once the condition is met, any further reported ...


9

A DAO class usually has the CRUD operations like save, update, and delete. Whereas the DTO is just an object that holds data. So there is actually a difference between those two. The term then depends on what the object does. A VO and DTO used to be synonyms: early Java EE literature used the term value object to describe a DTO, but it changed it in a ...


7

One term which has been used for this recently is test induced design damage. Telastyn is correct that your code snippet isn't actually a very good example of this concept, though. A more common occurence is that a test wants to set up a class to be in a particular state during its "arrange" phase, but due to encapsulation, doesn't have any way to do that ...


7

If logging is critical to your application, then one should stop the application if logging fails. If not critical, then being somewhat defensive one could have a secondary component to handle logging failures that logs/alerts to a secondary source. But even that is not fool proof and you will have to consider what happens if the secondary logger fails ...


6

Despite appearing in a book authored by Martin Fowler (for whom I gave a lot of respect), I can't understand why one would use this pattern. As you have realised, it is pretty limited as most business operations require accessing multiple tables, and sometimes multiple data sources (databases, ldap repositories etc). A secondary concern is performance - you ...


6

Ok, here's one suggestion. First of all, you should get rid of repeating parameters (from, to, subject etc) and methods (sendInvite, sendVerificationCode etc). To achieve that you could start with defining an EMail-class holding the parameters as attributes. This is quite a standard approach when facing repeating parameters. Now all invitations and ...


5

On the one hand I can argue this does not violate SRP, because the whole use is database communication. You could also say you have a single class in your application, because the whole class does processing of data. It doesn't work like this. If your class has: a mix of different abstraction levels; a mix of things that can be described as separated ...


5

Users do not like change. Even when the change is objectively superior from an UX perspective, the human resistance to change habits will result in them finding it subjectively worse. So when you already have a userbase you are developing the new application for, it is not a bad idea at all to follow the UI conventions they are used to instead of following ...


5

I certainly wouldn't call it a value object because that conflicts with the idea in domain-driven-design. Going from wikipedia: In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same ...


5

The decision which parameters a constructor should have is the same decision which parameters an arbitrary function should have - it should have exactly the parameters which are needed to create a specific, ideally easy to understand, abstraction. And if your abstraction of a car encapsulates exactly those three things, version 2 reflects that much better ...


5

Is it misleading to label classes or methods as a particular design pattern (Strategy, Mediator, etc.) if they only loosely fit that definition? It depends. If you have a singleton and it does not prevent instantiation, then it would be misleading to label it a singleton, since it's not a singleton. It's a global variable. Doing otherwise leads your ...


4

As with all program design, if you have two things that need not know about one another (A and B) then the proper design is to have some mediator C that lives above and knows about both: C / \ A B The mediator can then glue the two together via a generic decoupling mechanism (events, messages, delegates, just passing one into the other, etc). For ...


4

Yes, I think you are violating the SRP. Not because you kept all of your database code in one class, but because you have database code for completely different entities (users, products, events, friends) all in one class. At the very least, separate your code into classes by the entity it's most closely related to. If you're looking for design patterns, you ...


4

The Context Object is a pattern used in a number of places, including J2EE, ASP.NET MVC and Entity Framework. It is used "to encapsulate state in a protocol-independent way to be shared throughout your application." Context Object is a controversial pattern. Although it can be thought of as a means of Inversion of Control or Dependency Injection, it's ...


4

You wouldn't use it. It's mainly out there as an exercise to help you understand the interesting properties of java enums, for which there are a few uses beyond the more traditional C++ style uses. It's less verbose and requires some relatively deep knowledge of the language, which makes it attractive to the "look how clever I am" breed of programmers. ...


3

What you describe are known as JavaScript Promises, in general programming parlance they are called Continuations. C# supports them through the Task Parallel Library and Async/Await keywords. Here's how it works, I want to call an operation asynchronously. If the operation is already declared Async it's simple: Add async to your function that is calling ...


3

The first is marginally better, but in general, you should try to avoid unnecessary side effects altogether. Why? Modifying input parameters is vile. It is unexpected, it is difficult to test, it is difficult to reuse, it creates problems in concurrent environments... Modifying a class is sometimes fine, that is what classes are for really... but it can be ...


3

There isn't, so far as I'm aware, a general name for production code created specifically for the purpose of unit tests. With the notable exception of friend-assemblies (for unit-testing internal units) such code would normally be a smell indicating that something's up with the shape of your class' public signature. This particular example, however, does ...


3

Design patterns are "best practice" solutions for challenges that occur frequently when designing software. The benefit of design patterns lies in If you find that your problem (nearly) fits a design pattern, you have a short name to call your problem by, which eases communication with others The solutions presented in design patterns are generally well ...


3

If a property meets the following criteria then I make it a constructor parameter: The class is dependent on it for operation It has no reason to change over the lifetime of the object Its value is known at object creation If it meets these criteria, then it's a constructor parameter. If it only meets one or two of the criteria then it's almost ...


3

I understand you are leaving some details out due to the proprietary nature of the project. This answer is my take on what is going on based on how I understand the question. Please leave a comment if I am off base here and I will edit accordingly. I think you may misunderstand how to use JUnit in complex projects. Each test needs to stand on its own: ...


2

I would call them structs. An old school name for old school design. DAOs contain persistence-related functionality. That's not a DAO. That could be a poorly implemented value object. Value objects should generally be immutable and they should have proper constructors. (However, a configuration could very well be an example of a value-like object that ...


2

You're confusing global variables for member variables. Modifying member variables in member functions is fine, when your function is meant to modify the class state. That's kind of why OOP came about in the first place: to logically group state and behavior. If it's getting hard to keep track of whats happening to your member variables, that's not a ...


2

It is not a real DTO, according to this definition of DTO. In that definition, a DTO is a streamlined, packaged object or group of objects without real behaviour. On the other hand, it is certainly a transfer object, by definition, and it certainly (likely) can package more than one object. Putting validation, especially inter-object validation in it makes ...


2

The abstract Controller class can't create the right <concrete class>Domain classes, because it doesn't know which concrete class it belongs to and which Domain and View classes it should be associated with. What you can do is pass in the Domain and View classes from the derived class's constructor. abstract class Controller { private $domain; ...


2

First and foremost, you should be consistent with the framework convention. Java is a big world to be sure. I use Java for Android, and here the convention is rather permissive. For example, setOnClickListener allows you to pass in null - this is a crude but nonambiguous way of removing the listener. From Android source code: public class View implements ...


2

Good question. I believe that such methods don't require its own check simply because: NullPointerException is thrown should the event occur, so assuming you tested that case at least once, you would know if null were passed. If you begin adding checks for addListener or removeListener, then you really would have to perform basic checks on every method in ...



Only top voted, non community-wiki answers of a minimum length are eligible