Tag Info

Hot answers tagged

51

Modularity. Any decent language will give you the means to glue together pieces of code, but there's no general way to unglue a large piece of code without the programmer performing surgery on the source. By jamming a lot of tasks into one code construct, you rob yourself and others of the opportunity to combine its pieces in other ways, and introduce ...


27

Better maintenance, easy testing, faster bug-fixing are just (very pleasant) outcomes of applying SRP. The main reason (as Robert C. Matin puts it) is: A class should have one, and only one, reason to change. In other words, SRP raises change locality. SRP also promotes DRY code. As long as we have classes that have only one responsibility, we may ...


21

Is easy to create code to fix a particular problem. Is more complicated to create code that fixes that problem while allowing later changes to be made safely. SOLID provides a set of practices that makes the code better. As to which one is correct: All three of them. They are all benefits of using single responsibility and the reason that you should use it. ...


18

Every time you notice something like that, enter a new ticket into your issue tracking system. Make a habit to use issue tracker as a primary tool to communicate stuff like that, because from there, it will be easy to pick, evaluate and prioritize for your senior colleagues / lead / manager / whoever is responsible for tracking the issues in your project. ...


7

You've misread the directionality of the quote. JOINs are generally discouraged for high-volume systems, because they are expensive (because of I/O being necessary more than one table). SO put their database into RAM specifically to avoid being hit by double disk I/O costs, and it turns out that even without physical I/O, the double table searching is ...


5

If the server only responds to requests from the client and new interface versions only add new requests (existing requests and responses are never changed), then disallowing newer clients means that neither client nor server need to explicitly support multiple versions of the protocol. In that case, if a version 8 client connects to a version 10 server, ...


4

You do this the same way a clerk in a law office fights unethical behavior, a fast food worker fights unsanitary behavior, or a parking enforcement officer fights police corruption. Be a good example. To the extent you can, produce clean and sensible code. When given a choice, choose the one that meets your requiremets with less downside. (Be aware that ...


4

You're a professional. Your employer hired you to be professional. So, treat your concerns the same way you'd want professionals you hire to treat their professional opinions. In particular, you expect other professionals to make necessary optimizations and corrections along the way, provided those optimizations don't unexpectedly increase the cost. For ...


4

Here are the arguments that, in my view, support the claim that the Single-Responsibility Principle is a good practice. I provide also links to further literature, where you can read even more detailed reasonings -- and more eloquent than mine: Better maintenance: ideally, whenever a functionality of the system has to change, there will be one and only ...


3

There are a number of reasons, but the the one I like is the approach used by many of the early UNIX programs: Do one thing well. It is hard enough to do that with one thing, and increasing difficult the more things you try to do. Another reason is to limit and control side effects. I loved my combination coffee maker door opener. Unfortunately, the ...


3

What makes me feeling bad about your scenario is exactly what you wrote in the headline and multiple times in the question text: You are the lowest developer in the chain Why is that point so important? Well, first of all, and from a purely technically viewpoint, you are certainly right. You are hired as what you call an "implementor" of things, a worker ...


3

Because software is organic. Requirements change constantly so you have to manipulate components with as little headache as possible. By not following SOLID principles, you may end up with a code base that is set in concrete. Imagine a house with a load bearing concrete wall. What happens when you take this wall out without any support? The house will ...


3

The reason that you can't find a one-to-one mapping between the views of the 4+1 Architectural Model and the various UML diagrams is because such a mapping doesn't exist. What all those authors are trying to tell with their 'mappings' is that for each view, there is a different set of UML diagrams that can be useful to convey the information that you want ...


3

We have been told every client will have different import layouts and different columns that identify a table's primary key. Dear lord in heaven, DO NOT let this go into production without establishing a clear standard process for giving each record of importance a single, system-wide, actual key. A key that is of the same format for all customers, ...


3

The default XML Serializer is quite flexible. Ignores (by default) what doesn't know (that's it information on the xml file/stream for which there is no member variable), and what it knows and it is not present (in the xml file/stream), it gives defaults. So, a very dirty way is just to add what you need where you need it. It will work. It will not be ...


