Tag Info

Hot answers tagged

7

This seems like one of those common "favor composition over inheritance" scenarios. A RestController serves as an endpoint for REST calls. Not something to govern Authorization. Not something to control the HttpCache. It's a violation of the Single Responsibility Principle. Instead, you should have classes (strategies if you'd prefer) to govern these two ...


5

All three are wrong, because you are storing connection strings in source code. Source code is not the right place for configuration, because you are not expected to have to change your code (and so, do all the regression testing) every time your database moves or every time you move from development database to staging and to production database. Instead: ...


5

To be clear, none of "refactoring", "abstraction" or "encapsulation" are design patterns. Neither is what you posted. As you say, it is a refactoring. Specifically, it is the one that Martin Fowler named Extract Method. The definition is "Turn the fragment into a method whose name explains the purpose of the method.", which is precisely what you are doing. ...


4

create a collection (map, dictionary, etc) of requests to objects. In ProcessRequest, you iterate through the collection to find an entry that matches the input request, and call the associated object. Then you only have to populate the collection, but this can be done by reading configuration or by having each RequestData class register itself at startup ...


3

The way this is normally done is with user roles and a role access matrix. Each user has a role, saved in the database along with the user name, password, etc. Then, there is a two-dimensional role access matrix somewhere, specifying for each role and for each screen field what kind of access is to be had by users who have that specific role on that ...


3

You are very confused. A lower level becomes dependent on the abstraction defined in the higher level No it doesn't. It depends only on the abstraction that it has defined itself. For instance, a TaxAuditImpl might depend on the interface TaxAuditor that it satisfies. However, it does not depend on the SuperDuperPersonalFinanceManager that uses the ...


3

Like Ixrec said - put the implementation in another file. But since you need a state that you don't want to make global - put that state in a class! OK, that came up a bit confusing. What I mean is to keep the class, but hide it from the user. The user will only see a global function that internally creates the class and call it's go method. Actually - ...


3

I do not think this practice has a special name, I would call it "encapsulation", "creating an abstraction by utilizing a class", "class design", or simply "OO programming". And it is definitely not an anti-pattern.


3

