Hot answers tagged

130

Using a custom object to group related parameters is actually a recommended pattern. As a refactoring, it is called Introduce Parameter Object. Your problem lies elsewhere. First, generic Window should know nothing about Student. Instead, you should have some kind of StudentWindow that knows about only displaying Students. Second, there is absolutely no ...


49

The "pattern" you are looking for is called "logging", just make the logging statements as verbose as you need them. By using a decent logging framework you should be able to switch it on and off at run time, provide different verbosity levels, or tailor the output for different purposes (like web vs. console). If this has a noteable performance impact ...


25

You say it's not quite easy to test individually, because it needs a real Student object to call the function But you can just create a student object to pass to your window: showInfo(new Student(123,"abc",45,6.7)); It doesn't seem much more complex to call.


21

In layman's terms: What you call a "custom object" is usually simply called an object. You cannot avoid passing objects as parameters when designing any non-trivial program or API, or using any non-trivial API or library. It's perfectly OK to pass objects as parameters. Take a look at the Java API and you will see lots of interfaces that receive objects as ...


19

I disagree with your assertion that it is a red flag. I also disagree with your representation of the counterpoint, that there is One Right Way of representing a Builder pattern. To me there's one question: Is the Builder a necessary part of the type's API? Here, is the PersonBuilder a necessary part of the Person API? It is entirely reasonable that a ...


11

There are some posibilites, how to mock static methods in PHP, the best solution I have used is the AspectMock library, which can be pulled through composer (how to mock static methods is quite understandable from the documentation). However, it's a last-minute fix for a problem which should be fixed in a different way. If you still want to unit test the ...


9

Neither is generally better than the other. It's a judgment call you have to make on a case-by-case basis. But in practice, when you're in a position that you can actually make this decision, it's because you get to decide which layer in the overall program architecture should be breaking the object up into primitives, so you should be thinking about the ...


7

I understand how annoying it can be when 'appeal to authority' is used in a debate. Arguments should stand on their own IMO and while it's not wrong to point to the advice of such a well-respected person, it really can't be considered a full argument in itself ala we know the Sun travels around the earth because Aristotle said so. Having said that, I think ...


7

A good pattern is Observer. https://en.wikipedia.org/wiki/Observer_pattern In your algorithm, at each point where you want to output something, you notify some observer(s). They then decide what to do, be it to output your text on the console, or to send it to the HTML engine/Apache etc. Depending on your programming language there may be different ways to ...


7

Idiomatic C# generally favours properties over accessor methods for simple properties, so just use a property unless there is a good reason not to. If there is complex logic in the getter or setter, it may be better to use accessors to avoid breaking the Principle of Least Surprise. For a canonical example, WPF checkboxes use a property - although a bool? ...


5

The author of 'Functional Programming in Scala' gives a nice illustration of the best that can be achieved in Java in a type safe manner: http://blog.higher-order.com/blog/2009/08/21/structural-pattern-matching-in-java/ Essentially, it uses a Church-encoding of the cases to ensure that the compiler will complain if any are missing. The details are not ...


5

"I think it would add a level of complexity to the app" ... opposed to what - using just one schema for all tenants? Then typically the opposite is true. Implementing multi-tenancy in one schema adds the complexity to each and every table where the data might belong to different tenants, which means this kind of complexity will go also into your app. ...


5

Perhaps it's because I used C/C++ in a previous life but I would argue strongly for keeping the enums simple. In those languages an enum was a glorified integer only. In Java, as you say, they are really a true object. But I feel that the spirt of an enum is not to have a ton of code in there - an enumeration is a complete, ordered listing of all the ...


4

I'm sure there are situations where this would make sense to do, particularly if you're writing a small application, but in general I think it would be a bad idea. You could apply any argument that you could make about global variables to static variables - they're still changeable anywhere in the application. If your application (and dev team) is ...


4

To answer why a type would be coupled with a builder, it is necessary to understand why anyone would use a builder in the first place. Specifically: Bloch recommends using a builder when you have a large number of constructor parameters. That isn't the only reason to use a builder, but I speculate it is the most common. In short the builder is a replacement ...


4

