Hot answers tagged

144

KISS is subjective. DRY is easy to over apply. Both have good ideas behind them but both are easy to abuse. The key is balance. KISS is really in the eye of your team. You don't know what KISS is. Your team does. Show your work to them and see if they think it's simple. You are a poor judge of this because you already know how it works. Find out how hard ...


127

A common misunderstanding with the DRY principle is that it is somehow related to not repeating lines of code. The DRY principle is "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". It's about knowledge, not code. LoginPage knows about how to draw the page for logging in. If EditInfoPage knew how to ...


110

You don't do DRY because someone wrote it in a book somewhere that it's good to do, you do DRY because it actually has tangible benefits. Specifically from that question: If you repeat yourself, you can create maintainability issues. If doStuff1-3 all have similarly structured code and you fix a problem in one, you could easily forget to fix the problem ...


75

If they really are reusable methods / classes, you could write them into a small number of 'Swiss Army Knife' libraries. We do this quite often at my company; we call them framework libraries: Framework.Data - Utilities for working with database queries. Framework.ESB - Standard methods for interacting with our enterprise service bus Framework.Logging - ...


58

The general rule reads "Prefer delegation over inheritance", not "avoid all inheritance". If the objects have a logical relationship and a B can be used wherever an A is expected, it is good practice to use inheritance. However, if the objects just happen to have fields with the same name, and have no domain relationship, do not use inheritance. Quite ...


46

Er wait you're concerned that repeating public LoginPage loginPage; in two places violates DRY? By that logic int x; can now only ever exist in one object in the entire code base. Bleh. DRY is a good thing to keep in mind but come on. Besides ... extends LoginPage is getting duplicated in your alternative so even being anal about DRY wont make sense ...


39

I wrote about this already in a comment to another answer by candied_orange to a similar question and also somewhat touched on it in a different answer, but it bears repeating: DRY is a cute three-letter acronym for a mnemonic "Don't Repeat Yourself", which was coined in the book The Pragmatic Programmer, where it is an entire 8.5 page section. It also has ...


34

I want to challenge your basic premise, namely that Design Patterns aren't added to the standard library. For example, java.util.Iterator<E> is in the standard library and is an implementation of the Iterator Design Pattern. java.util.Observable/java.util.Observer is an implementation of the Publish/Subscribe Design Pattern. java.lang.reflect.Proxy is ...


32

You're not wrong. It's just psychologically very difficult to convince people of their own limitations. The reason we have invented maxims, guidelines etc. that restrict what we should do is that we have found, over time, that behaving in a particular way leads to more success. Importantly, it will lead to more success even if it doesn't seem so to us at ...


30

In a way, you answered your own question with that remark in the last paragraph: I am starting to think the DRY principle does not apply as much in this kind of situation, but that sounds like blasphemy. Whenever you find some practice not really practical for solving your problem, don't try to use that practice religiously (word blasphemy is kind of a ...


27

The Don't Repeat Yourself (DRY) principle is easy to mindlessly over apply. Keep in mind that the real sin isn't using copy and paste. It's spreading a design decision around in a way that makes it difficult to change that decision. If what you really have is two decisions that just happen to look the same at the moment then everything is fine. You'd be ...


26

If I try to make a new method to handle B differently, it gets called out for code duplication. Not all code duplication is created equal. Say you have a method that takes two parameters and adds them together called total(). Say you have another one called add(). Their implementations look completely identical. Should they be merged into one method? NO!!! ...


24

I believe this is a misconception any way I can think of. The test-code that tests production-code is not at all similar. I'll demonstrate in python: def multiply(a, b): """Multiply ``a`` by ``b``""" return a*b Then a simple test would be: def test_multiply(): assert multiply(4, 5) == 20 Both functions have a similar definition but both do ...


23

Design patterns are recurring designs which cannot be captured in a class or library. Usually they have to do with how multiple classes interact. The standard library of a language can use patterns just like other code can - eg. the Java IO library uses the decorator pattern. But the decorator pattern itself cannot be captured in a single class or library. ...


