Tag Info

New answers tagged

-2

Pass a whole object, but, select from databse only that fields that you eally need. You will get object with three filled properties, and others properties will get defaults. Such way it will be simplier to fill other properties with data just by adding field name to query, without changing method's signature.


3

I have an object that has about 50 properties, Stop! Go - right now - and fix this. Of course you're going to run into functions that only use part of your object, when your object is doing everything under the sun. No object needs 50 independent properties. Certainly some of them can be organized into sub-objects. Those three that your function takes ...


0

It sounds like you have a good grasp of the issues involved. I don't know specifically whether Dapper makes a difference in your strategy, but in general you only want to return the data from the database that you need. Will you have to alter your query if you need another property in the future? Of course, and that's the downside of returning only what ...


0

A project I worked on did something similar using MEF plugins which sounds like the way to go for this project. Other plugin frameworks are available. The application would be comprised of multiple parts - A lightweight host that is a simple updater/launcher that merely queries a server to find out what plugin it needs to download and execute. The ...


11

If you design a system where 20-30 people all have to edit the same class of your codebase on a daily basis, I would say you will have a pretty big organizational issue and a pretty big architectural issue as well with your system. If such a class is a facade or something else is irrelevant. To solve these issues, I would start with splitting the teams to ...


0

It looks like you are using your observer as both a publisher and a subscriber, while the Provider is only a publisher. Or is it both too? This seems a bit confused. Maybe you should make some kind of Bus or Queue that you can both Publish and Subscribe to. There are so many complexities in messaging that you really should make a distinct component be ...


0

Are there any drawbacks to modifying the Subject Observer design pattern this way? Well, yeah. What I see is backwards, inside-out; an incorrect implementation The observer (ObserverClass) should not be the notifier - the notifier is your ProviderClass. The notifier notifies, the observer observes. Having the ObserverClass calling the providers ...


0

In a similar situation I am using a state machine. The fact that your rule needs the source of the event tells me that your rule must consider the context of the event, i.e. the state your are in. In my suggested state machine scenario your model would be like this: You represent the "world" in your application by defining the possible states with ...


1

You can't add stored properties, but you can add computed properties. A computed property can act just like a stored property. In fact ObjC provides a handy set of calls to make that if not actually easy...well, at least not hard. Performance might not be where you want it, but if performance is a big deal let the profiler tell you when you should give up ...


0

To answer your original question (in title), a Builder is by definition a very stateful object, so after issuing the final "build" and obtaining the constructed object, the Builder is discarded - never re-used.


0

I think you should make the owner responsible for managing their charges, and simply pass the task to the owner. That way the task never has to touch the plan at all. I don't think your alternative is really that much better because a task still has to know about a plan and know that it's responsible for determining the cost. Here's an example, I'm ...


0

I guess your Rule class is an example of specification or command pattern. Definitely different rules will need different types of information to do its work, but if it were me, I would not pass those information during method invocation, I would use constructor instead. The information that is different from one rule to another is the implementation detail ...


0

I'll go against the grain slightly from the advice of "keep coding good/slow" and "find a new job" that you'll be receiving in the other answers, in case neither of those options are desirable for you. Here's the sad truth: Sometimes its better to write crappy code that conforms to the team's style than it is to write good code that goes against the grain. ...


1

Should I use DataTable and shove it to gridview just like the rest of my team do? Hell no. That's just bad code. It's ok code for very small uncomplicated projects that are unlikely to change and has a database schema that will rarely if ever change. Or for quick one-off-projects. Otherwise that is bad code practice and it will come back and bite you in ...


2

Automated testing Invest your time in automated testing. It will pay you off very quickly. The basic idea is that if you do manual testing only, you'll be unable to handle the ever increasing number of tests. It is not unusual for even a relatively small application to have thousands of tests, not counting integration, system, functional, load and other ...


2

Just think of a decorator as having 2 functions: adds/modifies the functionality of the original class. In order to do so, it needs to have reference to the original class, and therefore need to have composition. look the same as original class to the client. By look the same, I mean from the client's perspective, they will not know and don't need to know ...


4

