Tag Info

Hot answers tagged

48

No, item.AddTo(items) it is not more natural. I think you mix this up with the following: t3chb0t.Add(item).To(items) You are right in that items.Add(item) is not very near to the natural english language. But you also don't hear item.AddTo(items) in natural english language, do you? Normally there is someone who supposed to add the item to the list. Be ...


17

I'll tell you a story. Many years ago, when I was a young, inexperienced programmer and GoF had not long before published their Design Patterns book, and Java was a new language and the only user interface library generally available for it was AWT, and AWT applications all looked ugly as hell, my company decided to switch development from C++ to Java. But ...


8

IMHO you are approaching this from the very wrong end. You ask for avoiding duplicate code where it seems you do not have any (or at least not much) code so far. Better start implementing the code for creating one or two PDFs, and whenever you are tempted to copy/paste a piece of code, stop for moment, step back and think if you can avoid the duplication ...


6

Command Pattern is generally used to decouple WHAT from WHO, and WHAT from WHEN. This is the benefit of having a simple interface as simple as: public abstract class Command { public abstract void execute(); } Lets imagine that you have a class EngineOnCommand. You can pass this Command to other objects which accept instances of Command. So this means ...


5

The Builder pattern is most useful when the product you are building consists of multiple discrete parts, where external information specifies which parts, or if the product has many optional properties. In your case, you have a long list of required properties. Here the Builder pattern only gives you the appearance of a less complex constructor at the cost ...


5

