Tag Info

New answers tagged

1

tl;dr Your decisions on how much to abstract should be dependent upon your business problem to choose how much of the baby to split. Understanding relationships and how to define them properly without creating 'god' objects is a common problem when architecting solutions. Your idea on compromise is spot on when you are trying to accomplish something and ...


0

I think we've learned a lot since SRP was introduced, but in a more indirect and general way due to the changes in the way software development projects are managed. SRP is a principle that wasn't intended to have a set of strict rules that could be blindly applied to all situations. It depends. There are some general rules that experience has taught us that ...


0

Repository can be useful to deal with data access to the different databases. As for the rest, depending on what you pass to the ML algorithms you might want to use a Facade that hides away the details of accessing the different database and determining if the information there is relevant. You would pass a lead to a facade class, that class would ...


1

Singletons exist in programming. A lot. People don't think about this often, yet they are there. While there is some merit to avoiding "global" values, it is detrimental to avoid global designs when they are warranted. With a singleton design, you can make sure that multiple writes to the same record won't clobber data, that reads and writes to the queue ...


6

Abstract factory only makes sense, when code that creates the factory is in completely different part of your application than the code that actually uses your factory. None of your examples actually represent this. Quite often, the factory is downstream the dependency between modules. So the code that consumes the created abstraction cannot possibly have ...


1

You have already mentioned the modules, if the code is already making sense to be logically grouped in that manner, continue with that. It may be unavoidable to have a gatekeeper object that grants access to the modules, but every module would control access and functionality tied to it. Going back to basics and keep it DRY and keep it SOLID help delineate ...


1

Looking in the future, that class will be so huge that will be difficult to maintain it. Even if I group calls by the same module (user authenticate, user profile, etc.) it will be overpopulated. Maybe it's time to refactor into multiple classes having these 2 principles in mind: Maximum 5 public methods by class (rule of thumb) A class should do ...


1

In Python, switching between an attribute and a property isn't a breaking change, it doesn't alter the interface at all, so there's not much point to an auto-property system. You can start with a public attribute, then later on switch to a property without needing to alter the code that interfaces with your class at all. This is also why defining get_ and ...


0

The challenge with the alternative is that it makes adding/changing/removing optional features more difficult. For example, if we add a new optional feature, we now have to change the base class, and then change all of the subclasses to add the feature or the non-feature. This can be somewhat mitigated if there is a reasonable default, such as a no-op, so ...


0

Kilian Foth's answer is excellent, so please upvote it, accept it, go by it. This answer is simply meant to show the fallacy of trying to shoehorn patterns into everything. First of all, you will need inversion of control. Your main application logic should not go out there on its own to access the filesystem and query files, it should be passed some ...


11

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


0

I'd suggest you come at the ISP from the perspective of client code. In how many places is your class being used? Is there any client class that only needs one method but not the other? If all client code needs both, there really doesn't seem to be a case for two interfaces. If you do have two different places where your class is being used, with each ...


1

I'd implement a BanCommand class, which takes care of this. Domain models don't necessarily have to have state; sometimes they represent actions that take data and do something. That's pretty normal OO too; objects are behavior + state, but sometimes the objects don't really need any state to do something useful. That's why I always list behavior before ...


1

Composite often goes hand in hand with Builder pattern to address exactly the problem you have mentioned here. You can create a separate class, call it PageBuilder (or whatever suits your fancy) and move all the building logic into that class. Although I don't know the internals of your code but considering a very generic composite/builder duo here is some ...


1

I would call one object's method from the other, to avoid code replication. I would find a way to do this like that : class BanService() { public function __construct(IUserRepo $userRepo) { $this->userRepo = $userRepo; } public function banUser($userId) { $this->userRepo->getUser($userId)->ban() } } or ...


0

The approach I've used a few times (I'm not sure if it's recommended or not) is as follows: Code business logic into dedicated business logic classes Have your entities use these business logic classes so that they aren't anemic Whether they're injected at construction, or simply directly instantiated is up to you. Any time I need a certain entity's ...


0

No, you don't need them, and I consider it an anti-pattern to automatically make interfaces for every class reference. There is a real cost to making Foo/FooImpl for everything. The IDE may create the interface/implementation for free, but when you're navigating code, you have the extra cognitive load from F3/F12 on foo.doSomething() taking you to the ...


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

Unless you come up with some specific code that changes my mind, I'm going to say that MVCS is just a slight variation on MVC that makes it clearer that the Business Domain lives in the Model, and is technically separate from the data Store. MVC just includes S (the data store) as part of the Model, but the business domain always lives there.


1

If you are getting major push back from the rest of your team, you should probably stop writing/refactoring things into that pattern, and use/leave the prevailing style instead, at least until you can find a persuasive argument in favor. In your issue tracking system, do you have a body of fixed bugs where the problem was in the area of confusion over ...


0

I am working on my own Java 3D engine with LWJGL which leads me to my answer below. I don't know much about JOGL. Both LWJGL and JOGL are just Java bindings to accomplish the same thing, which is to call native code that changes the OpenGL state of the current context. For example, in the current thread, a call in LWJGL to glCreateProgram() will call the ...


0

Ok, the actual question was about how to handle the difference between {FOO, 54} and {BAR, "hello"}. This is classic use case of an union: struct A { int id; union { long val; std::string s; } un; }; unfortunately, unions don't handle constructors very well, so std::string wont work very well inside union (unless they changed it recently :-). But there's ...


0

