Tag Info

New answers tagged

2

You're question is a bit unclear, but I'll explain what the Strategy pattern is in case you don't have a good understanding. Strategy allows you to swap part of the functionality of an object dynamically during runtime. This is done by encapsulating the different functionalities in classes that all share a common supertype, and having the object in question ...


0

It would seem to me that either system would need to maintain its own outgoing queue in order to resume once the issue with the other system is corrected. Yes, queueing is a good solution for such a scenario. That's what queues are made for: queing up messages for its consumers. But I do not quite get, why a system has to maintain its own outgoing ...


0

If the middleman is currently pulling data based on the time of the previous successful run, then, to cut out the middleman, each individual system could do the same in a push architecture. Yes, each system would need to keep track of this, but it's only a single timestamp, not a full blown message queue.


10

This is the Parameter Object Design Pattern (or Argument Object), the related Refactoring is called Introduce Parameter Object.


1

This seems to me like a normal case of grouping related variables into compact structure, that has been practiced since structures were invented. Considering it is so ancient, I would imagine there is no name for it. Also, remember one thing : Patterns are much complex than that. Pattern usually means something that introduces SOLID into code. Your case is ...


0

The second option seems like you are defining your repository based on your requirements for this given application vs 1 repository per "table" which could be more flexible for other areas of your app that might come up or other applications that might not group stuff like your current app does. Yes, it means you'll have a fair amount of repositories, but ...


1

I don't know why it would need to return true. Why couldn't it simply commit if no exception is thrown? That's the way it would be if you just had a transaction in a using statement. There are arguments for and against external vs. internal control of these types of things (ie. external vs internal iteration), but I don't see the need to have BOTH ...


0

It makes sense for objects to share an interface if they share operations or properties. In your case, both ribbons and groups can be part of a web, so it makes sense for then to share an interface, which is your second option (which is sometimes called the composite pattern). I recommend calling that interface WebElement. There are some added complexities, ...


2

