Tag Info

Hot answers tagged

73

When building real-world programs, there is often a trade-off between staying pragmatic on one hand, and staying 100% clean on the other. If staying clean prohibits you to ship your product in time, then you are better off with a little bit of duct-tape to get the d***d thing out of the door. Said that, your description sounds different - it sounds you are ...


25

Interesting question. I am a bit biased though due to my previous experiences, which prompts me to answer with No. Short answer: We never stop learning. When you hit a wall like that, it is a chance to improve your architectural/design skills, not an excuse to add code smells. The longer version is that I have been asked similar questions a lot of times in ...


9

Having a god class like this is never desirable, as it does not only mean that your bullets are now monolithic objects, but the same goes for your procedural generation algorithm as well. The first step would have been to analyze, why exactly your AI did have so much trouble with dealing with the complexity of your pattern? Did you, by chance, tried to ...


8

All bad code since the dawn of time has a story behind its evolution that makes it look reasonable step by step. Yours is no exception. Coders learn by coding. There are aspects of your problem you could not have foreseen that seem obvious now. There are decisions you made that were entirely reasonable incrementally, but led your architecture in the ...


6

I don't agree that you should be sorting your methods by category, or even by visibility. It may seem, at first, like this is a good thing to do, but what you're actually doing is imposing order for the sake of order, but not for any particular reason. Consider ensuring that your address book were sorted by phone number. Certainly, it would be organized, but ...


6

Heating the processor and losing time by useless computations is a side effect which is generally ignored, so could be considered as not very concrete. It is not concrete according to the quoted definition of Meyer. This is why compilers are permitted to optimize useless code like /// spend some time busy waiting in a useless computation for (int i=1; ...


5

Is there a standardized set of categories in OOP that cover what methods can do? No, since by definition, methods can do anything. But you're solving a symptom. I find it easier to find my way through a class when I group its methods by category. This is a sign that your classes are too big, and/or doing too much. It also might be a sign that ...


5

You should choose between init in declaration or constructor, not both. In a language that has a default constructor where you don't have to explicitly provide a constructor if the default is all you need, a declaration init may be fine. As soon as you need an explicit constructor with parameter, I tend to move everything to constructor(s), to ensure that ...


5

Inheritance is "is-a", composition is "has-a". Is it the case that "a B is-an A", or it is the case the "a B has-an A for some reason"? It is obvious than setting window is-not-a main window, but is an external actor. So it should have an A passed in. EDIT: Since you told what A and B is, that is, windows, you should separate domain from presentation; that ...


5

I've never heard this exact claim before, but from the way you describe it, it sounds very closely related to two mantras I am familiar with: "favor composition over inheritance" and "separate interface from implementation". The definition of subtyping that you appear to be using (I won't get into the question of whether it's correct or not) is that, if A ...


4

You process method is indeed in a wrong place. What is the context where you will switch to channel 10? Why channel 10, and not channel 9? Maybe the user asked specifically the channel 10. In this case, 10 should be the input, not a value within the class. Maybe this is the default channel, the one which will be shown every time the TV is turned on. In ...


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


4

What you are after is not very specific for OOP, and has absolutely nothing to do with inheritance. You are after proper modularization. Each of your features should be a component, that means either a single class, or a group of classes, with a well defined interface, and not directly dependent on the Application object. In the current situation each ...


4

As an outsider looking at this code, it is not clear how the "hidden dependencies" get created to begin with. What if there is no "db" dependency registered? Does it throw an exception, return null? If my class doesn't get a "db" dependency, how bad is that? Many times people lean towards this pattern when there are too many dependencies to pass in the ...


4

Your example is already flawed, as Admin gains new properties over the base class which makes it incompatible. It would have been smarter to place the $permissions property straight away in the base class. Ask yourself, in what cases could it be desirable to introduce new properties on an existing object? Both instantiating an object as an instance of a ...


3

It's hard to say how to structure your application without knowing the differences between each 'branch'. What I would do is compare the functionality of each branch and distill the common denominators. Put these into classes that you use for each client. The parts that differ from client to client I would then put into adapters or strategies that ...


3

I think all three (this., super., and private member prefixes) are superfluous: this. is superfluous if you have relatively small methods, which you should (rule of thumb: does one thing; code fits in a single screen). In a small method you can easily tell apart method-local and instance/class variables. super. is superfluous because classes should be ...


3

Absolute nonsense. A few thoughts: You should not take OOP and it's principles too seriously. Many times functional or other software paradigms make more sense. Though the objects thing is cool... thinking in concrete components and all that. Testing, and specifically Unit Testing is meant to serve the project, verify it's design, and assure its ...


3

If that common behavior sees frequent use, it will admittedly be executed multiple times during tests for each of the subclasses, but so will it at runtime in production, there's nothing wrong with it. However, that doesn't mean you should specifically test the common logic multiple times. Concrete/abstract superclass If the superclass is not abstract and ...


3

In proprietary software you want to hide implementation details, while in free software you don't care (and you would accept someone extending your library in unexpected ways using the implementation datails). I also think it is related to the notion of leaky abstractions, and since you commented that your library will be free software, I would suggest ...


3

In your example: int i =1; while (true) { Immutable im = new Immutable(i); i = im.Print(); // get the previous obeject's state i++; // logic outside } Immutable should return the new state that the mutable solution would've stored, i.e. i + 1. You already have the old state. Returning the old state and forcing the caller to update the state ...


3

There are cases where a simple one-to-one mapping is not appropriate. Automatically assigning parameters to instance variables only works sometimes, not all of the time. Perhaps validation is needed, or an exception might be thrown. Maybe a parameter must be scaled, or another object created. Consider a Java BigDecimal. Internally it has a BigInteger and an ...


3

Because of inheritance. In a language without inheritance, the constructor could simply map its arguments to the object's fields in a one-to-one manner. If the mapping isn't one-to-one, you can always hide the constructor and provide a static method to do the work and pass the final values to the constructor. Case in point, this is how many functional ...


2

I'd only like to point out the following: This use of super super.aBarMethod(); is actually harmful because it disables dynamic dispatch for this call. This means that if a sub-class overrides aBarMethod, you will still call the one defined in Bar, not the overriding one. Probably not what you'd expect. What was supposedly meant to be a stylistic ...


2

You stumbled on one of the Bigger problems that tends to get swept under the rug in unit testing/TDD discussions. Well designed code from an object oriented perspective is generally hard to unit test, code that is easy to write unit tests for usually is compromising some paradigms of object oriented design. Most approaches to unit testing tend to drive ...


2

I'd advise against using this. in this fashion, not because it is in itself a bad idea. (Python, for example, forces you to do this with self. and python has a well-deserved reputation for readability.) But rather because the language doesn't enforce it. Because the language doesn't enforce it, it is easy to forget it on an individual line, which will ...


2

Having the language (eg, English, French, Japanese) so far up in your namespace is a smell. If I were you I'd keep the Language identifiers in the class names only. The recommended structure for a namespace is something like <company>.<project>.<namespace>.<subNamespace>.<andSoOn> So, in your case, you might consider ...


2

It sounds like essentially the problem is that you have 30 processes which are similar but vary in inconsistent ways and you want to avoid duplicating code as much as possible while still being able to change any aspect if required. In that case then the template method pattern can be very useful. The basic idea is that you'd implement a base/abstract ...


2

I think it's perfectly OK for a "feature" to need an "application", but the use of globals is nauseating. Constructor dependency injection can solve this problem, and allow a gradual refactoring of code. (I'm not a C++ developer, so any corrections/clarifications are welcome) First, the Application class: class Application { public: void ...



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