23

If changing the sound files for each single grade without modifying the code is the requirement here, I would externalize the configuration (mapping). Create entries in your configuration mechanism (config files or database) which contain the sound file names for each grade. Instead of duplicating the sound files I would rather list the same file name ...


22

Tackling each of these at a time: Regarding the Project Structure This one can be subjective at the best of times, but projects are typically structured by logically dividing your code into sub-folders or sub-projects based on their general area of responsibility, or which 'layers' they belong to. For example, Models, Views, Controllers, Core ...


21

I disagree with the accepted answer for many reasons. In my experience, when I see "miscellaneous" libraries like the accepted answer, they're an excuse to reinvent the wheel (or not invented here(NIH)) - a far greater sin than violating Dont Repeat Yourself (DRY). Sometimes violating DRY can be a reasonable compromise, it is better than introducing tight ...


20

This is actually a very difficult question to answer and I have found it to be a very controversial subject. As Yannis Rizos pointed out in his answer, having the constraint logic in both the database and the ORM layer would seem to violate DRY, which "can lead to maintenance nightmares, poor factoring, and logical contradictions". However, removing the ...


20

His primary argument was that "he's a good programmer and he can understand and read even the first version fast enough" so he doesn't care if it's written like that or not. If that is his primary argument it may be a sign that he is primarily afraid with being not called a good programmer, or even a bad programmer. IMHO the crucial point here is to make ...


20

The biggest reason against two applications is that you are very likely to have to implement user rights anyway. Presumably you aren't going to allow an advisor to enter notes about students he doesn't advise, or delete important information without uber-admin privilege, or edit information about advisors other than themselves? Once you have this mechanism ...


19

DRY absolutely does not mean "use minimum number of lines possible", or "do not write code that looks like other code" DRY refers to having code that does the same thing in two different places. But same doesn't mean "code looks the same" but rather "does the same conceptual task". How the code looks is irrelevant, what it does is what is important. Don'...


18

By using inheritance, you will end up with something like this, but class names will lost it contextual meaning (because of the is-a, not has-a): Exactly. Look at this, out of context: Class D : C { String age; } What properties does a D have? Can you remember? What if you complicate the hierarchy further: Class E : B { int numberOfWheels; } ...


17

child classes use different types, the calculation varies a tiny bit from class to class. First and foremost thing is: First clearly identify what part is changing and what part is NOT changing between the classes. Once you've identified that, your problem is solved. Do that as the first exercise before starting the re-factoring. Everything else will fall ...


17

I think this rule of thumb exists because it is easy to get caught into playing "What if..." when designing the code for the first time or after the first duplication. I've encountered severe analysis paralysis in some cases because people started designing functionality that might be needed later. But not needed for the immediate problem at hand. There ...


17

It depends. Assuming that the subject (and not the sender, for instance) is the only "repeated" parameter here, I'd turn the question back on you: If the subject text changes in one place, does it necessarily change in both? DRY isn't so much about eliminating the amount you copy+paste. It's actually quite easy to copy and paste! What we aim to avoid is ...


16

Your guiding principle should be Don’t Repeat Yourself: In software engineering, Don't Repeat Yourself (DRY) is a principle of software development aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures. The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative ...


15

It depends. Deciding where to put validation should be based on the description and strength of the contract implied (or documented) by the method. Validation is a good way to bolster adherence to a specific contract. If for whatever reason the method has a very strict contract, then yes, it is up to you to check before calling. This is an especially ...


15

Others on the team think that it should be two completely separate applications because of the complexity of modifying the views based on the authorization level of the user. Really? they don't realise they have to create these views anyway if they made 2 separate applications? How hard is it to put both views into the same application and decide which ...


14

Proper unit tests have a naming convention that helps you immediately identify what has failed: public void AddNewCustomer_CustomerExists_ThrowsException() This is why you have one assertion per test, so that each method (and it's name) corresponds to the condition that you are asserting. As you've correctly pointed out, each new test is going to have ...


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