Tag Info

New answers tagged

0

I have done this with XML and it works well: Simply allow any element in your document, to have any attributes and any subelements (and when order is not important - in any order). Beginning from first version of program - when reading document, ignore attributes and sub-elements that you dont know in current version. In future when you are adding new ...


0

My humble opinion is that this kind of bold statements can be wrong, boldly. Will not be possible to use a static class. And won't allow some ways of creating a singleton for instance. Sometimes it is useful and helps the algorithm. But read this post it will help you make up your own decision. ...


3

What you gain by following his recommendations is the ability to accept any object regardless of implementation as long as it implements an interface correctly. There's nothing special about this and it's a commonly-used technique. As the paper points out, what you lose is: The ability to restrict variables to a specific class, which matters when ...


3

I would like to understand the clear reason, Why additionally interface List is introduced? In Java, types form a directed acyclic graph, but classes form a tree. As such, types are strictly more flexible than classes. When designing APIs, you should prefer uses non-class types as much as possible for your parameters and your return types. And pretty ...


6

In both of your code snippets, the use of AbstractList is discouraged.1 The correct usage is to put the new instance of list in a List variable. The abstract classes AbstractList and AbstractSequentialList are provided for the convenience of implementers (i.e. library writers) of list-like containers, by providing default implementations(*) for some of the ...


0

It seems to me that you're just missing a class definition. Declare a class CustomerOrders with GetOrdersTotal method. It's a pure business object. There no such table in the db. It wraps an Order DAO and applies business rules on on it (active order, filter by customer id). So, OrderRepository is your DAL and CustomerOrders is your BL


3

To me, though, it seems like overkill to pass in the time as an argument. You're right, and with mocking you can make the code testable and avoid passing the time (pun intention undefined). Example code: def time_of_day(): return datetime.datetime.utcnow().strftime('%H:%M:%S') Now let's say you want to test what happens during a leap second. As ...


3

It's not because a class should only have one instance in a particular application that you have to use a singleton pattern. That is the key to solving this. Simply only instantiating an instance of the class once and then passing it around to other classes needing it still maintains the singleton as a concept - only one instance - but does not have the ...


1

What is business logic code and what is data access code, and what's the difference? There is a short answer to that: a) Code, that is used to open a connection to a DB, to retrieve data, do OR-mapping etc. is called data access code static public int AddProductCategory(string newName, string connString) { Int32 newProdID = 0; string sql = ...


4

