Tag Info

New answers tagged

1

If I understand your question, the Facade Pattern fits your needs: Intent: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. Wrap a complicated subsystem with a simpler interface. Your Facade, the ClientReport class, has classes SourceA and ...


1

Here are (at least) two objects client and report involved. From what you write so far, a report seems best to be composed of a client and ressources: public class ClientReport() { public Client client; public decimal ressources; public getClientName(){ return this.client.getName(); } // ... public setRessources(decimal ressources){ ...


1

The definition of your client class should not be tied to how you acquire the data to construct the class. You should review your business requirements of your client class and define it based on that only. From what you have shown so far, it looks like you need two file processing classes which both are provided a collection of client objects to work on, ...


1

An application context object usually allows access to the configuration of the application instance, things like: What is the application's hostname and path? How is dependency injection configured, i.e. what implementation is to be used for a given interface? OS environment variables In a properly designed OO system, the access will be via methods of ...


2

In some respect you are right: They both refer to the same domainobject, which is called order. But you are wrong in as far, it is not a real duplication than a different representation - originated from different purposes. If you want to persist your order, you e.g. want access to each and every column. But you do not want to leak that to the outside. ...


0

(Disclaimer: I only saw it being used in this way. I might have misunderstood the real purpose of doing so. Treat this answer with suspicion.) Here is another missing bit: the conversion between Order and OrderModel. The Order class is tied to your ORM, while the OrderModel is tied to the design of your View Model. Typically, the two methods will be ...


7

The purpose of the View Model is to provide decoupling in two ways: by providing data in the shape that the View requires (independent of the model), and (especially in MVVM) by pushing some or all of the View logic back from the View to the View Model. In a fully normalized model, Customer would not be represented in the Model by a string, but rather by an ...


16

So am I missing something important here? YES While these look like the same thing, and represent the same thing in the domain, they are not the same (OOP) objects. One is the Order as known by the data storage part of the code. The other is the Order as known by the UI. While it's a pleasant coincidence that these classes have the same properties, ...


1

I think in this case just need some encapsulation and specification pattern: Encapsulate the list in a container, expose only needed methods: public class EntryList { private List<LogEntry> _entries; public EntryList() { _entries = new List<LogEntry>(); } public void AddEntry(LogEntry entry) { ...


1

Answer to this question can get very complicated if you need to support parallel requests while you need to split single request across multiple processing nodes. There are 2 types of scaling, Vertical Horizontal For Vertical scaling (adding more CPU power / adding more memory). Since the operation happens in single process, one of the consideration ...


1

If you really want to use a design pattern here, you should look at the Visitor pattern. However, as you are iterating only over one data type (LogEntry), I don't see a need to create a separate class for each calculation. I would keep my design simple and use a single class that contains all those calculations as members: public class LogStatistics { ...


1

No, providing one implementation of an interface is not the Strategy design pattern. The Strategy design pattern generally will have multiple implementations that can be switched at runtime. Source: Strategy Pattern


1

There are obviously dependencies between the handlers. One possible way to do this is to assign priorities to the modules - good thing is that it is easy to implement, but (as Frank Hileman noted) this solution is not scalable. Essentially you hide the dependencies between modules from the system and solve these dependencies yourself by manually ordering ...


0

My tip is to look into Dependency injection. Here is a real world example of what you wanna do Inject your behavior into the VM https://github.com/AndersMalmgren/FreePIE/blob/master/FreePIE.GUI/Shells/Curves/CurveSettingsViewModel.cs#L18 In this example I inject a ISettingsManager into the VM public CurveSettingsViewModel(ISettingsManager ...


0

The general approach for ensuring a list of handlers getting executed in the right order is to not make every handler as being ready to execute, but to only make the first such handler as being ready, and pass on the remaining list of handlers to the first handler, so that the first handler can execute the next one on the list as the first one finishes. Each ...


1

The ICustomTypeDescriptor interface implemented on your components will allow you to show only those properties you wish, or to inject properties on other objects. However, it is only for the property grid. It won't help you with the API or code serialization.


-1

The builder pattern is essential when working with immutable objects. There are a lot of benefits working with immutable objects, especially in making your program be more robust executing in a concurrent environment (i.e., threads)


0

You quoted the Wikipedia article out of context. It actually says: The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. A use case controller ...


0

In MVC pattern, a controller mediates between view and model. Action methods in a controller should be thin and should not have logic embedded in them.In GRASP you can look for Indirection pattern (http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)) So how many controllers should we create or how many action methods should be in one controller, ...


3

Is the top-down design methodology I am describing here a valid approach? Does it have a name? Yes, it is called top-down design, and there's a decent Wikipedia article. In particular, you're describing an informal variant where you figure out what you want the library to do and how you want it organized based on how you intend to use it. do teams ...


8

You're describing Acceptance Test-Driven Development. The basic principle behind ATDD is that each software requirement is accompanied by an acceptance test that, when executed, provides proof that the requirement has been satisfied. Acceptance tests are created when the requirements are analyzed and prior to coding. They can be developed ...


2

God object is one of the worst "designs" you can create. Please, put some effort into separating different concerns. Your future self will thank you.


12

In my experience, a web application would have to be trivially small to not benefit from the organization and decoupling that MVC provides. Perhaps a bit of explanation about the MV* family of architectural patterns is in order. The MV* patterns concern themselves primarily with the User Interface. Their primary purpose is to provide decoupling between ...


1

What if another property will be added and become optional? I have done precisely this when I needed to inject some new functionality into that method. This does not break existing code; you gotta love that! In my case I bypass the new thing if the parameter is null. I generally prefer to use a more meaningfully named value/enum. For example, ...


3

In addition to what Ixrec said, the constructors or method named parameters won't allow you to have your object in a to-be-constructed state in which it can still be modified before building it. This is the beauty of the Builder, where you can delegate parts of its construction to different methods or classes altgether: var myThingBuilder = new ...


2

I understand that in React state should only contain data which may change and cannot be computed from elsewhere, I think there is no need to store something that cannot change in a variable at all (use constants for that). And if something can be computed from elsewhere, you might wrap calculation into a function and call it when you need. So, this ...


1

I agree with Robert's suggestion for using Dictionary as a classic lookup for memory based collections. On the point of the singleton. Use singletons for resource contention ,performance and context If you feel your application might create many instance of cardInfo over and over again and you can manage a singleton safely, then use it. Consider the ...


2

To get an object by name, put your objects into a Dictionary. var dict = new Dictionary<string, CardInfo>(); There are a number of ways to add the CardInfo objects to the dictionary. Here's one: dict.Add("cardname", new CardInfo { foo = 1, bar = 2 }); You retrieve them like this: var cardInfo = dict.Item("cardname"); or var cardInfo = ...


0

Find a pen and a paper and start modelling your system. You will find that you probably need a domain entity called PERSON. Since both STUDENTS and TEACHER "is-a" PERSON, you could create an abstract entity called PERSON with generic attributes like firstname, lastname etc. A TEACHER -> is-a -> Person. Now you can try to find characteristics for a TEACHER ...


14

Builders are most useful when your object needs a lot of arguments/dependencies to be useful, or you want to allow many different ways of constructing the object. Off the top of my head, I can imagine someone might want to "build" objects in a 3D game like this: // Just ignore the fact that this hypothetical god class is coupled to everything ever new ...


1

StartDate and EndDate of what?.... the school year? Ok: public class SchoolYear { StartDate = DateTime.Now; EndDate = new DateTime (2016, 6, 23); } Object Oriented Programming is about, well, objects: Put properties in a class to appropriately describe/define what it is. Write methods against those properties to describe/define what it does. As ...


1

I agree with what has been said but if you really want a memorisation system then investigate the Leitner cardbox system . You could write a program to implement this or google for flashcard systems etc. Another good way to recall technical details is to maintain a blog. The act of reflecting on what you have learned and then writing about it will reinforce ...


5

What you are saying is absolutely normal. As the British would say, "if you don't use it, you lose it" This however is not necessarily absolutely true. As Killan Foth pointed out in the comment above, your memory is much more complex than that. It keeps it in store somewhere, just harder(slower) to find (computer memory btw tries to mimic this, hence L1 ...


0

If the "userManager" exposes separate methods for setting the email, the password, etc. then it is explicitly exposing a model in which partial failure is possible and to be expected. Sure, you can roll your own rollback mechanism as Snowman suggested, but I think it would be easier (more pragmatic perhaps?) to just add the ability to your "userManager" ...


1

You need to use a memento. At each step you look at the previous state and store it in a temporary object. If at any time there is a failure that requires rolling back, you simply look at each memento and restore the original state. This should normally be done as a LIFO stack to ensure changes are undone in reverse order. Note the term "roll back" here: ...


1

NO. And I'm surprised how many people voted otherwise! Paradigm It's Data-Oriented a.k.a. Data-Driven because we are talking about the architecture and not the language it's written in. Architectures are realizations of programming styles or paradigms, which can usually be unadvisably worked around in a given language. Functional? Your comparison to ...


1

I believe neither of your approaches violate anything and both can be used just fine. Passing parameters to the builder can be done either using constructor or setter methods. I do not see any problem with it. I tend to pass parameters via constructor if there are not so many of them. If I have more than 3-5 configuration parameters I switch to using ...


0

But categories can be dynamically created at runtime, and this seems like a lot of code. Is there a convenient solution for this? Only one instance of each object and can handle them dynamically. Or maybe it's not DI at all? Well, if categories can be dynamically created, how are you going to identify and get from DI container? I think you should ...


0

This is a very very broad question... Too broad to really answer well... Are we talking about things like days of the week? are we talking about things that matter only to the UI, and the Business Logic doesn't care about? are we talking about values that arise from real Business Logic? Some default values come directly from Business Logic. Eg. employ ...


0

In a MVC type web application, default values being submitted with a form request should generally be placed in the view directly. This is to say that the controller shouldn't care what arrives, so long as the parameters are valid (and as these things go, it is always a good idea to check user input). However, it is also true that default values can get ...


1

I asserted that default values are business logic and should be tested as such in a recent code review. It's not hard to pull the initialization logic out into whatever component owns "presenting" your view. In essence, ask yourself why a default value should be treated any different from a.. I don't know.. "normal" value. If you concede default values are ...


0

If you realy, realy, realy need so many client-specific features, which I do not recommend at all, you should make your application highly modular. Every time a client-specific change is needed just create a new module instead of adding an if-else mess to existing modules. Make these modules as small as possible and use interfaces and patterns like ...


-3

I have witnessed and participated in many online debates about OOP. The proponents of OOP usually do not know how to write proper procedural code. It is possible to write procedural code that is highly modular. It is possible to separate code and data and ensure that functions can only write to their own data store. It is possible to implement the concept of ...


1

You should architect the API around resources, not around roles, e.g.: /rest/students should be accessible to anyone with a role that allows them to see students. Internally, you are implementing role-based security. How you go about that depends on the details of your application, but let's say you have a role table, each person has one or more roles, ...


0

At this very phase of development you describe, I wouldn't recommend looking for a certain pattern and implement it. Just as a first step, collect what you know: You need to filter You know certain criteria You have an object list of type List You would like to have (I assume) a new listFiltered of the same Type List. Now it depends what libraries and ...


0

I think that answer to behavior extension cannot be abstracted itself - it depends on concrete problem. If we assume that pulling sledge is unusual dog behaviour* (encapsulate what varies) another level of abstraction would be the answer, but it would be different in case of pulling-sledge-contest-app where a dog can pull sledge in generall, but some are to ...


0

How about decoupling the user model from the task model. Instead create a TaskManager object that could get the tasks for the user. Something like TaskManager.getUserTasks(user); //which would return a list of Task objects the advantage of keeping these two is that you can keep on adding functionality without having to change the User model.


0

I pretty much agree with what @radarbob answer states. For some time I wondered as well, about how one would implement such a design pattern in "real life". It's fine when reading about it to understand the design pattern theoretically, but actually applying it is different. If you have access to Pluralsight I would highly recommend the following video ...


3

You may need to consider some re-factoring. So it looks like we have [Client] -message-> [Server] and Message (and all derivatives of) are stored in the [Common] package. In your comment you explain that the Message contains a function which gets called by either the Server or the Client depending on which received the message, which in turn calls a ...


-2

I think the answer is clear if you read Martin Fowler's AnemicDomainModel article. Removing the business logic, which is the domain, from the domain model is essentially breaking object oriented design. Let's review the most basic object oriented concept: An object encapsulates data and operations. For instance, closing an account is an operation that an ...



Top 50 recent answers are included