Tag Info

New answers tagged

0

Member variables are variables are a "has a" relationship (the rectangle has a width). If the object does not have the variable then it should be passed into it to be used where required, if it's related to the object itself then it should be stored in the object. A quick way to test the relation could be seeing how much that object uses the variable. If ...


0

If the wrapper is truly immutable, program behavior is identical whether you create a new wrapper each time, or reuse one. The only difference is the thrashing of the garbage collector. I have thought about using structs as read-only collection wrappers, instead of class instances, but I realized there would be little gain, since often a collection is cast ...


1

In both designs, MainClass has to know about ClassB and ClassC (and any future derived classes) to provide the methods to create and add new list elements. This makes that with the current interface for users of MainClass the first design is the simplest design and the best of the two. However, it is possible to create a better design by decoupling ...


0

Treat every chat like a group chat with each device or web browser tab as a subscriber to the group. Use web sockets for all clients.


0

Many ejabberd and mongooseIm users have faced this problem. They have managed to cover up for most of the essential features, but some specification like file transfers,location tracking etc dont come out of the box with erlang based chat servers like ejabberd and mongooseIm. But the makers have provided users with the luxury of extending ejabberd's ...


3

The Head First series is quite good in my opinion, try Head First - Design Patterns Pragmatic Programmer also comes to mind. As mentioned by rwong: Clean Code Code Complete, 2nd Edition


0

Maybe my blog article can help you Basicly it uses a template engine to render the backend Commands and Queries into java script objects. In this case .NET T4 templates, but maybe it can give you some ideas. You benefit from contract safty and code completion during design time


-1

Right-biased Either. It can't be ignored, it must be handled, it's completely transparent. And IF you use the correct left handed error type it conveys all the same information as a java exception. Downside? Code with proper error handling looks disgusting (true of all mechanisms).


1

I would use option Change the API so every request for an image returns the image + a status information. If there is no image, you return a 0 byte stream for the image and a status like "no image available". So the user of the API needs only one roundtrip to retrieve the full information, the operation is atomic, you don't return an error for a valid ...


1

I would prefer option 1. This would involve expanding your current definition of an Incident to contain a hasImage flag so that the client can decide for which Incidents to call the image fetching API (eg, getIncidentImage(...)) Thos covers modelling and API design. As other people have mentioned, from a UX perspective, you might want to include a ...


-1

Personly I would just send a generic image / place holder such as


1

It depends on the technology you use. Normally in this case you would return a Type that describes the possibility of an image. In some languages these types are built in (Option in Scala, Maybe in Haskell). In other ones you can write them yourselves or use a library that includes these types. For javascript (which may be what you can use, I guess), you can ...


0

You can't have both without restricting your user: allowing users to create the URLs freely AND having collision-free URLs for each module. If you want to allow users to create URLs, you may check if the entered URL is already in use through doing self-queries but that would still result in having the user restructure the URL catalogue in case there has ...


11

Since you are using this information for billing purposes, I do not see why you would not want it in the database where it can be easily queried, aggregated, reported on, and joined to other data. I also think it's much easier to maintain a single database table containing the log information than a bunch of separate log files. Same with your concern ...


1

Elaborating a bit on Snowman's answer, I think I would go for a hierarchy of hash values over (exponentially) increasing subsets of the file, computed on-demand whenever collisions occur, and memorized in a suitable data structure (hash table, but even a simple prefix tree would do) for quick future access. This should ensure quick failure in case of 'almost ...


1

Data deduplication is also often called "record linkage", so you may want to also use that as a search term when researching this. There is an article on the Eventbrite engineering blog that explains how you could greatly reduce the number of file comparisons by using Multi Index Locality Sensitive Hashing. In short, you create a special kind of hash value ...


2

Your approach is good... if the files have completely random data. Here are some things to consider: How bad is it if there are collisions? If you need a mission critical guarantee (e.g. those astronauts on the ISS will die if a collision occurs), your algorithm may not be good enough, even though there are 10^38 possible MD5 hashes. People do win the ...


6

It sounds like you are trying to optimize the file comparison because that can be a potentially expensive operation: If two files have different sizes, they must be different files. If the first and last 4K of two files hash to different values, they must be different files. The first portion will check stuff like a file identifier commonly included in the ...


