New answers tagged

0

My view on this is that the model needs to give an array of object that are called ViewModel or viewData encapsulated in a cellConfigurator. the CellConfigurator holds the CellInfo needed to deque it and to configure the cell. it gives the cell some data so the cell can configure its self. this works too with section if you add some SectionConfigurator ...


2

Please ignore "patterns" and "anti-patterns" for now. Implement whatever you need according to your requirements. In particular, if you have a need to instantiate a boolean filter expression that acts on StudentDetails at runtime (i.e. the composition of the rules aren't hard-coded) and then to use the filtered records somehow, then your approach is ...


1

I'm of the opinion that the command pattern does not apply here. The intent of the command pattern is to collect lots of pieces of data, then supply them to some sort of processor class Wikipedea. This can easily become an anti-pattern with the command object becoming little more than a container for (almost) global variables. In my world, what you have is ...


0

From a Domain Driven Design perspective, I would argue that each Command should capture user intent, and only carry the kinds of information that goes with that particular user-action. So the guiding question is "how do your domain-experts mentally categorize this"? If it's something like "Generate the list of Honor-Roll students", that's probably a single ...


0

The concepts you mention (Clients, Products, Orders, Billing) are typically represented in a single Domain Model and hence Bounded Context. I suggest you are understanding these concepts incorrectly.


0

Each item itself This all should work much alike event-driven system. Parent entity should give orders to its Items, and Items should check with their state to see if and how they can perform that action. Even if it is as simple as reading 1-2 public properties for the Parent, it is still better for encapsulation to not do so and let Items check their ...


4

In general, java tends to require lot of boilerplate because of multiple reasons. Some boilerplate is the result of bad decisions. Some of them were well thought out but turned bad anyway (like checked exceptions and mostly WHERE to use them), some just bad (java.util.Calendar & Date), some from java itself, some from external libraries). But most of ...


2