PyCharm (the community version is FOSS) will do a pretty good job of finding all calls to your function (Alt-F7), so you can easily see how it's called. Of course, being a dynamic language it can't untangle truly horrible code, but your use case should be fine. Another mechanism which may fit your case better (since returning two things is a common way for ...


1

After discussing this with a colleague, and some more thought, I came to the conclusion that it depends on the nature of the dependency. The whiteboard pattern completely decouples sources and listeners. The overhead (in processing time and absence of compiler checks) is warranted if: the listeners of an event are completely unrelated to the source (i.e. ...


0

Well I would add caching to your DTO. DTOs are stateless, so always poke the database, unless a cached value exists. Security is not an issue; you can always cache reports by users.


0

That is an OOP Data Descriptor. Although you are describing additional information about a class rather than information about bits in memory, the fundamental parity still applies; you're describing in one place useful aspects about data in another place. I'd advise you to adopt that name, write up a clearer definition of the pattern, and use the name in ...


1

The problem lies with the concept of answerQuestion. You use answerQuestion for two roles: User input provided, listeners perform appropriate actions. Server update provided, listeners perform appropriate actions. Simple approach While they are similar, they are not the same. The pattern for this (if you want to call it that), would be to have two ...


1

You can inject a singleton just fine. Don't understand why people are saying don't use it. A singleton is just something guaranteed to have one and only one instance. Using a singleton doesn't rule out injection. In Java the recommended way to implement is to use an Enum. Again very injectable. Have it implement a common interface so that more thermometers ...


5

No, it's not a good candidate. What if you buy a second thermometer in order to get the temperature in two different locations? What if you want to create a mock or a stub of your thermometer in order to unit test parts which rely on it? With singleton, you'll end up doing something like: public class TemperatureRealTimeDisplay { // Show the current ...


1

Here is what you've done wrong already -- you have hand-rolled an MVC while in a state of confusion, and without any MVC under your belt. Take a look at PureMVC, it is language agnostic and can be a good platform to get your feet wet with actually doing MVC. Its code is small and comprehensible, and this will allow you to tweak it to your needs as you ...


0

I strongly suggest that you put this scope logic inside your data schema design (SQL tables for example). Don't do filtering. The reason is mainly scalability. When there are so many data items, you don't want to ask the DB to load them all, and then you apply scoping on these items in memory. You overload the DB with extra work, and memory too. Database ...


0

I think that at least part of the answer is to make your Access Token 'ambient', so that you can access it from any part of your code without having to pass it along as an argument with every call. One of the ways to do this is to define a custom IPrincipal that includes your Access Token, and set it on the HttpContext.Current.User* , e.g. see this ...


0

I'd have a BaseJob class which will contain basic/shared properties and functionality. It can be an abstract class or just a plain base class, depending on the situation. If all jobs and states have similar behavior the base class can act as a controller and be abstract. I'd also have State in each Job or may be the BaseJob can expect some sort of ...


1

Java has a standard mechanism precisely for this, the java service providers, thinks in the way you use a JDBC plugin, you put the JDBC driver in your classpath and your application now can connect to this concrete database provider (oracle, mysql). In fact this is used in a lot of java standards that define an interface an allow different implementations. ...


1

As pointed out in the other answers, it depends on your unique circumstances (needed to run the simulations) whether to use a real database, or a real geographic information system (GIS). Regardless of you choice of tooling, one thing is certain: your simulations will involve application logic that is superficially similar to what is done by databases and ...


2

I don't think Asp.Net is really based on a Design Pattern. It's just a Framework developed with a similar concept to the Windows Forms. If you want to use a pattern to develop a Web Site with .Net Framework, I suggest to have a look to Asp.Mvc. It's another technology from Microsoft based on the MVC pattern. At first point, I have partially misunderstood ...


1

Get the data design done first. Understanding what data you need for each entity, and how the entities relate should simplify your design. You may find you have many entities which can be modeled as sub-types. Different sub-types may have different behavior, but should contain the same state (data). Understanding the common and specific behaviors of ...


1

This looks like a dashboard. There are a number of dashboard platforms out there that can be configured as to data sources, polling intervals, etc. Let me suggest a rough design, while challenging some of your assumptions. Assumption: You state that there is a central database that holds the results of each job. I don't see a requirement that it holds the ...


6

You both can be correct. In general, your approach falls under the purview of the Interface Segregation Principle and his falls under You Ain't Going to Need It. In my experience, it depends on what the interface is. Does it represent a concrete thing, or does it represent a trait of a variety of things? If it represents a concrete thing, then just leave ...


1

Neither. Abstract classes and interfaces are not substitutable. If your class has a binary operation (that is, it inspects the private fields of another instance of its class), this simply can't be done from an interface (because an interface hides its implementation). This is why, for example, you don't see a union/merge operation in Java's Set interface. ...


5

You have two options: Every agent knows about every other agent, and queries those agents as needed. Every agent publishes its state changes, and other agents listen to the changes they care about. The second approach has several benefits over the first, most important being that changes only happen when necessary. For example, if only 2 farmers trade ...


2

Pipe & Filter is what you're looking for. http://msdn.microsoft.com/en-us/library/dn568100.aspx Basically, you define a standard input object and a standard output object. In object oriented programmation, you can easily define those as interfaces. The filters take the standard input object, apply some transformations and returns a standard output ...


3

I have seen similar things done using the Chain of Responsibility pattern. Basically, each transformation/filter is a single command, and your configuration specifies the order in which they execute. The result of each transformation command can be passed to the next along with a command context to contain other metadata that should not be in the data being ...


1

You may want to consider only running tests that have recently failed. Given that the entire set takes 6-7 hours (i.e. is runnable nightly), you could base your tests set on the past few nights' results. If you mix in a few randomly selected tests for broader coverage over the course of the day, you should get a good chance of catching errors. This idea ...


1

TL;DR: Create a Dependency DAG from affected modules Identifying the tests that are impacted by a particular change is the same as identifying when to recompile/relink a object file. Create a dependency directed acyclic graph (DAG) starting at the modified module. You should be able to traverse all imports to identify the what needs to be tested. You can ...


0

My personal favorite would be to use knockout to accomplish this kind of page manipulation through a two-way binding with some kind of "security" class. I use quotes here because it really isn't security so much as it's just interface manipulation. Security should always be handled server side. However, with a good knockout model you would be able to use ...


0

Let's take a look at your observer pattern: As you stated, parent objects may not be in the memory at the time of change. The observer pattern is only applied to situations where the entire observer hierarchy is present in the memory so that changes may be reflected directly. To consider this option would mean considering the following: What does it mean ...


1

I assume this interface would contain different signatures like RegisterUser(), LoginUser(), BanUser(), ModifyUser(), ChangeAuthenticationLevel() and so on? Is this correct? No it is not. See, how there is User in each of those methods? That means it operates on user, and thus is part of the User entity. And as such, they should all be methods on User ...


0

After some thought it seems like the following approach might be beneficial whereby each inner control is represented by a facade which constructs the presenter, view and its model and exposes the relevant methods: I would love to know what others think about this idea...


1

You could wrap your disposable Connection in a reference-counted disposable wrapper, like so: public abstract class RefCountDisposable<TDisposable> : IDisposable where TDisposable : class, IDisposable { TDisposable reference; protected RefCountDisposable(TDisposable reference) { this.reference = reference; } public ...


7

Let's pause for a moment and look at the fundamental issue here - Architecting a system where the architecture model is too coupled to low-level features in the system, causing the architecture to break frequently in the development process. I think we have to remember that the use of architecture and design patterns related to it have to be laid on a ...


2

The first thing you need to do is explicitly separate out the connection lifecycles in your two scenarios. Trying to juggle the two will only lead to confusion. To that end, I would completely remove the _connection member variable. Here's what I propose: Use a "context object" to manage your state. Your Connect method already returns a Connection, so that ...


4

Your friend seems to be facing numerous headwinds based on his anecdote. That is unfortunate, and can be a very hard environment to work in. Despite the difficulty, he was on the correct path of using patterns to make his life easier, and it is a shame that he left that path. The spaghetti code is the ultimate result. Since there are two different problem ...


2

I think it at least partly depends on the nature of your situation. You mentioned constantly changing requirements. If the customer says "I want this bee-keeping application to also work with wasps" then that seems like the kind of situation in which careful design would help progress, not hinder it (especially when you consider that in the future she might ...


3

A design pattern's complexity can bite you if the problem it was supposed to solve suddenly disappears. Sadly, due to enthusiasm and popularity of design patterns, this risk is rarely made explicit. Your friend's anecdote helps a lot to show how patterns don't pay off. Jeff Atwood has some choice words about the topic. Document variation points (they are ...


-3

Obsolete code intertwined with "fresh" production code complicates reading and, therefore, complicates writing of new code. Such code must be kept under control and eliminated as soon as it's no longer needed. Here I wrote a short article on keeping obsolete code under control. Hope it helps.


7

The question seems to be wrong at so many points. But the blatant ones are: For the Null Object Pattern you mentioned, after the requirements changed, you change a bit of the code. That's fine but it doesn't mean you 'murder' the Null Object Pattern (btw, be careful with your wording, this sounds too extreme, some people too paranoiac won't see this as ...


9

It would appear the mistake was more to remove the pattern objects, than to use them. In the initial design, the Null Object appears to have provided a solution to a problem. This may not have been the best solution. Being the only person working on a project gives you a chance to experience the whole development process. The big disadvantage is not ...


7

There are certain static analysis tools that can help determine "test impact", which can then run the effected tests. But I can't help but feel that you're solving the symptom, not the problem. When I worked in QA, there was one overriding mantra that has helped me as a developer: "don't trust the developer". Even if I could determine "relevant", I wouldn't ...


1

If your unit tests are taking 6-7 hours to run, something is wrong. They should take a few minutes at most. Note that I say should - I know how difficult this can be in reality. Maybe it's time you start mocking out your objects so that you're not dependent on the filesystem or DB or whatever is slowing you down. You don't want to have to deal with working ...


82

I see some wrong assumptions in this question: code with design patterns, though applied correctly, needs more time to be implemented than code without those patterns. Design patterns are no end in itself, they should serve you, not vice versa. If a design pattern does not make the code easier to implement, or at least better evolvable (that means: ...


14

In your example of using the Null Object pattern, I believe it eventually failed because it met the programmer's needs and not the customer's needs. The customer needed to display the price in a form appropriate to the context. The programmer needed to simplify some of the display code. So, when a design pattern doesn't meet the requirements, do we say that ...


39

My humble opinion is that you shouldn't avoid or not-avoid using design patterns. Design patterns are simply well known and trusted solutions to general problems, that were given names. They aren't different in a technical manner than any other solution or design you can think of. I think the root of the problem might be that your friend thinks in terms of ...



Top 50 recent answers are included