Tag Info

New answers tagged

0

It depends entirely on what you want. These variations exist for your convenience, not because one way is a better way than another. Personally I'm partial to the non-abstract class, because it requires the fewest number of classes, which in my opinion is always a plus. However, you may find yourself in the situation in which there is an AbstractText ...


0

JavaScript does not support parameter defaults for function declarations. function foo(x) { console.log(x); } foo(); // outputs undefined You would have to add extra code per parameter to set the default value. function foo(x) { if(typeof x === 'undefined') { x = 0; } console.log(x); } foo(); // outputs 0 This becomes a pain when there ...


0

One way to fight the large amount of parameters is a builder pattern + fluid interface. Consider: widget = makeWidget(100, 200) .withSize(384, 256) .withColors(green, black) .withBorder('solid', 'black', 1) .withDialogButtons('OK', 'Cancel', 'Help') This approach groups related sets of parameters so that each set is ...


3

I would say it depends of the language. In a strongly typed language like Java, pasing a Map<String, Object> means that you risk using the wrong type for a parameter. That said, I have seen this been used in frameworks like ExtJS and, for some tasks that require lots of parameters (like initialization, configuration) it is worth it. It actually helps, ...


1

Having the language (eg, English, French, Japanese) so far up in your namespace is a smell. If I were you I'd keep the Language identifiers in the class names only. The recommended structure for a namespace is something like <company>.<project>.<namespace>.<subNamespace>.<andSoOn> So, in your case, you might consider ...


0

The absolute most important metric would be the number of database queries executed. If the ORM's translation of the logical code result in a different number of queries, this will have an effect that will dwarf any other difference. You should be especially on the lookout for "n+1"-pattern where the ORM will perform an individual query for each item in a ...


0

Based on just the info you gave, option 1, because with a single client request you'd be mixing apples and oranges and the fruit basket might be very large. caching is a tradeoff where you gain performance but potentially lose consistency (stale data). If you don't have any identified performance issues, synchronization problems are usually not worth ...


0

As always in programming, it depends. So, the real question is: what should you consider when deciding for A/B/C or a combination of the three? I would say that the real discriminating factors are the implementation details of the 3rd party APIs you are consuming. As an example, you should consider: Are they fast or slow? Do data changes frequently and ...


0

These three options are not mutually exclusive, you can use an combination of both client-side and server-side caches. However some of data, like comments, may become stale, if kept in cache for too long. Considering you can't check whether that is the case, you should probably refrain from storing it at all. On the other hand content usually doesn't change ...


0

The question you should be asking yourself is if the effort saved on maintenance (by not having to change code for future user requests) or the additional versatility (such as being able to easily convert and market the app to different users) are worth the additional effort of creating a more generalized system. Don't write a universal condiment dispensing ...


0

JDT's answer is pretty good, but another option you might want to consider is a domain-specific language (DSL). In this approach you define a simple language to capture your workflows, provide primitives for specialized checks and steps, etc., and then write an engine to interpret and execute them. By keeping everything in a database, or hard-coded, you ...


3

