Tag Info

New answers tagged

4

FP does indeed strive for a reduction in the representational gap: Something you'll see a lot of in functional languages is the practice of building the language up (using bottom-up design) into an Embedded Domain Specific Language (EDSL). This lets you develop a means of expressing your business concerns in a way that is natural for your domain within the ...


5

Most functional languages are not Object-Oriented. That does not mean they have no objects (in the sense of complex types which have specific functionality associated with them). Haskell, like java, has Lists, Maps, Arrays, all kinds of Trees and many other complex types. If you look at the Haskell List or Map module you will see a set of functions very ...


2

As Niklaus Wirth put it, "Algorithms + Data Structures = Programs". Functional programming is about the way to organize algorithms, and it does not tell a lot about ways to organize data structures. Indeed, there exist FP languages both with mutable (Lisp) and immutable (Haskell, Erlang) variables. If you want to compare and contrast FP with something, you ...


7

I would like to stress an aspect that I find important and that has not been covered in the other answers. First of all, I think that the representational gap between problems and solutions can be more in the mind of the programmer, according to their background and to the concepts they are more familiar with. OOP and FP look at data and operations from ...


18

The basic data is structured the same in pretty much any paradigm. You're going to have a Student, a Course, etc. whether it's an object, a struct, a record, or whatever. The difference with OOP isn't how the data is structured, it's how the functions are structured. I actually find functional programs much more closely match how I think about a problem. ...


9

When I took my Java class years ago, we were expected to show our solutions to the entire class, so I got to see how people think; how they solve problems logically. I fully expected the solutions to cluster around three or four common solutions. Instead, I watched as 30 students solved the problem in 30 completely different ways. Naturally, as fledgling ...


0

It is difficult to tell without having more conetxt information on what the class does, but I faced the same problem once and I took the composition approach to refactoring. The first approach looks like the decorator pattern to me. Depending of what the nature of your class is, it could be a good solution but without knowing much more I can't tell. Back ...


0

With the constrints you having (unable to use a common interface) for ModelA and for ModelB, there isn't a lot of things you can do from the Models. However you could generalize the helper class. One way to do is, public class RequestDTO { string xyz_blah; } public class ResultDTO. { string ProductCheckField; } public class HelperClass { ...


0

Similar to what Robert Harvey proposes but instead of logging or signaling an exception when the boolean switch is true or false, always signal the exception and use a different exception handler depending on the switch. For instance, if the switch means to log silently, your exception handler should do that. Otherwise the exception handler would just ...


0

What you have shown of the Models shows the same interface. So your protestations of differences are unsupported by the example you give. I suggest you wrap the fields you check in performX and checkY with accessor methods that are commonly named across model A and be and extract a common interface for the use of your Helper class. public interface ...


1

Personally I would be using factory methods to create each of these objects and would forget about the additional inheritance you have designed. The form of this would be a ReportFactory class and a SystemFactory class that would have their own creation methods. In the creation methods you would instantiate the required class, and then perform the ...


1

If it's just one API or function call, include a boolean switch in the function call that allows you to switch the error behavior. If this is something you want to implement on a system-wide basis, the best way to do it is probably in whatever logging strategy you are using. You can use a configuration setting to tell the logger to either log the error or ...


5

I'm assuming that the input that your code receives is the string representation of the function anyway, so there's no avoiding a string checking. There is, however, ways to avoid some of the other problems you've noted. I would go with your option #2, with the following caveats: Shared code should be shared Rather then extending Function, create an ...


0

I would start by moving any code that implements or supports the implementation of any delegate or data source into their own classes. So for example if you have a screen that contains a table view inside a navigation controller, move the tableview's delegate and data sources into separate classes and inject them into the VC. The once you've split up all ...


1

The answer is wrapping, but it is considerably more work than implied here. I see why you are trying to do this though, because after a certain size of the code base it indeed can be a nightmare to work with typecasting every time you call a library function. Subclassing CustomList is not advisable, as it would expose all the functions that return or expect ...


2

In times like this I try to step back, forget the implementation, and focus on the requirements. Essentially, you want to: - Define discrete entities using primitive data elements - Validate entities using domain-specific rules - Construct a domain model from valid entities - Perform useful and interesting computations with your domain model If you're in ...


0

One option is to use a parameter object. Take the parameters required by every instance and bundle them as a seperate class. See also this question


5