3

As david.pfx writes in his comment, there is a bit of info missing, but I am willing to give it a shot. I am making an assumption in my answer. The reason that C and D both want to use B is, at least in part, to use M100Communicator Thereafter it kinda depends on if other modules are around that want to use the ICrt570 interface. Scenario A If it is ...


2

Although I generally agree with Bart van Ingen Schenau's answer, I think a few points need additional elaboration. Th advantage of the 4+1 View Model is that it maps stakeholders to the type of information that they need, without requiring specific modeling notations to be used. The emphasis is on ensuring that all groups have the information to understand ...


2

One of the principles of layered structure is that every layer call only the layer below and receive callbacks. So if the reporting layer does not provide access to this data, it is fair to assume that the data is not accessible from any other layer above. I don't think adding globals is a good idea. It makes the architecture inconsistent and adds very ...


2

For a long time I have been using and recommending the explicit multi-class approach (the second example) as it is the most universal, maintainable, and coherent. Here I will try to support this claim. Single-class This approach has a big problem when there are two or more categories of modifiers. For example a .button with modifiers small, large, huge for ...


2

As Steve Evers states, using an enumeration as a key and either a Class to instantiate (or an instance of Query pre-built) to return. If you don't like the if/else pattern, I know Java has Map implementations, of which the EnumMap would be a good fit (where it optimizes the utilization of Enumerations as the key values in the map. Then your code looks ...


1

It is odd that a 10.1 can't communicate with a 10.0 version (I'd expect at least a major version difference before that happened). The designer probably didn't want the client app to be weighed down by the compatibility layer needed to connect to the older server, while the server can fall back on the older protocol if needed.


1

If a class is too big, it becomes hard to maintain, test and understand, other answers have covered this will. It is possible for a class to have more than one responsibility without problems, but you soon hit problems with too complex classes. However having a simple rule of “only one responsibility” just makes it easier to know when you need a new class. ...


1

The answer is, as others have pointed out, all of them are correct, and they all feed into each other, easier to test makes maintenance easier makes code more robust makes maintenance easier and so forth... All of this boils down to a key principal -- code should be as small and do as little as necessary in order to get the job done. This applies to an ...


1

The best way to understand the importance of these principles is to have the need. When I was a novice programmer, I didn't give much thought to design, in fact, I didn't even know design patterns existed. As my programs grew, changing one thing meant changing many other things. It was hard to track down bugs, the code was huge and repetitive. There ...


1

I follow the thought: 1 Class = 1 Job. Using a Physiology Analogy: Motor (Neural System), Respiration (Lungs), Digestive (Stomach), Olfactory (Observation), etc. Each of these will have a subset of controllers, but they each only have 1 responsibility, whether its to manage the way each of their respective subsystems works or whether they are an ...


1

Especially with such important principle as Single Responsibility, I would personally expect that there are many reasons why people adopt this principle. Some of those reasons might be: Maintenance - SRP ensures that changing responsibility in one class doesn't affect other responsibilities, making maintenance simpler. That is because if each class has ...


1

I'd go with Option 3, with the following notes: Try and reduce the amount of domain logic that your clients need to know to get the job done. Create services that expose that data in meaningful (to your clients) ways, so that you can request collections of domain objects which fulfil certain criteria, rather than doing that crunching on your client. ...


1

I have never heard of an organization that didn't want it's employees to participate. You say that you are only paid to do the tasks. I sincerely doubt you have the right tasks in mind. Because you are paid to write good software. Take this responsibility. Say no to adding features if you can't support the base. Advice the customer with your expertise. ...


1

Since it looks like the questions and the set of possible answers are the same for all users, I would say that it is fine if you share the same data with all the users. You can use composition for this. The only piece of data that varies according to your descriptions is the user's selected answer for every question. As such, a user may have another ...


1

A User may take many Sets of Questions, at different times or even more than once - I think you need a new class here to store: (a) The association of a User with a Set of Questions (Quiz?), possibly at a particular time, and (b) The answers selected by that User for that particular Set of Questions. I would consider a new class, created based on the ...



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