As a slight improvement to straight logging, create some sort of object that models one execution of the algorithm. Add a "step" to this container object each time your code does something interesting. At the end of the algorithm, log the accumulated steps from the container. This has a few advantages: You can log the full execution as one log entry, ...


4

This could be solved by using event driven programming and a few observers. How many things does this method do? public void submitThing(Thing thing, SubmitData data) { thing.setStatus(SUBMITTED); thing.setData(data); documentService.doSomething(); mailService.doSomething(); } Three. It does three things. Submits the thing. Does ...


4

In your student example I assume it is trivial to call the Student constructor to create a student to pass in to showInfo. So there is no problem. Assuming the example Student is deliberately trivialised for this question and it is more difficult to construct, then you could use a test double. The are a number of options for test doubles, mocks, stubs etc. ...


4

I think there is nothing wrong per se to have getters in your builder class allowing to inspect which data was passed in. As Robert Harvey stated, getters are not part of the pattern, but sometimes a pragmatic solution is better than sticking to some doctrine. And there is not "the one and only correct way" to implement a pattern, design pattern always give ...


4

Create a Scanner or Tokenizer class, which takes the input data (the text to be parsed) and holds the position of the current token or similar state. It can also provide some shared helper functions. Then provide a reference (or a shared pointer) to the Scanner object to all your individual xyzParser objects, so they can all access the same scanner. The ...


4

First, I would suggest to split this up into separate methods: public function validate($value, Constraint $constraint) { $totalCount = QueryTotal($value); ShowMessageWhenTotalExceedsMaximum($totalCount,$constraint); } private function QueryTotal($value) { $searchEntity = EmailAlertToSearchAdapter::adapt($value); $queryBuilder = ...


3

Circular references are required for certain data structures, such as doubly-linked lists. So, circular references are not inherently evil. Circular dependencies between libraries, projects, subsystems, or layers are usually really bad. Such dependencies often involve initialization & termination issues, which tend to thwart reliable library or ...


3

I wouldn't say you're using bad design. There is always a cost in coding--to win the most 'CS class' worthy / most object-oriented award isn't really what coding is about. Code is a tool, just like any other and like most tools--you invent uses for those tools as needed. I find it easier myself to use a static class for 'utility' type stuff as you have ...


3

I think you've got a pretty good understanding of how decoupled software works :) The only doubt in my mind, is that now both the application, and the device's concrete class both depend on the library that contains the IDevice interface. But, is that a bad thing? It doesn't need to be! I also don't see how the application won't need to know about ...


3

REST maturity levels and DDD are orthogonal concerns. Your Ubiquitous Language doesn't care whether it's reflected deep down in the payload of a SOAP message, in a resource URI, or in a domain-specific content type, as long as it remains pervasive and coherent throughout its Bounded Context. If your Bounded Context includes both the client and server ...


3

Given a variable which needs to have a scope beyond a single function call, yet be accessible by only one function, I believe it's okay to not introduce a new scope just for that one function as long as you don't make the variable global. In other words, I'd put this variable at module scope. You should already have some kind of module system which prevents ...


3

This is not a good idea because you can introduce a race condition. In one thread you change the value to one you want but before you manage to create an instance of the class another thread changes the value, and you get an instance created with the wrong default value. Your hair will grow whiter than mine, trying to figure out why things aren't working ...


3

Steve McConnell in Code Complete addressed this very issue, discussing the benefits and drawbacks of passing objects into methods instead of using properties. Forgive me if I get some of the details wrong, am working from memory as it's been over a year since I had access to the book: He comes to the conclusion that you are better off not using an object, ...


3

It is much easier to write and read tests if you pass the whole object: public class AStudentView { @Test public void displays_failing_grade_warning_when_a_student_with_a_failing_grade_is_shown() { StudentView view = aStudentView(); view.show(aStudent().withAFailingGrade().build()); Assert.that(view, ...


3

According to the collection of embedded system design patterns at http://www.eventhelix.com/RealtimeMantra/Patterns/, what you're talking about is called the Serial Wait State Pattern, which contrasts to the more flexible/efficient but harder to use Parallel Wait State Pattern.



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