The Builder pattern is most useful when the product you are building consists of multiple discrete parts, where external information specifies which parts, or if the product has many optional properties. In your case, you have a long list of required properties. Here the Builder pattern only gives you the appearance of a less complex constructor at the cost ...


2

There is no way to logically group these into different objects to reduce the amount of parameters passed into the constructor. I think this is the essence in your problem. First, the Builder pattern is normally used in this situation as best practice. However, for me personally, I don't like it and even consider it an anti pattern. You in some way ...


0

It's hard to understand fully what you need done here. It looks like you MIGHT have a case for the Visitor pattern but you said you can't use the same interface. The only other alternative would be the Strategy pattern where the CheckMethod would be implemented in a strategy class for each Model and instead of the overloaded methods you can use generics to ...


2

You seem to have some sort of mental block going on. If you want a design that eliminates the duplication, you're going to have to change your design somehow, which you seem resistant to do. You need to look past your current design. Some ways to eliminate the duplication, some of which are better than others: Put the common stuff of the models into a ...


0

When I am writing code, I do not plan on deliberately using as many design patterns as I can. But, I guess, sub-consciously, when I get a coding problem, one of the design patterns seems to fit, and I just use it. And sometimes nothing fits. What is more important to me is writing code that does the job and is easy to maintain and grow. Here is an article ...


-1

I did following code, so I could measure the time in either option. public static void multiple() { long start = System.currentTimeMillis(); for (int i = 0; i < 100_000_000; i++) { Instance instance = new Instance(); instance.rand(); } long end = System.currentTimeMillis(); long time = end - start; ...


0

I would say you should initialize just one d20 object for your application. The inspiration for this style is that a real life DM only has one D20. He doesn't have a whole box where he pulls one out, rolls it, and throws it away. You should not assign a dice property to your RPG characters simply because RPG characters don't roll dice, the dungeonmaster ...


2

Have any class that requires a random number source accept a Function<Integer, Integer> (or any equivalent functional interface you like) in its constructor. Create a static method int rollDie(int sides) that generates a random number from 0 to sides, inclusive. This avoids the redundancy of rollD20, rollD8, etc. Interally this'll probably just be a ...


4

First, I would not call the class Dice. Rather call it DiceShaker or so and give it a method so you can call diceShaker.roll1W20() or even better, create different diceShakers (by composition/extending) for different purposes and make DiceShaker an interface. Next, yes, it is good if you create a single instance that you pass to all the classes that need a ...


4

When the method doesnt remember a state a static Mehtod should be okay. java's shorthand random number method in the Math class (Math.random() ) is also a static method.


5

Hold a meeting and decide which factors (ease of use, scalability, etc.) you are going to use to judge each framework. Then, write a small prototype application, making several versions that use each of the different candidate frameworks. Have another meeting (code-review style), and evaluate each of the frameworks on the factors you decided on in the ...


0

You could implement permissions using the type object pattern http://gameprogrammingpatterns.com/type-object.html So each of your users would have a type property that defines their type in 1 of 2 ways. differing type object properties eg. typeName type object inheritance hierarchy 1 has the advantage that all type objects are of the same class and thus ...


0

After you read Evans' book, you will see that DDD is a collection of concepts. The book was written over a decade ago. My opinion of it today is that it has good parts but is easily misunderstood and sometimes used inappropriately. In reality, some parts you may not need or may not be right for your application or chosen tools. As far as EF, I don't think ...


1

How do I reduce the duplication without losing the expressiveness of having different classes? By considering the scenarios in which your program interacts with the scripts, as stated in your top-level description: Get a list of scripts off the filesystem Execute the appropriate migrations on the database The first decision is which up or ...


1

The solution with the abstract base class is the way to go. To reduce duplication in the code that determines which scripts to process, you can introduce a factory class/method that creates either a UpScript or a DownScript instance based on a parameter (the same parameter that determines if the scripts with the "_up" or the "_down" suffix should be used). ...


2

My C# is rusty, hopefully I haven't glossed over any language constraints. I would implement UpScript and DownScript as interfaces that have the same members: public interface IUpScript { public long Version { get; private set; } public string Name { get; private set; } public string Content { get; private set; } } // ... public interface ...


1

I think your solution with the abstract base class is just fine. It's common OO programming: you have an abstract type with two different implementations. You should not worry about about duplication of creating two classes. In a language like Scala that provides some syntactic facilities, you can define such cases in a more concise way, but for C# and Java ...



Top 50 recent answers are included