Decorators usually augment the original functionality in some way, not replace it altogether. So they need to hold a reference to the original object. For example, a decorator that adds memoization to a function will need to be able to call the original function if its result is not found in the cache. However, the calling code should not need to know if ...


1

if any of the methods fails, there is really no point in calling subsequent methods. How should I address those possible method failures? Throw an exception. Should the Carousel class be 'injected' into my class before it is used? Yes, if there is more than one implementation of Carousel (including the possibility of a mock object for unit testing ...


1

Normally, no. The callback is part of the API exposed by layer B. The API of Layer B defines the form (prototype) of the callback, the API of Layer B defines the functions to register and unregister the callback, and Layer B defines the conditions under which the callback will be invoked. Furthermore, since the callback gets registered, it will work even ...


3

You might also look into expert systems, business rule engines, declarative programming, inference engines, A* search algorithm, Rete algorithm, Prolog, Datalog, CLIPS, metaknowledge, metaprogramming, reflection, etc... J.Pitrat's blog has interesting entries, e.g. Know thyself etc... Is there a programming pattern that allows me to make an extendable ...


1

Your problem is comparable to a program simulating a chess player. When in need of using a set of knowledge rules to produce the most suitable decisions, the logic programming seems to be the ideal solution. Using such a programming language (like Prolog), you can define the whole set of rules that govern your 'world', and finally you have to create a query ...


2

It seems that you are not asking how to implement undo, since you've already chosen to work with Qt's Undo Framework, which already has an implementation to hook in to. If I understand you correctly, you are more interested in where to implement the necessary code. It seems that you have tried implementing it in two places which leads to complexity in ...


3

An Item-Class is there to tell you about data relating to items, and perform business logic that is centered around them - so making it able to tell you its price for a given customer and quantity, its main-image-filename or some such doesn't seem like a violation of the Single Responsibility Principle. Yes it is a violation of the SRP. It is ...


7

I would go with the anemic domain model here. Consider the example of your ItemImageFinder. Consider a few scenarios: You decide to extend your system to also include Image thumbnails, or including alternate images. Now you need to modify your Item behavior. Clearly this is not the only reason for Item to change, so you are violating SRP. You either have ...


2

As always, it's useful to think about the pros and cons of each approach: Pro passing in SQL It's flexible. If you have a lot of different queries that are difficult to parameterize you won't end up with a ton of methods, or having to design around it. Anti passing in SQL It's generally a bad idea to present a larger interface than is necessary. The ...


0

I think the question needs to be split into two parts. Firstly, what is the role of the POCOs representing your database objects, and secondly, how best to structure repositories to deal with them. In answer to the first question, you seem to have chosen to map your POCOs directly to database objects- one class exactly represents on table, or one view. ...


0

I think there are too many methods to your repositories. This pattern is better (IMO). First of all you should have a repository for every table, and if your program uses the two tables together you should create another repository for the ColorAggregate (ColorHeader and ColorDetail together). The ColorAggregate object can be read from the db (from a view) ...


-1

If there is no difference between GetColorHeader and GetColorHeaderView, I think you should remove GetColorHeaderView method and use data in ColorHeaderView view to make GetColorHeader. Your repository using no need to know detail of your database implementation.


3

Passing SQL into the repository is definitely not a good way to go about things. It violates the single responsibility principle because the client uses the repository and also tells it how to work instead of it using the repository and the repository knowing how to work itself.


0

Traditionally, your dependencies would descend downwards in your application. That is, you would have a high level class A, which depends on a lower level class B. Consider a car. In traditional programming, your car object would depend on your steering wheel object, which would depend on your two front wheel objects. This means that if your wheels ...


0

I would go with Option #2 to eliminate the duplication, as you mentioned. I am not sure of the performance implications of joins and grouping here but I do believe it's a cleaner representation of the data. That said, I would consider using a graph database like Neo4J or Titan. It simplifies querying these types of relationships.


2

Not that you can't but for me personally it is a code smell in a sense that your base class is supposed to facilitate the creation of its derived classes but not help them with their method implementation. I'm not sure if this assertion is necessarily true. I can think of many examples where it's accepted for base classes to provide functions ...


1

...Is this design desperately wrong? No. You can serialize circular references using JSON I don't know what's the Python-approach. But from the specification point of view I've heard that json pointer fragment might be the internet search query Wikipedia → JSON → Object references is not very clear on this subject and emphasizes the implementation ...


1

To avoid circular references, only a parent node/class should know about it's children. Accessing Game as the root node should allow you to gather information anywhere you need.


2

The problem is that the implemented methods in derived classes are very similar, varying mostly in respect to how the location of the disk is stored. This is not a problem. The point of object-oriented design is not to reduce the total amount of code by factoring common code into superclass methods. The point of object oriented design is proper ...


3

I would say that it is the Single responsibility principle. Even though it was first applied to Object Orientation, the underlying principle is valid even on non-OO environments - one thing, one job. In object-oriented programming, the single responsibility principle states that every class should have responsibility over a single part of the ...


14

It's consistency, or also "principle of least astonishment". However, your less formal definition seems fine too, more pragmatic.


0

Not sure if this answers your question appropriately, but I would advise against using EF or Nhibernate or any other large ORM for non classic DB structures. I highly suggest using a microORM such as Dapper, petaPOCO, or Susanoo (full discretion Susanoo is my open source project). EF for instance has some pretty stringent rules and conventions that don't ...


1

State diagram with timing is great way to model your situation. This is both understandable and easy to implement. The "movement detected" could be understood as transition from movement being detected to no movement being detected. You could make it better if you had "movement started", "movement ended" and "movement continues" transitions.


4

You can use a variable with 3 possible states: someone at home nobody at home indeterminate These states are mutually exclusive, so it will make sense to use them for modeling. Whenever the door gets opened, set the state to "indeterminate". Whenever the door gets closed, start a timer, and when the timer ends, you change the state to "someone at home" ...


5

The concept you are looking for is known as "Hysteresis" (Wikipedia). But don't waste too much time reading the article, as your situation is rather simple. You have a number of inputs, which have states, and you also have a "logical state" (person in or out of home) which you need to compute out of them. The "logical state" cannot simply be a direct ...


3

DIP states that Higher level module should depend on Lower level module over abstraction and All variable implementations require Factory Method.Ref: DIP So, creating a Factory Class definitely a good option to resolve your problem. In addition, you could inject both IReader and Iwriter to your Person class. public class Person : IReader, IWriter { ...


14

Enums do not create brittle interfaces. Misuse of enums does. What are enums for? Enums are designed to be used as sets of meaningfully named constants. They are to be used when: You know that no values will be removed. (And) You know it is highly unlikely that a new value will be needed. (Or) You accept that a new value will be needed, but rarely enough ...


4

Enums are a great improvement over magic identification numbers for closed sets of values that do not have a lot of functionality associated with them. Usually you don't care about what number is actually associated with the enum; in this case it is easy to extend by adding new entries at the end, no brittleness should result. The problem is when you have ...


1

If you are careful in how you use them, I'd not consider enums harmful. But there are a few things to consider if you want to use them in some library code, as opposed to a single application. Never remove or reorder values. If you at some point have an enum value in your list, that value should be associated with that name for all eternity. If you want ...


1

A third option might involve creating a class to manage the state of your books, then sharing an instance of the class with your Person and IReader implementations. This is conceptually similar to having a book repository or cache. Option 1 or my suggestion are probably the cleaner solutions. Can you provide more information about the overall problem you ...


15

Any change to the ColorChoice enum affects all IWindowColor subclasses. No it doesn't. There are two cases: implementers will either store, return and forward enum values, never operating on them, in which case they are unaffected by changes in the enum, or operate on individual enum values, in which case any change in the enum must of course, ...


21

When used properly, enums are far more readable and robust than the "magic numbers" they replace. I don't normally see them making code more brittle. For instance: setColor() doesn't have to waste time checking if value is a valid color value or not. The compiler has already done that. You can write setColor(Color::Red) instead of setColor(0). I believe ...


1

Eric Evans Domain Driven Design specifies that you should provide a repository for 'aggregate roots' that need direct access. So this is not one repository per model but one repository per cluster of models, if you like. This assumes you are doing DDD and therefore understand the business context, though.



Top 50 recent answers are included