Remove the duplicate test code Having tests on your child-classes for code that is in the parent class means twice the maintenance if the parent class changes. The reason you move to a parent class is specifically to avoid duplicating code, actual code as well as tests. (And if you ever end up creating a third child you might end up thinking that all tests ...


4

I think you might be getting stuck trying to make your class hierarchy fit a real-world taxonomy, and that's not always the best approach. First of all, objects are almost always created by some sort of factory in this situation. You call a probe function that returns a list of all Widgets connected to your system, already instantiated. Then you can ...


4

@valenterry is quite right about the problem of separation of concerns. Classes should know nothing about the various collections which might contain them. You would not want to have to change the item class each time you create a new kind of collection. That said... 1. Not Java Java is no help to you here, but some languages have more flexible, ...


4

You could always use an interface or an abstract class to define the contract where you have generalized behavior for the ColorText class, but you need to keep the method name the same (AddColorText) public interface IColorText { public abstract void AddColorText(string text); } public class RedColorText : IColorText { public void ...


4

I'd just start out using no patterns. var records = CheckTable(); foreach(var record in records) { GenerateReport(record); SendEmail(record); } Start simple, not everything needs a pattern. If you start doing a lot of different tasks, or allow tasks to be configurable in the order and the number of tasks run per record, then think about ...


4

Although this can be a good idea at one level, you want to avoid passing monads around all over the place if you can. It's easier to read, write, compose, and reuse if you write your functions normally, then modify them into a monadic context as needed: insert x (Buffer before after) = Buffer (x:before) after insertList xs (Buffer before after) = Buffer ...


4

This is sort of problems intended to be dealt with using Template method pattern: ...behavioral design pattern that defines the program skeleton of an algorithm in a method, called template method, which defers some steps to subclasses. It lets one redefine certain steps of an algorithm without changing the algorithm's structure... Applied to your ...


3

This looks like a good application of the ideas of "Finite State Machine" and "Polymorphism". You've already defined your states, so the next step is to define the transitions between states, and the behavior of the system when it's in each state. There are many ways to implement state machines, but in this case you might benefit from three classes, one ...


3

No, having the View observe the Model (or perform other read actions on the Model) is a valid implementation of the MVC pattern. There are two main ways that the MVC pattern is typically implemented and they differ mostly in how the information from the Model gets to the View. In the first form, all information passes through the Controller, who is made ...


3

It depends on the current situation and the size of the project. Registering the classes that implement this interface in the IoC container and then injecting specific implementations in the objects that depend on the interface might be the way to go in some cases but might be an overkill in others. In small projects, I prefer the benefits of seeing ...


3

The problem I am trying to solve is, given two types, how can I determine whether one can be converted to the other. In your language design, you have a well defined set of rules for your type system. A is a subtype of B if and only if these conditions hold. C can be assigned to a variable of type D if and only if these other conditions hold. And you ...


3

Delegation in code is the same thing as it is in real life; you're handing a task off to someone or something else to execute. In user interfaces that have event handling, this is a good thing, as the code behind the UI is already complex enough, and delegation helps avoid a big ball of mud. As a matter of general practice, I push as much logic as I can to ...


2

You could create a third class that manages both the repository and the cache. Then, don't manually try to get the cached value and if not available query the repository like $activity = $this->cacheHelper->getFromCache($key, $name, "ArrayCollection<DW\DWBundle\Entity\Activity>"); if ($activity == null) { $activity = ...


2

The answer by scriptin is giving a reasonable solution, but doesn't answer your questions about the failure of the implementation you had. You get a 'queue empty' error when you call pop on a Ruby queue in non-blocking mode (true passed) and there are no items on the queue. Your "producer" thread is created and your "consumer" thread is created, but ...


2

Design patterns like the Repository pattern aren't dependent on particular technology, so the obvious answer to your question is "yes, of course you can". You can write repositories which are ultimately backed by any storage technology - the point is that the Repository pattern is a way of structuring your data access code and separating it from your other ...


2

I think the book “Head first design patterns” is correct. As per Wikipedia, this pattern “allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class”. 'Extensions' are adding capability to an object statically and behaviors can be added by adding methods only, ...


2

Yes, many people consider Service Locator to be an anti-pattern. Depending on how it is implemented it can be difficult to unit test code that uses it, it reduces flexibility because clients can only have a single implementation of each interface, and it relies on run-time type testing so various errors can only be detected at run-time (often only during ...


2

Since you need to do what seems to be polling, you could take a look at the Observer Pattern. This would allow your service to call your methods so that they can take appropriate action. That being said, as it has been mentioned in the comments, you seem to have design patterns the other way round. The task should lead you to a design pattern. Trying to ...


2

It is very hard (although in a language that has reflection not entirely impossible) to create a 100% decoupled application. With reflection, we can use this to allow the user to specify concrete classes for each object needed in the application at runtime (perhaps through a configuration file), thus achieving complete decoupling at the expense of increased ...


2

With your extension method you still have to call Add() so its not adding anything useful to your code. Unless your addto method did some other processing there's no reason for it to exist. And writing code that has no functional purpose is bad for readability and maintainability. If you leave it non generic the problems become even more apparent. You now ...


2

In times like this I try to step back, forget the implementation, and focus on the requirements. Essentially, you want to: - Define discrete entities using primitive data elements - Validate entities using domain-specific rules - Construct a domain model from valid entities - Perform useful and interesting computations with your domain model If you're in ...


2

There is no way to logically group these into different objects to reduce the amount of parameters passed into the constructor. I think this is the essence in your problem. First, the Builder pattern is normally used in this situation as best practice. However, for me personally, I don't like it and even consider it an anti pattern. You in some way ...


2

You seem to have some sort of mental block going on. If you want a design that eliminates the duplication, you're going to have to change your design somehow, which you seem resistant to do. You need to look past your current design. Some ways to eliminate the duplication, some of which are better than others: Put the common stuff of the models into a ...


2

Your architecture should look something like this: Data source <--> Data source driver <--> CRUD interface <--> Application You'll need one data source driver implementation for each type of data source. The CRUD interface will be the same regardless of data source. Note that you can have more than just CRUD methods. You might want to ...


2

While views shouldn't contain business logic, they still can contain basic conditional logic, loops, etc. Since your website is “very heavily based on whether an event has occurred or will occur”, this is definitively a case where you'll have two views, not one. What questions could I ask myself to help me determine the best approach to take to this in ...



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