0

Without some knowledge of the nature of the files you cannot be sure without hashing the entire file. Checking the file size and hashing only a portion of the file contents is sufficient only if you can guarantee that the contents will be unique in the hashed portions.


1

In the code: Validate in the setter the collection has at least one item, and raise and exception if it doesn't. In the database: Create an episode_image table. That table would have a foreign key with the image table. Unfortunately, there's no way to enforce that for every row in the parent table, there's at least one corresponding row in the child ...


1

You are asking two very different questions. The former one is not a generalization of the latter, because answering the first won't answer the second. There are many other things that might influence the second question, like how you would tackle transactions with multiple users and such. As for the first question, everybody agrees that a shorter ...


2

Are there any clear (measurable?) guidelines (besides "it depends") for setting the degree of explicitness/inderection. Not many. The first is the Law of Demeter, which focuses on how many "steps" it takes to get to what you want, which directly relates to your question about indirection. Another is Tell, don't Ask. If you have some implicit state ...


0

There are a few options: Just use a regular ICollection, document the fact that it must be non-empty, and enforce this in the setter. In the database, you would have a episode_images table. This doesn't provide the compile-time safety you're seeking, but in my opinion it's the only reasonable option. You could store a FirstImage field and a OtherImages ...


2

First you have to decide if it is sufficient to have runtime safety about the number of images or if you want to have compiletime safety. Runtime safety Achieving runtime safety is quite easy. All you have to do is remove the default setter for Images and implement a setter that performs a check before saving the given ICollection<string> argument ...


1