I can think of two possible solutions here, but they both require a fair amount of development (but I really can't see a solution where this is not the case). I would also recommend not developing any specific kind of check step until it is actually needed. It's very easy to have requirements for 42 different kinds of automated steps that end up having only ...


0

The response to this question is highly dependent on the organization of each company. As mentioned, the ideal is that the technical documents are written by the Software Analyst, after having discussed with the software developers/engineers of the project. However, when there is no Architect in the group, the workload has to be shared. In other words, why ...


0

I would (almost) discount option 3. Choosing between 1 and 2 depends on two things: (A) how big the result of a single, total fetch is (B) how much of the detail of the result the client/user will typically use in that session. It's easy to make a decision if A and B are extremes: If A is large and B is small, definitely go for option 1 (A la Carte). ...


0

At my current job, we have BAs who are more technically inclined than where I've worked before, but we still have never expected them to write technical design docs. Developers always wrote those, and then architects signed off on them. In support of xmojmr's comment, though, I would point out that while we were very diligent about documentation during our ...


0

If you're using dependency injection then using the Factory Pattern hides the dependencies of the object you're creating from the consumer. For instance: class MyClass { MyClass(IDependencyA dependencyA, IDependencyB dependency) { ... } } If you want to create this directly, you do: var myClass = new MyClass(dependencyA, dependencyB); That means ...


9

Unless the BA is also an technical architect, they should concern themselves with the "what it does" not the "how it does it". As a result, the BA writes the requirements and the technical architect writes the solution, and the developer writes the code. Sometimes (or quite often) these roles are shared by someone, so a dev could also be the architect of ...


2

bbatsov/clojure-style-guide suggests some good rules on how to use namespaces: Use one namespace per file. Use the ns form for representing namespace dependencies. You should almost never need to use load in regular code. Prefer :require :as instead of :refer or :use. This makes it easier to see what you are using from which namespace, and your code ends ...


4

Requiring a reboot of the application when the database goes down is definitely a bad design, because it increases maintainance effort which will negatively affect your uptime. A good design would try to reconnect to the database every few seconds so business can continue as soon as the database is available again. In the meantime, returning a "500 ...


4

Addition of many elements to the end is O(m + logn), where m is the number of elements to be added. These operations would be O(n + m), and if m = n then they are almost as fast as addition to the end. In practice, they would be many orders of magnitude faster than if the user implemented them naively. However, for small numbers of elements, they would ...


0

For a simple application, I think that using a static attribute is a decent solution. However, I would recommend you make it private and only provide a getter so that you restrict the scope where the configuration can (unintentionally) be changed to the main entry class. public final class ApplicationMain { private static String name = "default ...


1

Using global variables is a really bad idea. Why not pass the parameter as an argument to a function or inject it at class instantiation? As function argument public class Consumer { public void generateReport(String param) { System.out.println("Reports Generated based on " + param); } } public class ApplicationMain { public static ...


3

Why can't you use the same structure as in your bullets? <topLevelTag> <item id="1"> <value>ItemName</value> <category level="primary">foo</category> <category level="secondary">bar</category> </item> <item id="2"> <value>ItemName</value> ...


0

There are at least two questions being asked here (arguably a lot more, so I'll have to ignore many of the little ones), but the solution to both comes down to writing a class that effectively encapsulates retrieving (your) data from (your) files. Since you specifically asked whether it should be a class or something else, in this language classes are the ...


0

I would pass it in as an argument as you've done in your example. You could have a singleton ApplicationConfiguration class that you would populate in the main method with your passed in arguments, and other areas of the code would get the values out of that object. This answer does a good job of explaining how to properly use the pattern for this purpose. ...


3

In proprietary software you want to hide implementation details, while in free software you don't care (and you would accept someone extending your library in unexpected ways using the implementation datails). I also think it is related to the notion of leaky abstractions, and since you commented that your library will be free software, I would suggest ...


1

is it right to include system timer performing sms sending in the use case diagram shown below? If not, what should I replace it with.? Actors in use case diagrams don't have to be humans. It may as well be another system or the system itself. I would replace the "system timer" box with an actor labelled "Alerting system" (or whatever your system is ...


5

Using function names to differentiate among n true/false behaviors will result in 2n functions. This is easy to manage when n is a small value like 2 or 3, but it gets out of hand very quickly with anything greater. The POSIX open(2) call has nine true/false variants, and if that were written as one function per combination, you'd be staring down 512 ...


3

The amount of variables (and hence, the magnitude of the combinatorial explosion) can be reduced with a more general and modular API. For example, instead of making Find support substrings, create a separate function that takes a substring out of a string. Instead of returning either the start of the end of the match, always return the start and make it easy ...


1

...Is this design desperately wrong? No. You can serialize circular references using JSON I don't know what's the Python-approach. But from the specification point of view I've heard that json pointer fragment might be the internet search query Wikipedia → JSON → Object references is not very clear on this subject and emphasizes the implementation ...


1

To avoid circular references, only a parent node/class should know about it's children. Accessing Game as the root node should allow you to gather information anywhere you need.


2

Although I have not worked in this area, it seems like this is the type of problem one would use something like Apache Giraph to handle. You essentially want a huge population of "things" which you suspect are "related" to each other possibly across a large number of dimensions, and you want to pair them up optimally based on the strongest matches. You ...


1

Two things could help you there: Instead of Use Cases, User Stories. Why? Well User Stories are written for/by the user. They are not an accurate description of functionality, but do specify what the user wants to do. This can be your initial road map into writing code that actually allows the user to do something, rather than comply with system ...


0

A test fundamentally tells you, "If I supply input X to program P, I get output Y." Test driven development works by writing X and Y first then filling in the gap. Work backwards. The program will produce some outputs. Whether these are control signals, images, web pages, text, lamps, toast, whatever: outputs. Produce some representative outputs by hand. ...


3

You cannot jump directly from "idea" to "implementation". Good example is the "V model" : You start at high level go lower and you write tests on each level. And each level gets more specific in both implementation and testing. For example you write an acceptance test that says that you should be able to add a customer. This results in you writing an ...


0

Cannot quickly find any links, but I was taught that naming something an XXManager is a "code smell" and you should strongly consider naming it XX. Why do you want an Anemic class XX with a separate XXManager? Sometimes it makes sense to have a separate manager, e.g. if you are religiously following MVC, or a Database is involved, but is that the case ...


3

Structurally, I would reconsider the notion that a post belongs to a category. That's a strange way to model the relationship, especially considering a post very well may form a relationship with multiple categories. So in my mind a post has multiple categories. As @James Anderson initiated, you shouldn't think about your API as a result of your persistence ...


1

While I agree with James, sometimes for whatever reasons you may want to have objects, so as to have a better representation of the actual data. In those cases, there are two considerations: Having just CategoryId, if you laways or almost always need the name, will require another request; Having both options is pretty useless since Post.CategoryId is not ...


4

I think you are starting from the wrong end. API design is about what the client/requester requires not about how you represent the data internally. If the client need the category name then just provide it along with the id (if its useful to the client). As a Post belongs to only one category there is no reason to have anything other than a flat structure. ...


1

I wouldn't implement deleting usernames in this fashion by using a boolean flag. You are correct that there are problems with implementing it this way; specifically, what happens when another user registers that username? Do you simply set the deleted flag back to true? What happens if that user then deletes the account? Your historical record has vanished! ...


2

Both of your designs have the problem that they put the burden of keeping track of the validity of the favoriteColor attribute on the user of the class. Your second design (with the getHasFavoriteColor) has the additional problem that it duplicates the information if there is a valid value for favoriteColor in a way that makes it very easy to create ...


0

I don't know C++ but I hope my idea helps you to resolve your problem. Create your model class based on your XSD file. class Person { private string name; private string favoritColor; public Person (XmlElement person) { // parse the XML element and assign the values to appropriate element // if the element does not exist, don't assign ...


0

Writing use cases with (say a Product owner) could perhaps get you started. The problem for me is that "conception" in your graph and unit tests are on different conceptual levels. Unit tests are on a very low level (and are best viewed as a code design tool), they do not dictate or guarantee system level features. I would start by writing automated high ...


2

You mention a 2000 lines update method. I'd start to read this method top to bottom. When you find a set of statements which belong to each other, i.e. share one responsibility (e.g. create a user), extract these statements into a function. This way, you don't change how the code works but you shorten this huge method gain a better, higher level ...


6

Interestingly, refactoring is the most efficient way I've found to understand code like this. You don't have to do it cleanly at first. You can do a quick and dirty analysis refactoring pass, then revert and do it more carefully with unit tests. The reason this works is because refactoring done properly is a series of small, almost mechanical changes, ...


2

There is no general recipe, but some rules of thumb (supposing a statically typed language but that shouldn't really matter): 1) Take a look a the method signature. It tells you what goes in and hopefully comes out. From the overall state of this god-class, I suppose this to be a first pain point. I suppose, that more than one parameter is used. 2) Use the ...


4

First, a word of caution (even though it isn't what you're asking) before answering your question: A tremendously important question to ask is why are you wanting to refactor something? The fact that you mention "coworker" begs the question: Is there a business reason for the change? Especially in a corporate environment, there will always be both legacy and ...


0

I prefer the iterative refactoring approach. While we are developing the application usually our focus would be on the functionalities. Once, there is a code we could look at it and refactor it to make it more readable. To answer your question on approach (methods for deciding where to place a code) - Ask the questions that you will ask while refactoring ...


0

API first Engineers from both teams should work together on the API between the front-end and the back-end. Then both teams can start working based on the designed API. This has the advantage that another front-end team can also start the work (maybe mobile, after web client) besides the obvious advantage that teams can start working in parallel. Combine ...


0

Expanding on my comment: First gather requirements, then turn them into Use Cases & design. First comes a detailed database definition. I don't care if the client doesn't fully grok it, I force them to sit down & look at it - and sign off on it (possibly then forcing then to realize that once of their more tech savvy guys ought to do so), before ...



Top 50 recent answers are included