(Note: I'm assuming that you're talking about Python 2. As noted by @JacquesB in the comments, Python 3's input function doesn't do what you're talking about). First of all, Scanner is not the only class in Java that can be used for input. It is a utility class, existing to make input easier. Your calls to scanner could be replaced with the following code ...


2

If your different bounded contexts understand the meaning/purpose of a country differently, then you need to model it appropriately different in each one. However, if we are speaking simply of reference data of ISO codes and names, then I believe it's pretty fair and standard to stash it wherever is convenient and make it accessible to all interested ...


2

From your questions, I think you misunderstand bounded context. You may want to reread Chapter 14 of the blue book. Trying to answer generally - you have to be careful about sharing concepts between two different bounded contexts. After all, part of the reason that the boundary exists is that the ubiquitous language changes. To assume that the same data ...


0

I wouldn't worry about misusing the pattern but in the scenarios you describe I don't think you need it. PubSub seems to be the popular default at the moment for any messaging application but there is a simpler version of it for when you don't need to fan out or fan in the messages. Just use messaging. There are different forms:, http, rpc, MQ, ...


1

I have answered this question on StackOverflow as well - I place my answer here for easy reference... The PRG pattern alone will not prevent this, as the P action in it takes time (which is usually the case) and the user can submit the form again (via click or browser refresh), which will cause the PRG pattern to "fail". Note that malicious users can also ...


2

Whilst it's admirable to check your preconditions, I wonder: is your class usage such that you'll need to check all these ? e.g. I will check preconditions for a set of components that are exposed for more general usage, but for more limited usage in which I know how the component will be used, I won't perform so many checks. The counter argument to this ...


0

Visibility is often something you want to aggregate so you can tell a whole group of objects to hide or show themselves together. Even so it's still best let each object test and paint itself. I'm a big believer in tell don't ask. To me the object oriented world is divided into behavior objects that tell you nothing about their state, and data objects ...


1

At least in OO + event driven interfaces: GUI objects, including the window pane itself, have event listeners who are triggered with user actions. Those event listeners call a method which then send messages to other GUI elements (or to themselves). But... once a GUI element receives an message (like myButton.setVisible(false);) it renders itself ...


2

Use the factory-pattern. A factory is an object which creates objects. So when you have a weapon which shoot projectiles, pass a ProjectileFactory to it and leave the creation of the projectile to that class. You can then have different classes which extend ProjectileFactory, like BulletProjectileFactory, ExplosiveProjectileFactory, ...


1

The downside of your inefficient proposal comes when there are 2 jobs for a category. Now one is working..and everyone else is doing a busy wait. You can make this good enough by having workers scan through the queue for a next doable task, then return everything but that to the queue if they find one. Alternately return everything, then sleep. If the ...


4

There are two parts to this problem. One: the unknown list of possible categories. Two: interprocess communication between the workers to prevent two jobs of the same category being processed simultaiously. If you had a known list of categories you can have one queue and one worker per category. With unknown categories, you can still have a queue per ...


0

You could use generics, but its not quite the same as your example. MyFaveClass<T> { public T OnlyOneOfThese { get; set; } } var x = new MyFaveClass<AnotherClass>(); Here is another method which allows you to set the object. The as operator returns null if it cant do the cast, so this relys on the classes not inheriting from each other ...


1

Looks like MyFavoriteClass itself is a problem and should be split. Create specializations of this class which can only contain a specific pair of referenced types, that's how you get the constraint. Then use a factory which is capable of emitting the correct specializations of MyFavoriteClass. You may either provide an overload for each combination of ...


1

Your code as stated is not necessarily a violation of the Liskov Substitution Principle: you can introduce an additional constraint in the constructor as long as instantiated NpcParty objects do not assume that their foos collections always have at least one member. It doesn't seem like that will be the case, and you'll probably want to rely on that ...


8

In your example above there is actually no violation of the LSP. Each NpcParty object is still a valid Party object and can be used for it in exchange. The LSP is not about exchanging class A by class B, it is about exchanging objects of type A by objects of type B. Thus, constructors, and constraints which are only checked in there, are not subject to the ...


2

Have an abstract base class and two concrete derived classes. You didn't tell us what is different, but only said "their implementations are almost the same with each other". Let's assume the database name is the only difference: abstract class Model_base { public function insert($tableName, $columns, $preds = null) { $db = $this->getDB(); ...


1

What you describe here is a Factory, which simply offloads the responsibility of object creation to another class. What factory to use is static: known at compile time, does not change. What you need is an Abstract Factory, where the factory is an interface and the implementation of the factory is unknown until run time. This allows third parties to ...


0

You need a collection that represents all known setup rules. An master array or list of interfaces (as @StevieV suggests), for example. I'd put each setup capability into it's own class so that I could name all the methods simplysetup(). Each class would either inherit from a shared base class or implement an interface (or both). The base class and/or ...


4

As long as you want only a PDF version of your report, it's enough to simply apply good factoring practices. Write utility functions, extract common code into subroutines, choose good method names, and after a while you'll have a pretty decent maintainable report generator. However, the second it looks as if you'll have to support any other output format ...


1

You have brought up questions about two SOLID principles. The first is about the Single Reponsibility Principle. And now I doubt if I should add a isAdjacentTo(Node) method to the GraphEdge class or I should create a GraphUtil class(*) and add static edgeIsAdjacentToNode(Edge,Node) method to it. The question that you should ask yourself about this is ...


1

TL;DR This phrase would help remind one not to apply SRP prematurely: A good separation of responsibilities is done only when the full picture of how the application should work is well understand. Source: http://www.oodesign.com/single-responsibility-principle.html API Requirements Phase These are given as examples. Cross out ones that are not ...


0

The Single Responsibility Principal states that a class should only have one reason to change. If your class has multiple reasons to change, then you can split it out into other classes and utilize composition to eliminate this problem. To answer your question, I have to ask you a question: Does your class have only one reason to change? If not, then don't ...


21

The single responsibility principle can be tricky to understand. What I've found useful is to think of it like how you write sentences. You don't try to cram a lot of ideas into a single sentence. Each sentence should state one idea clearly and defer the details. For example, if you wanted to define a car, you would say: A road vehicle, typically with ...


6

Update (recap) Since I've written a rather verbose answer, here's what it all boils down to: Namespaces are good, use them whenever it makes sense Using inGameIO and playerIO classes would likely constitute a breach of the SRP. It likely means you're coupling the way you handle IO with the application logic. Have a couple of generic IO classes, that are ...


2

I'd say that the best way to go is to keep them in separate classes. Small classes are not bad, in fact most of the time they're a good idea. Regarding your specific case I think that having the separated can help you change the logic of any of those specific handlers without affecting the others and, if necessary, it would be easier for you to add new ...


-1

Advantages of dependency injections are, 1.your code is clean and more readable. 2.codes are loosely coupled. 3.more reusable as the implementations are configured in the XML file,it can be used in a different context. 4.code can be easily testable with different mock implementation.


16

This metaphor almost certainly refers to the practice of establishing the first conditional check in a while loop. If you don't do this, the loop won't work. It is a well-established pattern, and it hasn't changed since the while loop was invented. The requirement for setting the initial condition in a while loop is not a defect. int i = 0; // prime the ...


0

Why would you put that toJsonString method in your domain objects to start with? That seems to violation the single responsibility principle. With gson you don't need any of the internals of your class to do the serialization, so I would keep it out. I would provide a service to do the actual serialization instead.


0

An interesting question. Lets leave aside the question of how to represent reposts. Presumably you will have many types of 'post' some of will be sharing some sort of meta data. The main thrust of your problem is whether to store to data of the post multiple times, once per follower, or have a single copy for the poster and dymamically generate 'feeds' ...


0

You are doing well at having controller layer away from repositories. Controllers doesn't have any idea about the business nor the way data is persisted. Let business layer deal with DAOs (repositories). That's a good practice. Despite it takes extra work to implement. Build up a service layer where every service get rid of its own business. Slug / ...


2

Lets to do an exercice of creativity A's API Rest as webservice: In order to feed B and unbind B from A's data model , we need an interface that will act like a contract. This contract is going to be our webservice data model. B as standalone app: Lets wrap B into a standalone app that could be executed anywhere. Desktop or web doesn't matter. Lets say ...


1

Is there anything preventing you from using a traditional TCP socket connection? You might also be able to get away with a websocket (HTML5 - also built on top of TCP) solution. You didn't mention what language you are developing in but my guess is its either Java or C# and in that case, you will find thousands of tutorials, code samples, and pre-built ...


24

One way in which you can stick to the principle of least astonishment is to consider other principles such as ISP and SRP, or even DRY. In the specific example you've given, the suggestion seems to be that there's a certain dependency of ordering for manipulating the file; but your API controls both the file access and the data format, which smells a bit ...


12

This is not only about POLA, but also about preventing invalid state as a possible source of bugs. Let's see how we can provide some constraints to your example without providing a concrete implementation: First step: Don't allow anything to be called, before a file was opened. CreateDataFileInterface + OpenFile(filename : string) : DataFileInterface ...


1

Data Transfer Objects (DTO's) have one purpose, and one purpose only: to retrieve data from a database and work with it in an object-oriented form. There's no such thing as an "anemic BLL object." It's either a first-class BLL object, or it's a DTO. It's seldom both. There are reasons why you have things like ViewModel objects. A View Model object ...


1

You actually need to create a Data Access Layer: 1- Create a New Class Library [ProjectName].DataAccess 2- Create a Class Named UserManager. 3- Create a Method called AddUser that takes the User Model as an argument. and inside that method, you write the logic to insert the user to the database. Depending on the Scale of your system, you might want ...


1

I have, in the past, used something like this in Go, for this exact case: func ProcessFile(fileName string, wg *sync.WaitGroup) { defer wg.Done() // Do things } func ProcessDirectory(dirName string, wg *sync.WaitGroup) { defer wg.Done() // Do things switch { case isFile(name): wg.Add(1) go processFile(name, wg) case isDir(name): ...


1

Learn to model a simple problem into a problem domain model and then into code. Your first four requirements all relate to books. Your final "Manage users" is vague, so I'll leave that for now. How do you represent a Book? Assuming each book is unique, you model it with TWO objects. One being a particular book (Book), and the other the set of all books ...


2

From the docs for sync.WaitGroup: A WaitGroup waits for a collection of goroutines to finish. The main goroutine calls Add to set the number of goroutines to wait for. Then each of the goroutines runs and calls Done when finished. At the same time, Wait can be used to block until all goroutines have finished.


-2

Does search logic belong in the controller or the model? Neither and both. In the circumstances that you describe, you actually have a need for several different search algorithms, along with the need to determine which one to use at any given time. This tells me that the model's Search() method needs to take in the algorithm as a dependency. ...


1

The View is responsible for displaying data and accepting input from the user. The Controller is responsible for accepting requests and directing them to the proper method in the model for performing the requested operation, including related operations such as granting or denying security access and form validation. It is also responsible for directing ...


0

You usually do not want to have a class representing the relationship between the InformationSource and Car classes. In relational databases you do have these tables because there is no other way how to represent the relationship. In object oriented languages you can do that directly. I do not exactly know what you mean by available information source and ...


2

This sounds like a use-case for event-sourcing. (The following is a bit simplified view) Event Sourcing works by storing "events", instead of data, and then constructing the actual data bij re-running the events all the time. An event log could be like: teacher A created student "Bobby Tables" teacher A assigned student "Bobby Tables" to class Maths ...



Top 50 recent answers are included