Hot answers tagged

18

This is clearly a misunderstanding, the author does not mean "pattern" in the sense of "GOF design pattern". He does not even talk about "patterns in your code", but patterns in the problems you are going to solve with your code. So to express his recommendation in other words: one should try to write code which solves a whole category of problems instead ...


7

If you want a TrajectoryPrinter ask for a TrajectoryPrinter. Right now you're only asking for doubles. Something will need to build Oscillator. Something will need to build TrajectoryPrinter. I don't recommend that Oscillator build or even find TrajectoryPrinter. Oscillator shouldn't know TrajectoryPrinter as anything except as something it can call a ...


6

View is a layer responsible for displaying information which may be interpreted by a user/client of your application (it does not say the user has to be an actual person). JSON is completely valid format for a view layer, computers understand that. As long as the view layer publishes information which can be used by a user to affect models in your ...


6

This is pretty vague, and the author doesn't give any specific guidance. I'm pretty sure he does not mean coding by implementing one design pattern after another. I think he means that it is often easier to write the general case than the specific case. Here's a recent example from my own work. We are processing data from an external source. There are ...


5

You could call the class a Facade for the database and key/value dictionary. A facade is a class which encapsulates operations which consist of multiple complex calls to different objects behind a single object with a much simpler interface.


5

Use an identifier that has an explicit name. Validators with explicit names make your code so much more readable: instead of BusinessGroupA having validators 'v1', 'v2', 'v3' and 'v4' the CustomerOrderGroup is validated by the NoOutstandingPaymentsValidator, SufficientCreditValidator...


4

It sounds like you're describing the onion architecture, a form of n-tier architecture -- which is just a fancy way of saying it has components broken out into layers. The layer you're focusing on is the Infrastructure layer. Data is the most common component of infrastructure. But other functions can be contained in separate libraries in the same layer. ...


4

To answer your questions directly: 1) No, it will not affect performance much. Generics are mostly erased by the time the program gets executed anyway, so the additional cost is really only multiple (up to 3) map lookups instead of 1. I would not expect this to ever be a bottleneck in a scenario where usage of a standard HashMap is acceptable. 2) Not ...


4

MVC is a paradigm from the Smalltalk world concerned with how object orientated systems could have UIs. Early web frameworks took the general idea (separate out business logic, controlling logic and view logic) and applied the principle to how they structured the web application. Before this it wasn't uncommon to have God awful mess of HTML generation code ...


4

Yes your feeling is good. It's not right to have such methods inside Model. 1a. Models should only contain properties (in my opinion). 1b. Data-related methods like your SQL fetching should be encapsulate within Repositories. Repository pattern helps abstracting out the database connections we are using. Says you have dozens of models like this, and one ...


4

Static class methods are basically global functions, and are considered a bad idea in OO design. The reason why they are considered bad is hard to see in a simple code example where you are just comparing the difference between calling the same method on an instance or on the class itself. But when you get into slightly more complicated design global ...


3

I think you are extrapolating from rather old terminology of 'Data Layer' and 'Data Access Layer' The implicit assumption of these terms is that you have some large database which your app runs off and you want to separate and abstract that from your applications or 'Business Layer'. You want to avoid polluting your 'should be available for all uses, past ...


3

Your domain objects design depends on your, well, domain. You haven't given one so I'll just say the point of domain objects is to create a layer in your architecture where details, like web, database, user interface, are unknown. If your domain object knows you display in a web page it's not a domain object. Domain objects ignore how the system works. ...


3

Why not using the null object pattern ? Get rid of this builder, the most elegant code you can write is the one you actually don't have to write. public final class CarImpl implements Car { private final Engine engine; private final Transmission transmission; private final Stereo stereo; public CarImpl(Engine engine, Transmission ...


3

Foreign keys in your database enables data integrity, as you can't delete a parent row if there is a child row in another table. While you can rely on the framework to handle data for you, the framework will not enable data integrity and you will eventually end up with orphan rows in your database. So, my advice is: design the database properly in order ...