I guess the "correct" way to do this is to have a protected constructor on the base class which requires the state name as a parameter. public abstract class State { private readonly string _name; protected State(string name) { if(String.IsNullOrEmpty(name)) throw new ArgumentException("Must not be empty", "name"); ...


2

Your requirements are a contradiction: I'm trying to create a String property for each State called StateName. vs. But I don't need to implement all of that in each State. There's no language feature that allows you to force the existence of a member in only a few sub classes. After all, the point of using a super class is to rely on the fact ...


2

But it forces the lower level abstraction to be defined inside the higher level. No, it does not enforce this. The "lower level abstraction" (the interface, like ILogger in your example) can be defined outside the "lower level" and the "higher level" component, it can reside in a third, independ DLL which serves only for the purpose of providing the ...


2

Maybe i missunderstood the problem, but it looks like these are actually separated entities. I would personally not use inherence but favor composition. I would create different classes for each entity implementing an ITrackable interface and simply define the GPS as an object in these entities. Using an Interface An IReportable interface can also be ...


2

I want the new subtypes to inherit the way they are handled from their base type The classic GOF visitor pattern behaves exactly like that. For example, look the Wikipedia CarElement example (it is a Java example, but the important part is similar in C++). Lets assume you add new Wheel types like SquareWheel, RoundWheel by inheriting them from Wheel. ...


2

If the logic for choosing the next state is a part of the Algorithm classes, then clearly they must be able to communicate the specific state to change to to the Context class. If the concept of states to change to is useless without the 'context' object (hard to tell), passing a reference to the context object should be fine - the algorithms and the ...


2

There's nothing wrong with having distinct methods in your web service. This makes the service have a very explicit contract and it should easy to use for your clients. For example, your initial service may have: GetDeadlineOrders GetProcessedOrders If you have to add another method in the future like: GetExpiredOrders Your service is forward ...


2

Uncomfortably long argument lists and multiple return values can usually be addressed by grouping values into structured data types or encapsulating them in classes. If there are no clear groupings, hiding that by sweeping it into object state with other unrelated values is only furtherly detrimental. Methods (even methods intended to be private) should ...


2

If I understood your colleague's suggestion correctly, the solution proposed was to have a web.config key that contains a type name for the implementation class. You can use this name to retrieve the type, instantiate it (or register in DI container), and use it. I.e.: public interface IAuthenticationBlaBla { ... } public class ...


2

Is there a name for splitting interfaces by accessors and mutators into separate interfaces? There could be a name for this if this seperation is usefull and provides a benefit which i donot see. If the separatons does not provide a benefit the other two questions make no sense. Can you tell us any business use-case where the two seperate Interfaces ...


2

You needn't worry about your ViewModels having more functionality than just providing data. That is, after all, their true function - to provide the data for display and any functionality required by the View. ViewModel's will normally contain properties, ICommands, at least one model and any references to services and repositories required to deal with ...


2

What you are looking for is commonly called mixins. Sadly, C# doesn't natively support those. There are few workarounds : one, two , three, and many more. I actually really like the last one. The idea of using automatically generated partial class to generate the boilerplate is probably closest you can get to actually good solution : [pMixins] is a ...


1

There are several things to consider here. It is worth reading up on the HTTP specification, specifically about idempotent rules, and to also consider a RESTful style of webservice interface. In short, if you implement a webservice with GET or HEAD, then in theory it should be safe to call multiple times with the same parameters, but webservices that are ...


1

What language are you using? Depending on the language(synchronious, asynchronious) you will have different solutions. If it is JavaScript, promise is indeed the way to go. Promises in JavaScript If it is something like C#, you probably don't want to have a loop like you indicated, because you will be blocking the thread. In that scenario, I would look ...


1

No i think you're right. Of course you could also design your interface to be more flexible regarding querying. Let's just call it "design ahead". But of course this conflicts with YAGNI. So you'll need to compromise. Another alternative would be to run the old and the new service version on different ports /URLs - thus getting rid of the downtime. You'll ...


1

This is a natural progress of encapsulation, abstraction, and general code organization. As you extract pieces of code from a function into their own separate functions, you may notice that they share a lot of state that requires passing numerous parameters around. Promoting this state to fields of a class -- and said functions to methods of the class -- ...


1

In original Strategy pattern a strategy is injected into consumer. The code that is creating both consumer and strategy is responsible for choosing appropriate strategy. It is easier so if you can you should better stick to this approach. However, your problem is not uncommon - strategy has to be chosen in runtime based on input parameters. I see here two ...


1

I would suggest: divide and conquer the problem use components and keep each component focused on its main purpose decouple you system by using an event aggregator (EA) use interfaces where an EA doesn’t make sense I would try to split the big problem in smaller problems and then try to solve them by its own. The smaller problems can be solved easier by ...


1

You could consider using a mediator to decouple parameter event dependencies. This is sometimes known as an Event Aggregator. Your individual parameter classes are wired up to publish and subscribe to events directly through the EA. The following example uses Reactive Extensions but you could implement a simple version yourself using callbacks for ...


1

Create a Parameter class (assuming C#): class Parameter<T> { T Value; string Name; } Then build a graph with nodes containing Parameter values and dependencies as their references in the same graph. And next do all the operations on the graph as a whole, not directly on parameters: graph.SetValue(parameter, value) or ...


1

Some time passed and now I think that I can answer myself. There is no sense to make an adapter when two interacting classes are located in the same dll. For such case it makes the code more complicated and difficult for refactoring but does not provide any benefits. If you want to reuse some functionality you still need to reference the whole dll so don't ...


1

You could create list of classes responsible for each operation, where and when it makes sense for example, public abstract class MainActivity extends SingleFragmentToolBarActivity<T> implements Drawer.OnDrawerItemClickListener { .... private void setUpNavigationDrawer(Bundle savedInstanceState) { NavigationDrawer drawer = new ...



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