Tag Info

New answers tagged

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


7

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

Visitor classes should strictly follow SRP (Single Responsibility Principle) so using visit as common naming convention would be the most appropriate. As far as entity classes are concerned, they will usually do more than allow visitor classes to visit them, so name accept can introduce naming conflict if entity class would have accept method that serves ...


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


0

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


2

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


4

What you have written is really a lexer. Parsers give you the nested structure from your input, whereas lexers just give a sequence of symbols. You've probably spent a lot of time reinventing the wheel, when you could use a parser generator like antlr to do most of the work. For example, it only took me around 5 minutes to come up with the following basic ...


0

You are way too much worrying about performance without actually having measured it. Let your Number class just be a facade, and delegate each computational function to a internal helper class on its own, like a SquareRootCalculator, a SinCalculator, and so on. If you are really going to implement that calculations right from the ground, each of it is ...


0

Consider this a blend of two basic MVCs (this assumes you know the basic MVC). First, deeper MVC pair is: M = model C = controller V = view model Second, upper MVC pair is: M = view model C = collapsed / minimal / interspersed (OnSuperButtonClicked is part of it) V = view. With this separation, of course view from one triad cannot access model, nor ...


0

Consider the model being just data. It doesn't make choices, and it doesn't know how to render. A product can be a model. A list of products can be a model. A bundle containing the list of products, the cart and the information about the current user is a model. The last model from the list corresponds to the data you need to render the page, but it ...


0

In this case, tail-wagging is just the expression of something more fundamental (excitement?). Rename WagTail at the high level to something more "simple" (ExpressExcitement?), update the invoking code, and just invoke the relevant subclass's WagTail methods/code from their ExpressExcitement methods. That could be a lot of work (it could also be a really ...


4

Actually, Randall Cook gave a very good answer here, but I would like to add something. Assumed you are going to implement "WagTail" for "man", the correct way of implementing it depends on the expectations of the code calling that method on mammals. If the caller expects some kind of error behaviour or exception to be thrown, then you could actually ...


4

The fundamental problem is that a pure virtual function was added very high in a class hierarchy which not all conceivable subclasses can plausibly support. This is why one should be very careful defining deep class hierarchies. I see a couple approaches. One approach is to simply provide an empty implementation of WagTail for the Man class. Hopefully this ...


2

This is a case of a Liskov Substitution Principle violation. Your mammal class appears to be misnamed, not all mammals have tails as you may have noticed. You may be able to solve it with multiple-inheritence. class Waggable + WagTail class Terrestrial + SunBathe class Cat : Terrestrial, Waggable class Man : Terrestrial Though I'm not sure ...


2

What should be at the top of inheritance tree of Decorator design pattern? How to discriminate: non-abstract class - Only if it makes sense in your code to instantiate it in client code (also see: liskov substitution) abstract class or interface - most common case; This is when it doesn't make sense for client code to instantiate it; To distinguish ...


1

It depends entirely on what you want. These variations exist for your convenience, not because one way is a better way than another. Personally I'm partial to the non-abstract class, because it requires the fewest number of classes, which in my opinion is always a plus. However, you may find yourself in the situation in which there is an AbstractText ...


-3

Pass a whole object, but, select from databse only that fields that you eally need. You will get object with three filled properties, and others properties will get defaults. Such way it will be simplier to fill other properties with data just by adding field name to query, without changing method's signature.


9

I have an object that has about 50 properties, Stop! Go - right now - and fix this. Of course you're going to run into functions that only use part of your object, when your object is doing everything under the sun. No object needs 50 independent properties. Certainly some of them can be organized into sub-objects. Those three that your function takes ...


0

It sounds like you have a good grasp of the issues involved. I don't know specifically whether Dapper makes a difference in your strategy, but in general you only want to return the data from the database that you need. Will you have to alter your query if you need another property in the future? Of course, and that's the downside of returning only what ...


11

If you design a system where 20-30 people all have to edit the same class of your codebase on a daily basis, I would say you will have a pretty big organizational issue and a pretty big architectural issue as well with your system. If such a class is a facade or something else is irrelevant. To solve these issues, I would start with splitting the teams to ...


1

It looks like you are using your observer as both a publisher and a subscriber, while the Provider is only a publisher. Or is it both too? This seems a bit confused. Maybe you should make some kind of Bus or Queue that you can both Publish and Subscribe to. There are so many complexities in messaging that you really should make a distinct component be ...


0

Are there any drawbacks to modifying the Subject Observer design pattern this way? Well, yeah. What I see is backwards, inside-out; an incorrect implementation The observer (ObserverClass) should not be the notifier - the notifier is your ProviderClass. The notifier notifies, the observer observes. Having the ObserverClass calling the providers ...


0

In a similar situation I am using a state machine. The fact that your rule needs the source of the event tells me that your rule must consider the context of the event, i.e. the state your are in. In my suggested state machine scenario your model would be like this: You represent the "world" in your application by defining the possible states with ...


1

You can't add stored properties, but you can add computed properties. A computed property can act just like a stored property. In fact ObjC provides a handy set of calls to make that if not actually easy...well, at least not hard. Performance might not be where you want it, but if performance is a big deal let the profiler tell you when you should give up ...


0

To answer your original question (in title), a Builder is by definition a very stateful object, so after issuing the final "build" and obtaining the constructed object, the Builder is discarded - never re-used.


0

I think you should make the owner responsible for managing their charges, and simply pass the task to the owner. That way the task never has to touch the plan at all. I don't think your alternative is really that much better because a task still has to know about a plan and know that it's responsible for determining the cost. Here's an example, I'm ...


0

I guess your Rule class is an example of specification or command pattern. Definitely different rules will need different types of information to do its work, but if it were me, I would not pass those information during method invocation, I would use constructor instead. The information that is different from one rule to another is the implementation detail ...



Top 50 recent answers are included