If it's a very simple app where the object is more or less tied to the datastore and visa-versa (i.e. can be thought of as a property of the datastore), then having a .save() method for that class might make sense. But I think that would be pretty exceptional. Rather, it's usually better to let the class manage its data and its functionality (like a good ...


-2

Define a method on that class that serializes the object, and returns a sequence of bytes that you can put in a database or file or whatever Have a constructor for that object that takes such a sequence of bytes as input About the RetrieveAllStudents() method, your feeling is right, it is indeed probably misplaced, because you might have multiple distinct ...


0

Depends on what you call an application. If you mean, an interactive program where you need to be certain that the real-time behaviour is exactly such and such under any given circumstances, then it's basically impossible to proove there aren't any bugs in it. I suppose it would be possible if you could solve the halting problem, but you can't. However, if ...


4

Not all bugs are created equal so you need to sort out the wheat from the chaff. Expectations Many bugs are raised simply due to a shortfall in what the software does and what the end user is expecting. This expectation comes from many areas: using other software, incorrect documentation, over-zealous sales staff, how the software used to work etc etc. ...


0

Defects have existed from the beginning of software development. It's hard to tell from your question to what extent and what severity the defects effect the usability or functionality. Defect-free programs exist, but just about any non-trivial system will have defects. You will have to decide upon some sort of prioritization and likely will have to ...


14

The closest you get to a bug-free application, the more expensive it gets. It's like targeting 100% code coverage: you spend the same amount of time and money getting from 0% to 95%, from 95% to 99% and from 99% to 99.9%. Do you need this extra 0.1% of code coverage or quality? Probably yes, if you're working on a software product which controls the cooling ...


0

From a different perspective, it is my experience that most programmers/developers do not plan for success and the "prototype" is almost always becomes Release 1.0. I have first hand experience with 4 separate original products in which the classy, sexy, and highly functional front-end (basically the UI) resulted in wide-spread user adoption and enthusiasm. ...


2

It is absolutely fine to have an interface that doesn't communicate how the implementation works. In fact that is the point of an interface, to hide implementation details! Your second option is fine in this scenario.


2

Getting the original investment According to my experience, the most difficult part is to get the original investment, because investors may be reluctant to give you money with no commitment from your side. What if your research leads to a dead end? What if it requires much more money than they can give you? Ordinary business projects, even Agile ones, are ...


2

In my opinion the former makes more sense if there's not much you can sensibly do without knowing whether you have an A or B. If you wanted to unconditionally get the string with the former declaration, you'd end up with redundant cases in the pattern match. Of course, you could easily write a function to do it. I would imagine the latter is easier for ...


1

I worked at a place that had a fair amount of independent data sources. They did put them all into a single database, but into different schemas that were accessed by webservices. The idea was that each service could only access the minimum amount of data they required to perform their work. It wasn't much overhead compared to a monolithic database, but I ...


2

I wholeheartedly agree with btilly's answer, but just wanted to add another positive for Microservices, that I think is an original inspiration behind it. In a Microservices world, services are aligned to domains, and are managed by separate teams (one team may manage multiple services). This means that each team can release services entirely separately and ...


1

You can store the value as a number if you have a datatype that can represent more than choicescount possible values. In the case of 340, this is the number 12,157,665,459,056,928,801 which is just under 64 bits. So, you could hypothetically store this in a Unit64 (docs). This isn't a good idea. As soon as you add another question, you will overflow ...


3

An int represents a fixed number of bits (usually 32 or 64). This is a measure of information content; it is fundamentally impossible to store more than this number of yes/no decisions in it. With three-way decisions the arithmetic becomes slightly more involved because they represent fractional numbers of bits (two three-way questions contain slightly more ...


25

Single Responsibility Principle, Separation of Concerns and Functional Cohesion. If you read up on these concepts, the answer you get is: Separate them. A simple reason to separate the Student from the "DB" class (or StudentRepository, to follow more popular conventions) is to allow you to change your "business rules", present in the Student class, without ...


2

There are quite a few patterns that can be used for data persistence. There is the Unit of Work pattern, there is Repository pattern, there are some additional patterns that can be used like the Remote Facade, and so on and on. Most of those have their fans and their critics. Often it comes to picking what seems to suit the application best and sticking ...


7

Both approaches violate the Single Responsibility Principle. You first version gives the Student class to many responsibilities and ties it to a specific DB access technology. The second leads to a huge DB class which will be responsible not just for students, but for any other kind of data object in your program. EDIT: your third approach is the worst, ...


0

I have been pondering the same recently, and my tentative conclusion is that the mere question arises because the .NET Exception hierarchy is severely messed up. Take, for example, the lowly ArgumentNullException which might be a reasonable candidate for an exception you don't want to catch, because it tends to indicate a bug in the code rather than a ...


1

You're basically using a mediator pattern. To start, be aware that you might be overusing it if you're using it everywhere. Event driven programs can be harder to debug or to even reliably predict behavior, so you'll want to use this pattern only when there's an actual pain caused by the normal coupling. For a modal I very much doubt I'd use it. With that ...


0

Version 1 is better than version 2. The reason for that is, a car should not know anything about an owner or any tickets. As cars are objects in our real world, think about it: Can a car exist without having an owner or tickets? - Certainly yes. Therefore, remove those from car and make car an independent class that is only dependent of what it is ...


3

If a property meets the following criteria then I make it a constructor parameter: The class is dependent on it for operation It has no reason to change over the lifetime of the object Its value is known at object creation If it meets these criteria, then it's a constructor parameter. If it only meets one or two of the criteria then it's almost ...


5

The decision which parameters a constructor should have is the same decision which parameters an arbitrary function should have - it should have exactly the parameters which are needed to create a specific, ideally easy to understand, abstraction. And if your abstraction of a car encapsulates exactly those three things, version 2 reflects that much better ...


1

IMHO, it depends upon the parameters. I've used DI to inject cross cutting concerns, such as logging and session management. I think this is good use of DI as the magic of DI does not affect the class-specific logic. Injecting instance specific parameters seems to be asking for trouble. Not the least of which is someone else trying to work out how your ...


13

Let's talk positives and negatives of the microservice approach. First negatives. When you create microservices, you're adding inherent complexity in your code. You're adding overhead. You're making it harder to replicate the environment (eg for developers). You're making debugging intermittent problems harder. Let me illustrate a real downside. ...


2

expose the existing complex data model without introducing DTO classes One major flaw of this approach is that of coupling data access layer with API. It can go very bad very quickly if those models are used elsewhere except API. I currently work on a project where both web interface and JSON API (kind of REST, but not quite) use the same Hibernate ...


4

The key in understanding MVC lies in the separation of the responsibilities, as MVC is simply SRP applied to UI code. It separates what data has to be displayed, from how to display it, from how to handle screen events. But an important (and often missed) detail of the original definition of MVC is that it was designed for a far more granular level. For ...



Top 50 recent answers are included