Tag Info

Hot answers tagged

29

Add the title to the parameters of the printf: char* title1; switch(gender1){ case 'M': title1 = "Sir"; break; case 'W': title1 = "Madam"; break; case ...etc. } char* title2; switch(gender2){ case 'M': title2 = "Sir"; break; case 'W': title2 = "Madam"; break; case ...etc. ...


17

Radical solution: Let the user specify their own title (from a predefined list that you provide). Your solution (as viewed through English eyes) only appears to cater for Lords ("Sir") and ladies; most men would be addressed as "Mr", most women as either "Miss", "Mrs" or "Ms", depending on their marital status and personal opinions. Then there's a whole ...


11

I'd call this the "Elephant in the Room" (anti)pattern. You are focusing on the minutiae whilst ignoring the bigger problem. If you have a class that requires 15 constructor parameters, then this a warning sign that the class is doing too much and thus needs too much configuration. The "pattern" you need here therefore is the Single Responsibility ...


10

You shouldn't. Design patterns are named, recurring solutions to recurring problems that involve complex workflows, typically involving many classes with systematic relationships to each other. What you have here is a simple task that calls for a loop or two and a simple list data structure. Ask again when you have to write a complex system with dozens of ...


8

Titles really belong in the database, but you stated you have no control over this. You have not specified a language tag but the syntax is in the C family, so this will be pseudocode that is almost C++: map<string, string> titles; titles.emplace("M", "Sir"); titles.emplace("F", "Madam"); cout << "Dear " << titles[gender1] << " " ...


7

You've got your Builder. However, at this point you need some interfaces. There is a FileBuilder interface that defines one subset of methods (not setSize) and a SizeBuilder interface that defines another subset of methods (not setFilename). You may wish to have a GenericBuilder interface extend the FileBuilder and SizeBuilder - it is not necessary though ...


6

What you are proposing looks like a Replace Type Code [or a conditional] with State/Strategy refactoring. Possible reasons for doing it: Conditionals have become complex, or are anticipated to become complex in the future. The conditionals incur delays or tax resources. Reasons for not doing it: The conditionals are simple at the present, and the ...


4

The most architecturally sound approach I know of is to put that single source of truth behind a microservice. It is perfectly okay for multiple parts of the system to update that data, as long as they do it through something like a microservice that can ensure it's always done correctly and predictably. So for instance, Customer data is probably already in ...


4

I'm going to assume your classes are called Composite, Foo, Bar and Baz. The simplest option is to let CompositeBuilder take pre-built Foos/Bars/Bazs, so you get new CompositeBuilder().setFoo(...).setBar(...).setBaz(...).build(). The big advantage here is that the API to your Composite class is dead simple, both for you and your users. KISS and YAGNI apply ...


3

I tend to prefer a builder for each object that accepts fully built sub-objects. The primary reason is this path provides simplicity of implementation, without loss of flexibility of expression. Also, I find it more readable. Compare two completely facetious examples: CompositeClass.builder() .withArgument(some_arg) ...


3

The data structure should contain a link to the algorithm, since it has exactly one algorithm. Right? (as I understand the requirements) But the same algorithm, say, "normalize to the average" could work on many different instances of the data structure. So it should not contain/store an instance of the data structure. Instead, its method should take ...


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

In general, a gateway class should translate from the interface you have to the interface you want. If the interface you want is a simple presence check, by all means write it that way. I would just caution you as the requirements change and the application grows, to not be afraid to reevaluate that decision. If your gateway class starts looking too ...


3

I've never seen the point of a class that only queries the database and returns an array (or DataSet or DataTable for those in .NET). The mapping of columns in a database to properties or fields on an object belongs in its own class, not in the constructor. The whole point of a data mapper is to decouple the database schema from the object model. By passing ...


3

There is no name for this specific idiom. And it's a good idea™ to write idiomatic code, instead of trying to dumb it down further or writing code which is too clever by half. Especially if any alternatives are long-winded, tedious, repetitive or otherwise bad.


3

ratchet freak's answer is quite a good idea if the sentences are all the same pattern, but with two insets, one each only dependent on gender1 respective gender2. Phil W.'s answer is probably the most flexible answer as it allows explicit control over the greeting, though he's quite correct it's a radical change. You might not have the data in that form. ...


3

I'd clearly choose the extra variable approach, because DRY. The varaible name additionally conveys the meaning of the argument (e.g. it could be warning or log_entry, etc).


3

I also believe that it's more clear to have an unique invocation if this one need to be changed later. The uniqueness of the invocation can be subject to change, too. Maybe you don't want to print anything any more if there is no argument and you don't want to call Print at all in this case. I don't think there is a definite answer to your question ...


3

Tomorrow your boss will tell you that they want to have most of the messages in RED color and a few in BLUE with extra padding... and you are pretty much into major refactoring with both of your approaches. Your Program class is responsible for decision making and printing at the same time. That way Single Responsibility Principle has been broken. So, I ...


3

Have a look at the Builder Pattern. It solves exactly the problem you are having - too many parameters in a constructor. You wind up with an empty constructor (typically in Java this will be a private method, if you use an inner class as the Builder) and setter methods (which may also remain private), then a Builder class with chained methods which call ...


3

The simplest code doing the job is the best. The first version just works. And it is very simple: All it has to do is to evaluate which of two functions to call, and then to call the right one. Little chance of error. Trivial to change if the determination what to call changes. Now you are making things complicated. You assume that once the second ...


3

That's exactly what interfaces are for. The programmer doesn't care what types of objects might be in the list, as long as they provide the method calls expected of any Observer. This way, your list can contain instances of MyTopicSubscriber, MyFileSystemChangeSubscriber, MyMailboxSubscriber, etc. (these are fictitious titles, of course). By using ...


2

The code sample #2 you provided is preferable in my opinion. What if tomorrow you want to have CachedProductData, you would only update product data class, or rather introduce another layer. If you have both classes merged like in example 1, you would be updating both responsibilities. So, Single Responsibility Principal would be broken if you choose ...


2

Let's go back to good old SOLID principals. Currently, your Gateway is: Providing integration with Web Interface AND Checking for an item in users inventory. You broke Single Responsibility principal :) Is it terrible? No, not really, but, trust me, it's much easier to correct it now, while you don't have a large application instead of correcting things ...


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.


2

I'd take a step back and ask yourself why you are trying to create a singleton in the first place. Don't get me wrong, I know there's a lot of people hating on singleton, and I think a lot of that hate is unwarranted. That said, it doesn't seem like your singleton is providing any functionality except acting as a global constant to IRCApiImpl. If you had ...


2

Can I have an object called Algorithm, that is essentially a bundle of methods that loads Products, Motors, combines them, does computations on them, sets up various flags, etc? Or is there a better design? The Strategy Software Design Pattern seems to match the description of your post: https://en.wikipedia.org/wiki/Strategy_pattern This Pattern allows a ...


2

I would improve on OOP part a bit. Provide better naming: You can to change Algorithm to something more specific like RelatedProductsService. Then, expose a method: getrelatedProducts($options) Separate Your responsibilities: You also want to avoid just passing POST along the class into it's children. That is a code smell and creates unnecessary ...


2

I would say to ditch both in favor for a class which handles all permissions. Your classes would then pass a string identifier of the permission you want to check and your class would perform a lookup to see what roles are required to perform that action. For instance, rather than have a method like: public void CreateReport(Report report, User user) { ...


2

You can use the Mediator pattern. essentially you have a single object to which you bind events and pass that into view models rather than binding to the viewmodel event. so: public interface IMediator { void NotifyColleagues(string token, object args); void Register(string token, Action<object> callback); void Unregister(string token, ...



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