Tag Info

New answers tagged

0

The idea is to restrict what objects can modify another object. There are two broad ways to achieve this. Forget it and let anyone modify the objects. Just do not call the mutating functions from outside Level and move on. Use a language feature to achieve this. For example, in C++ you could use the friend keyword to allow Level more access. In Java, you ...


0

A simple solution would be to make them immutable and produce new world objects for the next world state. This gives the Level complete control over the world's state without allowing objects to interfere with each other directly. Another benefit of this approach is that it still works even if your world objects stop being pure data and have some internal ...


0

Try not to get caught up in the details of the UML. It is extensible if you assume enter(Controller) is some kind of interface implementation, and your concrete methods aren't required to implement all methods of the abstract superclass. The goal of the diagram is to illustrate the essence of the pattern. The diagram alone fails to convey this, but the ...


0

I like the question, my two cents: Your two approaches are radically different: The first one is OO ans strongly typed - but not extensible The second one is weakly typed (string encapsulates anything) In C++, many would use a std::map of boost::variant to achieve a mix of both. Disgression: Note that some languages, such as C#, allows the dynamic ...


1

As Doc Brown says, this is a fluent interface, and is easily achievable in javascript, to use your example: Number.prototype.sqrt=function(){return Math.sqrt(this);}; Number.prototype.floor=function(){return Math.floor(this);}; String.prototype.alert=function(){alert(this);return this;} (5).sqrt().floor().toString().alert(); //alerts "2"


12

Here, because you don't want to expose how to directly create this object to the clients that need it, you expose a Factory that will create them and inject that into the client instead. If clients know the object exists, it's usually fine for them to know how to make it. If you have an interface then maybe you need some factory to make the concrete ...


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


1

For any factory pattern to be usable, it needs a parameter to know what concrete instance to create. With Factory Method and Abstract Factory this "parameter" is type the creation method is on, which is achieved with polymorphism. With "plain" factory pattern, only way to achieve that is to pass the parameter into creation method. Also, this creation process ...


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


15

Your question is tagged with "Java", no surprise you're asking why is the Factory pattern being mocked: Java itself comes with a nicely packaged abuses of that pattern. For example try loading an XML document from a file and run an XPath query against it. You need something like 10 lines of code just to setup the Factories and Builders: ...


3

Factories of one sort or another are found in pretty much any object-oriented language under appropriate circumstances. Sometimes you just plain need a way to select what kind of object to create based on a simple parameter like a string. Some people take it too far and try to architect their code to never need to call a constructor except inside a ...


10

Factories have many advantages which allow for elegant application designs in some situations. One is that you can set the properties of objects you later want to create in one place by creating a factory, and then hand that factory around. But often you don't actually need to do that. In that case using a Factory just adds additional complexity without ...


2

In general, there is this trend that Java programs are horrendously over-engineered [citation needed]. Having many factories is one of the most common symptoms of over-engineering, that's why people make fun of those. In particular, the problem Java has with factories is that in Java a) constructors are no functions and b) function are no first-class ...


31

As so often, people misunderstand what's going on (and that includes many of the laughers). It's not the factory pattern per se that's bad as much as the way many (maybe even most) people use it. And that no doubt stems from the way programming (and patterns) is taught. Schoolkids (often calling themselves "students") get told to "create X using pattern Y" ...


2

As Steve Evers states, using an enumeration as a key and either a Class to instantiate (or an instance of Query pre-built) to return. If you don't like the if/else pattern, I know Java has Map implementations, of which the EnumMap would be a good fit (where it optimizes the utilization of Enumerations as the key values in the map. Then your code looks ...


2

It's not clear to me that you need any design pattern -- at least not in the sense of the "Gang of Four" book. From your description of the problem: Every combination of arguments needs a different algorithm what you need is some way to get from input -> output where input is "combination of arguments" and output is "algorithm". This is essentially ...


-1

