Tag Info

New answers tagged

1

I have read in several places that having one programming language mechanism that conflates both is a bad thing. [...] So why is this a bad thing? Because in situations where one wants one of them and not the other, one is left without an option (a recast of the "wanted a banana but what you got was a gorilla holding the banana and the entire jungle" ...


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


4

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


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


1

You usually don't need to. Scala, for example, just keeps the arguments to the primary constructor in scope throughout the object's lifetime. It turns out, the vast majority of the time that's all you need, especially if you support default values. However, you still have to support those other cases that the other answers enumerated. Most languages ...


1

From a language structure point of view: Because of scope. Parameters passed in to a function are only valid and accessible within that function. Instance variables are valid and accessible in every function. Furthermore, by definition function parameters are passed in to the function from a caller. So they do not reside within the object: they reside in ...


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


0

I understand the obvious -- that it is a requirement of the language -- but I was wondering why virtually all OO languages are implemented this way. Because there is a difference between the type (or type constructor) and the constructor (or data constructor). By mixing these concepts, you're making assumptions about what the programmer wants - ...


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


1

The purpose of a constructor method is to construct an object. Your constructor parameters are scoped to the constructor method, so unless you save them in instance variables, they are lost once your constructor method goes out of scope. This is how parameters work in any method; they are local to the method, not global to the class. Your constructor ...


0

From the comments we discussed the following: it could be a side effect that is not actually directly in the function called, but in a function called by that function? So function A is called. It calls function B and function B has a concrete side effect and function A is then sad to have a side effect, because it calls function B.


1

1 class per row is of course not an option You will need something like this: Create a class (Item) that has the table columns as properties And another class (Items) that represents the table that has a property List<Item>


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


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


0

For inspiration, you might want to have a look at functional programming, or more precisely, tight-tailored types. The idea being that things don't work are impossible to represent in the type system you have available. For example, say you have a gun that has the components "shoot bullets" and "hold bullets". If they are two separate components, there's ...


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


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


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


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


2

In some cases this is definitely acceptable. However, I find it hard to believe there is no good solution using both procedural generation and your nice attached/component based behavior architecture. If all behaviors where just pulled into the bullet class there is no functional difference between the god object, and neat architectured version. What made it ...


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


1

Entry32::Method2 overrides Entry31::Method2, not Entry3::Method2. Since the override chain is broken between Entry3 and Entry31 (it is a shadow - completely different functions as far as the runtime is concerned) the virtual dispatch doesn't pass there.


0

Instead of passing hardcoded department name to the constructor of Person class, pass the initialized DeptName variable to Person class. private void btnShowTotalSalary_Click(object sender, EventArgs e) { string DeptName = "Unknown Department"; if (rbtHR.Checked) { lblTotalSalary.Text= ...


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


1

If you add a method Lead.list() where it returns a list of leads it's violation of SRP, as the fetching a list of Leads is not the responsibility of Lead object. So the best option is to use a data service or a repository. For example LeadRepository could have methods GetAll(), GetById(id)


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


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


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

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


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


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


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

"Static" is sometimes a naughty word in the C# world, because it makes it difficult to create Unit Tests around the class in question, unless the class is doing nothing but logic-processing and has no database, file I/O operations, or any such behavior. If you're passing data or commands from layer to layer, then I would suggest that your class NOT be ...


0

The source of the confusion here may be the fact that you are viewing the application object as being one and the same thing as the domain model of your application. They are not. The application contains the domain model, and instantiates the features that operate on it. So, my recommendation would be to take all these global variables out of the ...


1

I can not include Application header (since that would defeat the purpose of the separation). But since there are these types of globals everywhere in the old code this task is rather complicated. You just need to split the task into the correct steps, and then it is simple (though it may not be easy :) ) But sometimes there may be a lot of ...


0

A method on a class in c# doesnt actually take any memory on an actual instance of the class. So every object you create of this class will still be the same size whether or not you added some extra methods to the class. You definitely should not create a new class to do these operations that are closely bound to your 'data-passing-class'.


1

Your question is opinion-based and open-ended, so I'm not offering anything undoubtedly acceptable, but certainly, good naming is hard ← emphasis. I've found many times that coming up with good names or good system of names if they can't be easily changed with the use of refactoring tools later on, once the pilot was delivered out to the wild, is more ...


1

Kinect manager can store Kinect data and emit an event or signal. Every other object listening to this event or signal can act upon it and retrieve these data. This can be particularly useful if the other objects will not duplicate Kinect data to some other storage.


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


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


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


0

You could use the Template Method Pattern. Here is how. Have an abstract class that will be the parent and define the way things are being loaded from the database. Loading method will be an abstract method returning a generic value. Connection string will be an abstract property. Once you extend other classes from this parent class you can then define ...


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


-5

If you create objects with new you can access your prototype with <object>.constructor.prototype If you use Object.Create you no longer have this (unless you add it yourself) and that is why Object.getPrototypeOf(obj) was added. So there always was a way to get the prototype: when getPrototype didn't exist Object.Create didn't exist either.


0

You could try a while instead of a for loop. while($I->valid()) { echo $I->current(); $I->next(); }


0

This is really a question about what went through Eich's mind when he designed the language, so it's only really him who can answer. But if I should venture a guess, I would say the initial version of JavaScript was a quick-and-dirty prototype and he expected to be able to iron out inconsistencies and missing features in subsequent releases. But then it was ...



Top 50 recent answers are included