3

Use copy constructors. Here's why: IClonable semantics are ambiguous. Microsoft never specified whether a clone should be a shallow or deep copy. You can specify custom behavior in your copy constructor, such as giving each copy its own unique ID or only copying some fields and not others. Further Reading Copy constructor vs Clone in C#


3

You are trying to create a layered design. In the top layer are inputs & outputs that interact with the elevator riders: the inputs are the button panel in the elevator and the displays of what floor it's on along with the up/down indicator and button pressed indicators. Further there are up/down call buttons on each floor (and a duplication of the ...


3

Interfaces exist (speaking of the interface keyword), so you can define an API for classes, where the implementation does not matter, only the arguments, return types and maybe thrown exceptions. You should treat classes and their public methods exactly the same, whether they implement an interface or not. Once you realize that, you will see even a class ...


3

An old sage once said: You usually don't create an interface for every class, that would be an afterthought. You create interfaces as a design exercise, then you create classes that implement those interfaces. You have to think that what you are creating is always a foundation upon which someone else can built some bigger. Don't create little programs, ...


3

One approach that might fit is a finite state machine. There are tools that help you build and visualize them but you can also model it with standard OOP practices.


3

Frameworks/SDK's probably use instantance methods because it makes dependency injection possible, which is not really the case for static methods. However, if you don't use DI, a static method is the simplest way. KISS.


3

Is 20 Java classes for just making... This is entirely the wrong question. Something is wrong or you wouldn't be asking. It sounds like you're looking for something to blame. Anguishing over the number of classes isn't going to fix it. I've felt this same pain before. You step back and look at everything. It works. You can kinda follow it. But you ...


2

I have a collection of cooperative classes whose behaviors are interdependent upon one another. But I wish to keep them loosely coupled... Careful now! When you are thinking that exact thought it's time to take a step back and look at what you are trying to achieve and why. Loose coupling is great, but it is not a goal of its own. Every time you make ...


2

Well there is no generic answer, for some it's a matter of opinion so i won't answer in a generic way but i'll take your points one by one. I'm answering considering that all of those will be designed as simple interface. Not implementation. a web service that downloads a PDF of a SQL Server Reporting Services (SSRS) report. This could be just part ...


2

Okay... a simple answer. When I'm building a project that has 'perpendicular' behavior (connecting to external systems, writing to log files, etc) I do it through a library and generally make the calls to it in the business layer. The business layer typically is where the action requiring external access is taking place, and by building the capability into a ...


2

Apart from what Alexander Langer said, there are not only good reasons for, but actual security policies for going even further and don't even hold any kind of credentials or temporary tokens in your domain logic. Practically speaking (and I apologise for not knowing DDD or the exact case well): the domain logic (BC, WebService, whatever) rarely has to ...


2

Most programs have patterns of code that will be required several times, possibly with variations. If you can write code to handle the pattern, you greatly simplify development as you don't have to rewrite similar code. Consider these examples: An application reads and writes text files at several points in the execution. You have couple of options: ...


2

You seem to have two different requirements, based on the method calls you provided. Only one (required) engine, only one (required) transmission, and only one (optional) stereo. One or more (required) engines, one or more (required) transmissions, and one or more (optional) stereos. I think the first issue here is that you don't know what you want the ...


2

I think what you are looking for is a Business Rules Engine. It provides a nice neat reusable way of decoupling your "custom logic" from the "core logic". There are a number of lightweight FOSS BREs out there, hopefully in a language you're comfortable with, as well as some exceedingly expensive ones that are sold to organisations who want to be able to ...


2

Premature Over-Engineering For example, I assert that you do not need any of those interfaces. If needed later, make them later. An interface (the C# keyword kind) is for giving common behavior to unrelated classes and then handle objects polymorphically. Think more carefully about what constitutes a more specific class. Think of what a shopping cart IS. ...



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