I would go with a builder pattern. Where shape is the shape to be buffered, 5 is the required radius, I made up some other things that you may want your buffer to have. var bufferedShape = new BufferBuilder(shape, 5) .Inside() .SinglePixel() .DropShadow(10) .CreateBuffer(); ...


0

Typically you would get ahold of an ICRMRepository<Member> and query against that if you wanted all Members and within your loop you'd check their actual type: foreach(Member member in memberRepository.GetAll()) { // do stuff here that you can do for all Members, then... if(member is HonoraryMember) { var honoraryMember = member as ...


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


0

If you are a 100% sure you won't change your ORM in the future then no need to use UOW, EF does it for you, but if there is a need to change your ORM in the future, (for example if you will need dynamic tables creation, or an ORM that is more performant than EF) if you have a UOW layer that abstracts away your DbContext , you will find it easy to change the ...


0

From: http://martinfowler.com/eaaCatalog/repository.html Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers. The issue is here: So why make my own UnitOfWork if EF's DbContext already does this for me? If you are using a classic repository pattern, the ...


0

Your service layer might look simple now, but if you are building this application for a client they ultimately shape the service layer, not you. What if the client requires that they can edit multiple items at once, changing any number of item properties, some of which are part of denormalized database tables? What happens when EF throws a concurrency ...


2

I typically use the UnitOfWork to abstract away the knowledge of database transactions (and subsequently works well as an abstraction layer over my orm). The idea is, repositories are responsible for the logic of accessessing and modifying data, the unit of work handles when those actions get performed. It's a great tool for removing some complexity and ...


2

If anyone else finds this question relevant, I'm following-up with my chosen solution. Bottom line: when you can't find a simple solution to a seemingly simple problem, it may be a sign that analysis and refactoring of the existing design is needed. Analyzing my code, I realized that the Sequence class had fairly overloaded accessors that as designed could ...


3

