Tag Info

Hot answers tagged

81

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: ...


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 ...


16

This sounds suspiciously like an inner platform. Here are the potential problems: You'll be writing queries that query the database for what information to query (metaqueries) first, rather than queries that simply retrieve the needed information. You'll be subverting the role of the database, which already provides metadata capabilities such as rows, ...


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 ...


10

A Helper class is a lesser known code smell where a coder has identified some miscellaneous, commonly used operations and attempted to make them reusable by lumping them together in an unnatural grouping. Successive developers have then come onto the project and not realised that the helper class exists, and have consequently rewritten the same common ...


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 ...


8

I'm going to start flat out by saying after more than 30 years experience writing software and working in I.T in general, I have NEVER, EVER yet found a good reason for concatenating data coming out of a database. You could be putting 90% of your application code in the DB infrastructure, and doing all sorts of magic things with it, and I still would not be ...


7

There's a fair amount of debate in terms of when, where, and how to test an application of X complexity. And a fair amount of political zeal on all sides. In my own experience, I've been on a lot of projects that were small and simple, arguably requiring little automated testing. And truthfully, I developed with nearly zero automated testing and horrendously ...


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 ...


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 ...


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 ...


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 ...


5

If you are working on a script where you know (or suspect) that it will later be used as a library in a larger project, then it is easier to start out with writing the functionality in a library and then tagging on a driver script to use the library from the command line. There are no specific design patterns to help in creating good API's. It requires ...


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 ...


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 ...


4

"I'm trying to do X, which design pattern should I use?" is usually the wrong question to ask. A design pattern is a proven solution to a recurring problem, but its value as a pattern lies largely in its name: once you've solved similar requirements in similar ways several times, you can more easily remember the combination of classes and relationships ...


4

The main problem is that you've created a circular dependency between Person and PersonImpl... Person shouldn't have any references to implementation classes, but the "new PersonImpl()" call in the builder creates a hard, compile-time dependency on the concrete class. I think the fix is to either spin PersonBuilder off into it's own class, or else move ...


4

You might consider making LoadProducts() a static method, so that you don't have to instantiate a blank object to load a product list: class Product { public static function LoadProducts(...) { } } and then its just $products = Product::LoadProducts( ...)


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 ...


3

Bags and suitcases are both types of containers. You can also put bags inside suitcases, and vice versa. Containment doesn't care about inheritance, and inheritance doesn't care about containment. The two concepts are entirely orthogonal, and as such there is no 'best practice' here.


3

You can't really decide on a specific design pattern at this stage. Your description is too high level. To be able to get to deciding on a design pattern you should first construct a doman model which shows the main entities in your system, and associated cardinalities. From reading your description there are three main entities that jump out : User, ...


3

Fragment is a modular section of an Activity that has it's own lifecycle, receives its own input events, which you can add or remove while the activity is running (sort of like a "sub activity" that you can reuse in different activities) Apart from the obvious advantage of using fragments, UI optimization across different screens, it lets you manage ...


3

A design pattern is (to quote Wikipedia) "general reusable solution to a commonly occurring problem." You're describing a characteristic of good code, not a particular solution to a problem, so "design pattern" doesn't really apply. I believe the concept you're looking for is cohesion. Strictly speaking, cohesion refers how well the parts of a module ...


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

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 ...


2

There's definitely nothing wrong with not using exceptions when exceptions are not a good fit. When the code execution should not be interrupted (e.g. acting on user input that may contain multiple errors, like a program to compile or a form to process), I find that collecting errors in error variables like has_errors and error_messages is indeed far more ...


2

Why do people use it? I have seen quite a number of singletons in the PHP world. I don't remember any use case where I found the pattern to be justified. But I think I got an idea about the motivation why people did use it. Single instance. "Use a single instance of class C throughout the application." This is a reasonable requirement e.g. for the ...


2

I can try to answer your question on a generic level. You can create a centralized repository object which contains all currently loaded matrix objects and also records accesses to them. It loads the matrix objects on first access and stores them internally. All requests for these matrix objects must go through this repository object to record them ...


2

What you're talking about here is dependency inversion and encapsulation. You consuming code wants to hold a dependency on some means of getting hold of domain entities, without needing to know how that happens. It wants a set of methods on a black box, which it expects to give some inputs and get some outputs: an interface. Instead of having your code ...


2

First, what you are describing sounds quite a lot like functional approach to things. Separating data and functions operating on those data is modus operandi of all functional language. Try looking at Haskell for inspiration. Second thing that I see is that you seem to lack concept of abstraction. If you have identified multiple classes, which have same or ...



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