Tag Info

Hot answers tagged

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


9

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


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


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


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


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


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


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


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


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


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

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


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


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


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


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

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



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