What I ended up when writing serialization was the following: class ParserPairBase { public: //virtual std::type_info TypeInfo() const=0; virtual size_t SizeOf() const=0; struct PtrSize { char *ptr; size_t size; }; virtual PtrSize BaseParse(std::string s, bool &success) const=0; virtual std::string BaseCreate(PtrSize psz) const=0; }; ...


0

I will approach it from different side of things - in this case you will get the advantage of branch prediction. If you say you have a sorted sequence, this should be ideal in your case. The idea is your original if statement will be extremely fast before the crossover and shortly after. So, chances are it will be faster than actually having logic around ...


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


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


0

Yes and no and it depends. MVC is one of the terms which once had a very specific meaning, but then have grown in use to become a much broader and less specific term. The original use of MVC was specifically as a oo design pattern used when coding desktop GUIs in Smalltalk. The pattern was specifically concerned about separating the data displayed in a form ...


0

The Timeless Way of Building, which introduced the idea of Patterns was written in 1979, and it took another decade until programmers started to take Christopher Alexander's ideas and apply it to software (Design Patterns: Elements of Reusable Object-Oriented Software was released in 1994). The original MVC paper(s) were written starting in 1978, before the ...


0

I would strive for data-driven design. This means that your code is driven by customer specific data. This data may be stored in database or configuration files or whatever suits you best. This way you don't have to build different binaries for each customer with the conditional build directives. In cases where you need different behavior for different ...


1

I am creating my own answer (after a discussion on meta) because I believe that the correct answer is in fact a combination of everything so far. Firstly as DavidArno put, the pattern that I have asked about is more of an anti-pattern because it is just hiding the problem somewhere else. However I believe the suggestion of using the builder pattern from the ...


1

First thing you should check is how many lines of code a typical Organization class implementation has, and how it is structured. If it has less than 100 lines of code, and the class consists mainly of properties providing some flags or data, do not worry. If it has more than 2000, and it contains a lot of business logic, you should consider to split it into ...


1

I think you are almost there. You are getting the State and the Strategy. The way of selecting maybe would be a Factory or a Builder maybe reading a configuration file or a database just as you pointed. At the end it will depend on your own requirements, but the strategy mixed with the Factory or a Builder Pattern to create the object which contains the ...


0

As Doc Brown says, joining properly indexed tables is efficient You make it easier on your application by defining appropriate views and dealing with the views rather than the underlying tables e.g. (Tested on SQL-SERVER, you didn't specify an RDBMS) See Fiddle CREATE VIEW URLsInPage AS SELECT Links.[Name], LinksInPage.[Page URL], ...


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


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


-1

The Factory pattern is the most overused and abused design pattern. I have come across numerous cases where a Factory class is coded when a simple constructor would be adequate. Dont use a factory class unless:- You depend on an external resource but you don't know exactly which one yet. Construction is expensive and you want to build once and reuse many ...


1

Here are my views on the various observation patterns. I may update this list over time if comments seem to require it. Callback with closure: This is great if you have some sort of one-shot thing (like a network response), or multiple responses that all need to be handled the same way. Not so good if you are expecting multiple responses which need to be ...


2

This is kind of an opinion question - but I would say yes, keep them separate. While keeping them together may be less complex in the short run, in the long run, separate repositories make scalability, updates, bug fixes, and extensibility much easier. In terms of scalability: if you decide to host the frontend in multiple places, you can simply build and ...


0

I have encountered this issue several times and found the following solution at best. Please keep in mind this is my approach and your preference may be different. I always try to keep any form of SQL interaction inside the repository. Therefore the create method should be declared inside the repository. Now the issue with the ID persists. When looking at ...


0

I solved this when I started using service providers with a dependency injection container to implement a module system. Treating modules as service providers for the application is what worked best, whether they are providing new services or providing to data to existing services, like routes. The admin panel has itself become a module that simply ...


2

A competent production-quality industrial-strength compiler, with optimization turned on, will automagically transform Snippet2 into Snippet1. If your compiler falls into that category (and most do), there's no real reason for a preference. Personally, being one who believes in being terse, I'd've coded it as: private static void Snippet3(string[] args) { ...


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


2

$this->$data['id'] = $db->insertANewProduct($data); I think is a bad practice, because breaks de Single Responsibility Principle, the product class knows it's been persisted. You are loosing what you win with the repository pattern. If you want to do that another option (less OO) is Active Record. I would choose the option 1 public function ...


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

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


0

Maybe you are missing a layer. Without knowing the details of your application (requisites, architecture, etc) I would do something like Client (whoever it be) -> Application Service -> Domain Model The application service layer is allowed to interact with the repository and the domain model containing the business logic. So you can have something like: ...


2

configuration object or config object are the terms often used to describe this construct. It allows to rearrange the parameters in any order, because the properties of the generic object have no ordering. And you don't need a long list of optional parameters.


0

You would typically want UI strings like this to be pulled in from a string table instead of being hard-coded in the source code, for localization and ease of updating. So the approach I would take would be to use the inputs to build a lookup key, so something like: var lookupKey = "SALUTATION_" + gender1 + "_" + gender2; var format = ...


1

The data structure that you're describing is often used in JSON documents where you have a list of objects, each with attributes (keys to dictionaries) and their values (the mapped portion of each dictionary). In the DS that you give, you can think of obj_1_id and obj_2_id as objects and key1 and key2 as those objects' fields.


2

It's neither a pattern nor an anti-pattern. There's no specific name for it. It is exactly what it appears to be and its quality is determined by the program using it. Does it make sense? Not to me, not without context. Could the outer array be removed and the IDs moved into a single object? Maybe, depends on the program. Could the nested objects be ...



Top 50 recent answers are included