The database layer is intended to isolate the rest of the application from the details of the database -- how to make a connection, the syntax used to talk to the db engine, etc. The .Net Entity Framework version of your code would be: var id = customer.id; var customerOrdersTotal = db.Orders. Where(o => o.CustomerId == id ...


0

Using tokens is very common in APIs, these tokens are usually sent as a header and have a clear life cycle. Think for instance OAuth. Regardless of your programming language or framework, REST APIs are similar. I can think of several scenarios where you want to limit concurrency, two of them are: Multiple clients updating the same resources like a ...


2

Why not put configurable text logging into the C++ product. You can then write a separate program (in any language) to consume the log offline, or in real time, and populate a SQL database. This will decouple the SQL/DB requirement from your C++ code base, and you won't have to compile & link against or even install SQL on most machines. For the ...


1

After thinking about it overnight and looking at Nebu's answer, here are the solutions I came up with: Return only the URI, and accept one a/sync Func. While I do think it's reasonable for an API to return the URI to a video (in case the user doesn't want to download it just yet), I think it's a bit technical to ask him/her to download the source of the ...


1

You might have a look at the PNG file format and how it handles version compatibility. Every block has an id describing what kind of block it is, and it has some flags that tell the software what to do if it cannot understand that id. For example "you cannot read the file if you don't understand this block", or "you can read the file but not modify it", or ...


0

timesSignerIsRequired is not global state, it's a field on your object. It's okay for the methods of an object to access the fields (including private fields) of that same object.


2

A way of doing this can be by using a base class and interface with the basic functions for your file handling. Then use classes for each version that extend from the base class to handle all version specific cases. Functions that can change can be virtual in you base class of abstract if there are only version specific implementations. When you need a class ...


1

Why not make FromYouTubeAsync be a pure function (e.g. which takes a String representing the HTML of the youtube video page, and which returns the URL of the mp4 video file it finds within), and then have the caller worry about how exactly to download bytes over the internet, if you think they want to have as much control over the process as you're implying? ...


2

Your first argument regarding reuse of the HttpClient makes perfect sense. As for the rest of of the requests, I think you're trying to optimize prematurely. That can lead to unnecessary complexity. Also, I'd like to warn you of using the static classes. This is usually a bad idea. It makes your code harder to test and extend. Anyways, below is a design that ...


1

In CQRS, queries are not allowed to have any side effects, and thus they cannot change any data. Commands on the other hand must not return any data, but change the state of the application. With these definitions and your problem domain the question becomes this: What does the search functionality do? If it's purely for finding an order, then it is not ...


0

You could create @property decorated functions. In the setter one, you make sure you have something that calls all the pre-defined callback for said property. This is a visitor pattern really. So, in untested and incomplete code, something akin to this: @ook.setter def ook(self, value): self._whatever = ook for func in self._ook_callbacks: ...


4

From my experience, one of the most important and most far-reaching decisions you make when building a program is how you break the code down into units (where "units" is used in its broadest sense). If you are using a class-based OO language, you need to break all the internal mechanisms used to implement the program into some number of classes. Then you ...


7

Writing testable code is important if you want to be able to prove that your code actually works. I tend to agree with the negative sentiments about warping your code into heinous contortions just to fit it to a particular test framework. On the other hand, everybody here has, at some point or other, had to deal with that 1,000 line long magic function ...


2

Does Ninject provide a configuration-file based approach (like here)? I think if you did that the type would be dynamically loaded, and voila! - no dependency in your project. The drawback is that now you have potential runtime failures rather than compile-time ones, but I think that's what you would rather have in your situation.


1

If you are going with SOLID principles you will be on the good side, especially if extend this with KISS, DRY, and YAGNI. One missing point for me is the point of the complexity of a method. Is it a simple getter/setter method? Then just writing tests to satisfy your testing framework would be a waste of time. If it's a more complex method where you ...


8

It certainly has a cost, but some developers are so accustomed to paying it that they've forgotten the cost is there. For your example, you now have two units instead of one, you've required the calling code to initialize and manage an additional dependency, and while GetTimeOfDay is more testable, you are right back in the same boat testing your new ...


11

At some point the value needs to be initialized, and why not closest to consumption? Because you may need to reuse that code, with a different value than the one generated internally. The ability to insert the value you are going to use as a parameter, ensures that you can generate those values based on any time you like, not just "now" (with "now" ...


4

A quality of well-written code is that it is robust to change. That is, when a requirements change comes along, the change in the code should be proportional. This is an ideal (and not always achieved), but writing testable code helps get us closer to this goal. Why does it help get us closer? In production, our code operates within the production ...


8

It's possible that not every characteristic which contributes to testability is desirable outside the context of testability - I have trouble coming up with a non-test-related justification for the time parameter you cite, for instance - but broadly speaking the characteristics which contribute to testability also contribute to good code regardless of ...


8

It may seem silly to say it this way, but if you want to be able to test your code, then yes, writing testable code is better. You ask: At some point the value needs to be initialized, and why not closest to consumption? Precisely because, in the example you are referring to, it makes that code untestable. Unless you only run a subset of your tests ...


59

Is writing testable code still good practice even in the absence of tests? First things first, an absence of tests is a way bigger issue than your code being testable or not. Not having unit tests means you're not done with your code/feature. That out of the way, I wouldn't say that it's important to write testable code - it's important to write ...


94

In regard to the common definition of unit tests, I'd say no. I've seen simple code made convoluted because of the need to twist it to suit the testing framework (eg. interfaces and IoC everywhere making things difficult to follow through layers of interface calls and data that should be obvious passed in by magic). Given the choice between code that is easy ...


38

Yes, it is good practice. The reason is that testability is not for the sake of tests. It is for the sake of clarity and understandability that it brings with it. Nobody cares about the tests themselves. It is a sad fact of life that we need large regression test suites because we're not brilliant enough to write perfect code without constantly checking our ...


1

This may or may not be a violation of the LSP. Seriously. Hear me out. If you follow the LSP, objects of type ProjectTask must behave as objects of type Task are expected to behave. The problem with your code is that you have not documented how objects of type Task are expected to behave. You have written code, but no contracts. I'll add a contract for ...


10

You want all dependencies to be injected from the absolute top layer, so you should have a dependency graph with a root, and the root has a reference to the concrete implementation of the deps at every node, registers that concretion for the interface in a container, and then grabs just the first level deps it needs from the container. But in doing so, that ...


1

I think you're running into a common pain point while testing and one of the reasons I dislike singleton implementations. Injecting these repository instances is a useful pattern allowing you to substitute test doubles or change the configuration of the API client in the future without needing to modify its implementation. However by implementing it as a ...


0

I don't see these necessarily as opposites. I think of over-engineering as providing options or provisions for capabilities that are not yet or not yet know to be necessary. For example, and method parameter that only has one value that is ever used; an abstract class that has only one subclass. These things add complexity to maintenance and cost time ...


1

One possible solution: Upon execution, create a temporary file and store the status in it. Useful to keep logs as well. Delete the file every time new execution starts and you no longer need it.


0

I thought about this a little bit to see how complicated it would be to have our web server support multiple sessions across multiple tabs. Disclaimer I just had a quick brainstorm about this and I have not done this in practice or even tried to implement something like this. In order to take advantage of everything that cookies do and to not have a major ...


1

"over engineering" means improving a solution when the cost of improving it is higher than the benefits of improving it. And "under engineering" means not improving a solution, when the benefits of improving it would outweigh the cost. Now guess what "right engineering" means... Since a "simple" solution was mentioned, and was somehow correlated to ...


0

I call the two extremes described "under-engineering" and "over-engineering" They seem to refer to the sentence in the link above: In my experience there are two developer character type extremes: the ones that always seek and settle with the simplest solution, and the ones that seek the perfect solution, perfect in terms of efficiency, readability ...


7

When you're doing too much design to solve a basic problem, you're over-engineering. For example, when you're using an abstract factory pattern “just in case” in order to create a very simple object where the business logic is easy enough to fit in four-five LOC, you're over-thinking the design (and violating KISS and YAGNI). Note that it doesn't ...


3

Cookies are primarily attractive because of the ability to store long-lived values and the convenience of not having to explicitly submit session identification with each request (because the browser will). You can also pretty effortlessly hide cookie values from scripts, whereas the same protection over a form field or variable requires a more verbose ...


0

Your teacher's definition completely misses the most important point of object-oriented programming, the one thing that makes it useful and unique. "Message passing" is a bunch of nonsense dreamed up by the Smalltalk folks, and it's been a failure everywhere it's been tried. The true power of OOP is something known as Liskov substitution, and while the ...


7

This seems like one of those common "favor composition over inheritance" scenarios. A RestController serves as an endpoint for REST calls. Not something to govern Authorization. Not something to control the HttpCache. It's a violation of the Single Responsibility Principle. Instead, you should have classes (strategies if you'd prefer) to govern these two ...


0

One example worth looking at involves Java collections. The type hierarchy beneath Collection<T> has quite a few subinterfaces and concrete types. Each data structure has advantages and disadvantages. Sometimes they have additional properties above and beyond the basics of a particular data structure such as thread-safety or maintaining insertion order ...


4

Simplicity. Factory (not abstract factory, just an ordinary one in its simplest form) pattern is useful when initializing a class requires complex business logic. Putting this logic in the constructor is often out of question, and having the logic in a static method within the class leads to class pollution (and sometimes poor discoverability). In a case ...


1

Your concerns are valid. You're using a strongly typed language, yet venturing into a weakly-typed or untyped area. It happens, but this kind of error/constraint checking you're asking about (if nicely addressed) will increase maintainability by returning you to the benefits of being more strongly typed. What I would probably do is analyze the template to ...


1

It depends. If there is some code above this that effectively enforces that the right variables are sent in (some form for example), then this is unlikely to break frequently, so making each message its own type seems like overkill. If there is not some code above this and you're relying on your programmer's goodwill to make sure that stuff is well ...


1

The problem of using boolean parameters to me, is that when you encounter a call to such method, it is unclear what that boolean is representing. You would have to look it up, while I would rather focus on the problem I'm trying to solve. I find it more readable to create a seperate method for it, such as addRequiredTextBox() and addOptionalTextBox() ...


1

From my point of view the method "CanBeAdded" should neither be in the item, nor in a special rulter. It should be in the list itself. Therefore: if list.CanAdd(item) ... end The List implementation then should have a set (probably implemented as list) of rules, that define whether an item can be added. function CanAdd(item) As Boolean for each ...



Top 50 recent answers are included