To draw the line between exceptions and return values, I would try to stick to the following: - Anytime an instruction breaks the expected flow of execution, you expect an error to be thrown. - If the expected function of procedure may have different outcomes, you will want to work with return values. In the examples that you are stating, it seems very ...


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 have some code that illustrates some of the differences wrt visibility and "default" implementations when extending vs setting a self-type. It does not illustrate any of the parts discussed already about how actual name collisions are resolved, but instead focuses on what is possible and not possible to do. trait A1 { self: B => def doit { ...


1

You want to use the DependencyResolver Class. http://msdn.microsoft.com/en-us/library/system.web.mvc.dependencyresolver(v=vs.118).aspx In your global asax, you set the resolver and wire up fake implementations of interfaces that your data access layer also implments Then in your controller, you create 2 constructors public Controller() : ...


0

The basic reasons of using MVVM are Separation of Concerns (SOC) and Single Responsibility Principle (SRP). Then you have Flexibility, Maintenance and Testing. The goal of MVVM was to apply the above on WPF. WPF provides "plumbing" to allow easy use of MVVM through Data Binding. For SOC and SRP read: Separation of Concerns(Wikipedia) and Single ...


1

MVVM is basically just a modern refinement of the MVC pattern, so the main goal is still the same as that of MVC: to provide a clear separation between domain logic and presentation logic. This can be boiled down to code quality: by adhering to the concepts of high cohesion and loose coupling, you stand a much better chance of sustaining productivity over ...


1

If a class is too big, it becomes hard to maintain, test and understand, other answers have covered this will. It is possible for a class to have more than one responsibility without problems, but you soon hit problems with too complex classes. However having a simple rule of “only one responsibility” just makes it easier to know when you need a new class. ...


3

My simplistic answer is that in the standard MVC concept, the Model knows nothing about the View. However, on GUI platforms that support data binding, the View needs bind to something that is responsive to changes in what the user sees, and the Model cannot satisfactorily fill that role. Data Binding is a Good Thing, but not easily reconciled with MVC. The ...


1

The answer is, as others have pointed out, all of them are correct, and they all feed into each other, easier to test makes maintenance easier makes code more robust makes maintenance easier and so forth... All of this boils down to a key principal -- code should be as small and do as little as necessary in order to get the job done. This applies to an ...


3

The whole idea of MVC is Separation of Concern and by introducing any method that builds/generates any form of mark-up like what you are doing in your example, even without directly outputting them, you're violating that. So this is not MVC anymore. In your example changing the desing/mark-up by a designer needs modification in your object.php by a ...


2

You need to look at these sub-objects and what logic they contain. Something has to decide how to mark up the text. As your question makes clear, the controller should not (and in your case, is not) the place where this occurs. Those sub-objects may be considered part of the view, in that they contain code responsible for assembling the dynamic parts of ...


3

There are a number of reasons, but the the one I like is the approach used by many of the early UNIX programs: Do one thing well. It is hard enough to do that with one thing, and increasing difficult the more things you try to do. Another reason is to limit and control side effects. I loved my combination coffee maker door opener. Unfortunately, the ...


1

The best way to understand the importance of these principles is to have the need. When I was a novice programmer, I didn't give much thought to design, in fact, I didn't even know design patterns existed. As my programs grew, changing one thing meant changing many other things. It was hard to track down bugs, the code was huge and repetitive. There ...


1

I follow the thought: 1 Class = 1 Job. Using a Physiology Analogy: Motor (Neural System), Respiration (Lungs), Digestive (Stomach), Olfactory (Observation), etc. Each of these will have a subset of controllers, but they each only have 1 responsibility, whether its to manage the way each of their respective subsystems works or whether they are an ...


0

When talking about generating ("building") HTML vs. using template language one thing always pops into my mind: separation of concerns i.e. separating the representation ("view") from the business logic. I'm always in favor of using template languages: It's easier to separate the view from the rest of the code. The code will be easier to maintain and ...


4

Here are the arguments that, in my view, support the claim that the Single-Responsibility Principle is a good practice. I provide also links to further literature, where you can read even more detailed reasonings -- and more eloquent than mine: Better maintenance: ideally, whenever a functionality of the system has to change, there will be one and only ...


3

Template languages provide a declarative syntax, which is much less error-prone for this particular use case than an imperative syntax. In other words, you're specifying what the end result looks like rather than step by step instructions for how to build it. That's why template languages are so popular when the back end is written in a more imperative ...


51

Modularity. Any decent language will give you the means to glue together pieces of code, but there's no general way to unglue a large piece of code without the programmer performing surgery on the source. By jamming a lot of tasks into one code construct, you rob yourself and others of the opportunity to combine its pieces in other ways, and introduce ...


3

Because software is organic. Requirements change constantly so you have to manipulate components with as little headache as possible. By not following SOLID principles, you may end up with a code base that is set in concrete. Imagine a house with a load bearing concrete wall. What happens when you take this wall out without any support? The house will ...


27

Better maintenance, easy testing, faster bug-fixing are just (very pleasant) outcomes of applying SRP. The main reason (as Robert C. Matin puts it) is: A class should have one, and only one, reason to change. In other words, SRP raises change locality. SRP also promotes DRY code. As long as we have classes that have only one responsibility, we may ...


1

Especially with such important principle as Single Responsibility, I would personally expect that there are many reasons why people adopt this principle. Some of those reasons might be: Maintenance - SRP ensures that changing responsibility in one class doesn't affect other responsibilities, making maintenance simpler. That is because if each class has ...


21

Is easy to create code to fix a particular problem. Is more complicated to create code that fixes that problem while allowing later changes to be made safely. SOLID provides a set of practices that makes the code better. As to which one is correct: All three of them. They are all benefits of using single responsibility and the reason that you should use it. ...


1

It is a good idea to break the representation from the data in any case. It is not made clear explicitly from your question if this is what you want, but my guess is that it is what you're pointing to. I'm not familiar with the precise implementations you've mentioned, but generally speaking it can de handled as follows: If you roll your own, then you have ...



Top 50 recent answers are included