Tag Info

New answers tagged

1

Generally all nouns should have their own class, a model in the case of using the mvc pattern. User and order are two separate things so you should have two models. However, they are related so your data model should have a key or bridge table to relate users with orders. A user has orders but a user is not updated from an order but more precisely an order ...


2

Under normal circumstances, cyclical references are not a problem for the GC, because it can detect them. But here, the whole object graph looks like this (based on looking at the reference source): So, the problem isn't just the cycle, it's that you have a static field that references the cycle. What you could do to fix this is to break the cycle ...


1

Consider a class that implements IDisposable, but when it is not disposed by its user, it will not become eligible for garbage collection, thus its destructor won’t run, and resources will be leaked. Your presumption is incorrect. All classes are disposed and a properly written implementation of IDisposable will not leak resources. To be absolutely ...


0

If your class contains a IDisposable field you'll need to make that also IDisposable so it can be explicitly Dispose its own fields. Or otherwise guarantee the Dispose happens eventually by adding a Finalize method. Note that using the destructor for cleanup is not enough because they are not guaranteed to run (at least not in java). class Cyclical: ...


1

I think the performance cost of 1 copy versus 3 for an API being hit "hundreds of thousands of times per day" is fairly negligible; either way, they must both share some of the same resources, and be subject to the same potential bottlenecks. What I'd be more concerned with is the additional cognitive overhead of having 3 APIs, in terms of server ...


0

I'm not sure I quite follow what you're doing (like what does "file is sent for 'processing'" mean -- processing?). Maybe that's not all that important for the context. I guess my first instinct would be to ask why your "processing" can't happen on your app server (as part of the upload process). Then, whatever scaling solution you use for your app ...


0

Meeting the requirements, including performance requirements, trumps all other design considerations -- language, maintainability, readability, scalability, time to implement, coupling, etc. Either it works or it doesn't -- if you have to crank out hand tuned assembly in order to make it work, then that's what you have to do. Only when there are tradeoffs ...


0

In line with RAII, I would certainly make sure that you had a reference-counting smart pointer (shared_ptr) instead of a raw pointer. Besides that, there's nothing inherently wrong with what you've described. However, as many people have noted already, it is impossible to give an accurate answer without two things: Code. Are you turning your code into an ...


0

You're going to need to bust the assembly when an item within it is sold. Add the remaining items from the assembly to inventory and subtract the case. This will effectively balance out your inventory. As per request via comments, I will adjust my answer accordingly. We can use your 'Cola Can' example to help us visualize. We all know that you can buy ...


2

This is basically question of Composition vs. inheritance. In your first case, you use inheritance as way to share behavior. In second instance, you use composition. Also, in second case, it is easy to identify a Strategy pattern in IDownloadClient. So some would say the second case is better. But there is also KISS and YAGNI. Your second case is already ...


1

I need a way out of this conundrum, one that has the smallest technical cost in relation to changing the other controllers, I need a sort of "structural polymorphism" for these types, where the type is the same but its internal structure different. You mean like basic inheritance? I'm not sure I see the trouble here. If you have a common set of ...


0

Decoration is about adding subtle behavioural changes to an underlying class. I think your intention is to actually Extend a class. Think "Separation of Concerns". Also, the "Open/Closed" principle springs to mind (which I personally don't entirely agree with) The point of decoration is that you pass an object around which supports a given interface. If ...


2

The decorator pattern is typically used to avoid an explosion of subclasses. A common example involves ui windows that you may want to have any combination of n attributes (scrollbar, titlebar, resizable, movable, etc.). Supporting all combinations of those n attributes would involve making 2^n subclasses. The decorator pattern prevents the explosion by ...


2

Disadvantages are that: it is not obvious where it is used when you use something that uses it, you cannot supply alternatives (esp. when testing, you do not want to use eg. real credit card payment) when you decide that you want two contexts in which it should be unique you must rewrite every usage. These disadvantages are sometimes acceptable, ...


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 ...


0

The most interesting concept to follow here is a Single Responsibility Principal. It does mean you need a dedicated classes for each aspect/behaviour/state. I would go with: public class Product { public string Descripion { get; set; } public Uri Thumbnail { get; set; } } ProductFormat -> to choose Short/Full/etc. public abstract class ...


0

I would offer that there are actually far more than just the two meanings you provide for high level and low level, depending on the context of the conversation. In computer science, there is indeed high level and low level design, which would refer to the abstraction you are discussing, as well as the broadness of responsibility of a component in the ...


1

The first thing I can suggest you is to take out the Logic from Mark-up or basically avoid to write in-line logic in your mark-up. So you can re-write your first example like this: if ( in_array('name', $error) ) { $class = 'form-error'; } else { $class = null; } // or ... $class = in_array( 'name', $error ) ? 'form-error' : null; if ( isset($name) ...


0

Your wrapper may have some logic inside to deal with the template. And basically all STLs are templates by themselves. This doesn't shock me. Imagine you want to have an array of objects "Cars" and other of objects "Bicycles". Same structure but different data manipulation.


0

I agree completely with Chao's answer and so I will not repeat that. I think that the real problem here is that you need to ask yourself some more fundamental questions about the problem domain. Remember that all code is written to solve a problem. Why are we writing a base Documentclass in the first place? Why are we deriving from the Document class? ...


-1

You can create a base Model which will have the general queries and other models can be inherited from the base model and will contain specific queries to that model.


3

It depends on the nature of those custom operations, but probably yes, it's bad design. And the main reason for stating this is that you are coupling operation and storage. If a certain custom operation is semantically independent, it can be better implemented as an standalone (functor) class or function, taking an specific container parameter. Moreover, if ...


0

I've preferred to derive from the STL to add functionality and also hide the templating. So rather than use the vector as a member variable, I would derive so that my CustomVector is still a vector, and all the methods that are available on a vector, are also available on my CustomVector. Also, any method that can work off a Vector will also work on my ...


1

I wouldn't, I'd rather see a class that is a vector if its basically just a vector with 1 or 2 custom functions. For these custom functions, I'd say its better to make functions that operator on the type, for example all the methods in . You might find this approach is a little more generic and so encourages reuse across your wrapper classes. However, if ...


2

Embrace refactoring. Embrace the fact that you can create code that works, and you have tests that make it work, and then you can change the internals having confidence that you are not breaking anything. And as you mention, KISS. About the view of not having written/designed correctly from the start, for me the answer is that I have not worked in a project ...


0

I'd say the exception. Every time you refactor, you're basically changing the way the code looks rather than the way it works (eg you might extract a block of code into a method, or change a switch to a polymorphic function call, in all cases the functionality hasn't changed, you've just altered it). Now while this maybe useful to make the code easier to ...


4

I think the answer lies in between the two of you. Changes are to be expected as software evolves. No matter how competent you are, you can't predict the future with 100% accuracy. And even if you could, it may not match your customer's predictions or taste. Since he's the one who pays he (most unfortunately :) ) has a say in it. So unless it's dead simple, ...


1

It all come down to who writes better code relative to the amount of time. Your company/team should define what "better" means. Customers have something to say about this as well. Make sure you have a solid definition of Refactoring. It sounds like you do, but you mention it along with code behavioral changes very close together in your question. Be ...


1

If you can get to a usable working solution in only 3 iterations, you're doing well. The number of iterations and the amount of refactoring per iteration is highly dependent on the nature of the problem, how well you understand the specifications, how well the end customer knows what they want, and so on. Some companies will iterate a lot more than 3 ...


1

From what I understand your question to be, it seems like your Data Access Layer classes were accessing the Common Assembly and then your Business Layer accessed your Project Specific Data Access Layer. Now you want to put some of your Common Data Access layer classes into the Common Assembly. You think it is no longer OK for the Business Layer to access ...


2

This exact problem is why Dependency Inversion Principle exists. This principle says. High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. In your case, the business layer depends on detail that is data access. To fix this you ...


3

Consider using delegates instead of abstract classes. The Template Method pattern is mostly a hack to work around a language's lack of first-class functions. So instead of overriding "execute", pass it in as an argument. That aside, why don't you want dependencies between assemblies? What good is your Common assembly if you're not going to use it?


3

The pattern you describe is what I know as MVP, Model View Presenter. This is an alternative to the MVC in that the Presenter contains the logic for updating the UI code without the View requesting the data from the Model. The traditional MVC pattern does indeed allow for the View to know of the Model. When to favor one over the other? Purists will ...


0

The first approach seems totally off to me. You're clearly violating the Single Responsibility Principle in your Model design. Maintaining and extending the Model will be harder and less efficient. Also writing meaningful Unit Tests could be quite painful. In your second design you're implementing the Strategy Pattern and it's a good mix with MVC. I prefer ...


0

In short: you are on a right track and second design is more suitable to MVC pattern. Because in MVC pattern we should keep business logic in the Model. Also having 2 controllers with single view is also violation of single responsibility principle. It would require a rework if there would be any change on UI (either if encryption or decipher changes) I ...


3

A factory method is essentially just a constructor with another name. This can be useful e.g. to guarantee correct initialization, registration, or to supply default values without having to subclass the product: private List<WeakReference<Product>> products = ...; public Product makeProduct(Param x) { Product instance = new Product(x, ...


6

I don't think they are suggesting it for speed. Sending emails becomes a problem when you need to send a lot of them from a single IP. That IP might end up as a spammer and so your emails will not be sent anymore. Also if you try to send an email and it bounces for some reason, you the sender, must resend it, and check again if it fails and if so, send it ...


0

According to Uncle Bob in Clean Code this is a typical example of when to write more procedural code and less object oriented. You want the flexibility to add "data structures", so you need to put the logic elsewhere. Data/Object Anti-Symmetry Procedural code (code using data structures) makes it easy to add new functions without changing the ...


3

You could extract this to a separated service that has the only resposnsibility to track Container<->Item associoations. I think this is a very flexible solution. class Container<T> { private IItemAssociations associations; public Container(IItemAssociations a) { this.associations = a; } public void Add(T i) { ...


1

internal would be a fine solution here since container and item are inextricably linked, they're going to be part of the same assembly. That said, this is a code smell. Items should generally not know if they belong in a container, let alone being restrained to only one container. This is a coupling nightmare since items will then inevitably go back to ...


0

They are generally same thing. If you read What is the Dependency Inversion Principle and why is it important? and Dependency Inversion Principle, you will realize the two "principles" talk basically about the same thing. High level modules should not depend upon low-level modules. Both should depend upon abstractions. Abstractions should never depend upon ...


2

TDD is not design - it is a design process. A main artifact a TDD process eventually give you is the unit test suites, which should (to some degree) attest to the actual code's scope and capabilities. Good test suites give some assurances that the code works, and added security that future code changes can be done without breaking past code, as failing ...


2

Sure, these things exist. D-BUS comes to mind, or any number of messaging frameworks (RabbitMQ , AMQP, ZeroMQ, etc). They're all variations on a similar theme. Increased latency compared to directly-connected peers, and increased complexity for complex topologies. The biggest one I can think of is the ability to extend to multiple WANs and scale to massive ...


14

"Program to an interface" means don't depend on a concrete type to do your work, but it doesn't specify how you should get your dependency. The "Dependency Inversion Principle" says that an object shouldn't control the creation of its dependencies, it should just advertise what dependency it needs and let the caller provide it. But it doesn't specify ...


1

Interfaces are one way to implement DI. If you specify an interface as a parameter in the constructor method of a class, you can hand any object you like to that constructor method, so long as that object implements the interface of the constructor parameter. In other words, programming an interface allows you to change the implementation of that ...


-3

I would consider the behaviours of passengers. E.g. if you don't want behaviours provided by basic types it's better to create custom types...


0

I won't answer to your question, but I think that an issue is created by the terms you have used. E.g. XmlReader.read => twice "read" I think you need an XML so I'll create an object XML that can be created from a textual type (I don't know C#... in Java it's called String). E.g. class XML { XML(String text) { [...] } } You can test it and it's ...


1

I don't know if my solution could help you, but I think I create an abstraction: interface ImageEffect { Image apply(Image source); } and then: class EdgeDetection implements ImageEffect { ... } class GaussianBlur implements ImageEffect { ... } But, if you have only 2 or 3 effects I think you could simply create an object: class Picture ...


1

You could do either, so this is primarily opinion based. If you start with the backend, though, you should have unit tests, certainly, but also some sort of test harness that can simulate whole-flow calls to the backend. If you start with the GUI, you should have stubs or mock implementations of the backend to test your GUI against. Don't create a real GUI ...


3

It is really important when implementing a backup solution that the focus is not on the backup process, but on the restore process. It is the ability to get the data back into a working environment that matters, not the filling up of cloud hard drives and LTO tapes. In that respect, when backing up databases, OS directories, MS Exchange etc... taking the ...



Top 50 recent answers are included