New answers tagged

0

A conventional approach (i.e. an approach that adheres to conventions found in the CLR and elsewhere) would be to use the built-in interfaces that represent collections, e.g. IList<T> or ICollection<T>. public interface IGeoEntityCollection<T> : ICollection<T> where T : GeoEntity { } public class GeoEntityCollection<T> : ...


3

This is one thing that annoys me about OOP design. People think they can have these debates looking just at the interface, when there is a clear winner when you look at the actual implementation. There are a few big reasons why the convention is for the collection class to own modifications to the collection: The collection owns the physical memory holding ...


4

I think you are asking the wrong question, since you expect to find a braindead general design rule which tells you if this kind of design is "good" or "object oriented" (whatever that means). I doubt there is such a rule. Better starting thinking about the specific case and ask if the design can be improved to achieve some specific goals,...


1

I would not even approach this question from a technical (maybe even ontological) point of view, although Christophe is right, in the end it's just a bunch of bits. I'd like to address this from a more conceptual point of view, as it all boils down to a main concept of object-orientation, with the object Car being an abstraction of the class Car and the ...


-3

A "representation" can be anything. The only real rule is that it should have a referent: a "car" should have some real car that it refers to (or an imaginary car, if it is representing an imaginary car). Beyond that one rule, the only other thing that matters is a rule of thumb: symmetry. There should be a symmetry between the ...


2

In Vertical Slice Architecture (VSA) you are supposed to have a class for pretty much every operation you can do (as I understand it) Not literally every operation. Every cohesive group of operations. (And the article talks about slices, like "vertical layers", not just classes - a slice will often contain of more than just one class). A good ...


2

Actually, between objects of the real world and representations, there is another layer: Terms & Informations. In writing your question here, you have already used all three of those layers. Or maybe even just two. You have an abstract idea of what a car is. Something with four wheels, a motor, at least one dorr, at least one seat, a steering wheel and ...


-2

Yes, you're correct. There is one small caveat as James_pic mentions in a comment, "There's no inherent reason why car_object.drive() should not result in an actual car driving somewhere." Even if drive() does make some real car move (and not just your "fake" car), then the word "represent" is still accurate.


0

Object oriented programming was initially invented for the purpose of simulations. (The first OO language was called Simula and as its name indicates it was specifically designed for doing simulations.) In simulations you have objects representing things in the domain you are simulating. E.g. if you simulate traffic in a computer model in order to test some ...


6

Yes, it basically means what you said. The representation of an object is meant to correspond to the object - it tells you some information about the object, or it identifies the object - but it's not actually the object. "Represent" is an English word which is not specific to OOP. A photograph of a car represents a car, because it isn't a car, but ...


3

Is it really the intention, to make so many similar services/handlers/whatever-we-call-them? As far as I can tell, you only create so many similar services/whatever if you have so many similar user-facing features or API endpoints. Thus, if changing both a Customer's phone number and address requires me to fill and submit 2 forms, then VSA recommends to ...


-1

Semiotics You'll find that everything in IT is about representation. At the end of the day the computer itself is a fluctuating cascade of electrons across sand, or the dripping of fluid through a pipe, or the relative location of gears, cams, and spindles. What is Real? Is a really tough question (no, really). Philosophers have literally wrung each others ...


61

This question is not specific to software engineering: it applies to all disciplines working with information. In 1929, the Belgian surrealist painter René Magritte explained it very intuitively in a masterpiece of art called the treachery of images: the painting shows a pipe on a uniform background, and a caption in French "This is not a pipe". It ...


-1

OOP is a modeling technique. Any model is a representation. Both of your descriptions could be accurate, the second one would fit a simulation.


0

Ended up removing all classes in my codebase—outside of unittest.TestCase)—and just using defs: In [1]: import doctrans.transformers In [2]: doctrans.transformers.__all__ Out[3]: ['to_argparse_function', 'to_class', 'to_docstring', 'to_file', 'to_function'] In [4]: import doctrans.docstring_struct In [5]: doctrans.docstring_struct.__all__ Out[6]: ['...


3

The analysis aims to give a better understanding of what’s needed. It is not clear in your question if you need to automate a manual activity with a new system, or if you just need to document the activity and perhaps optimise some steps. If you’re in the second case: you could opt for structured analysis : it is based on one side on functional ...


2

You want to produce a high-level description of the roles & their responsibilities, which interact by providing and consuming (mostly information) with each other to accomplish work of the business.  I don't think you need to follow a formal methodology for that, but if I had to choose between those two, I'd pick SA since it focuses more on components, ...


0

Static is always better than non-static and worse than a free functions, which is worse than a pure function. Private is always better than protected which is better than public. 'Need to know' principle.


2

Including any public properties in base class is an anti pattern to begin with, or at least it's a code smell. In most cases, you should follow the tell don't ask principle, and the matters of property wouldn't even become an issue in the first place. In this particular case, the options could simply be a matter of render(), getDefault() and validate() ...


5

Having a property in the base class which is used in only one of several subclasses is a common antipattern. This can easily happen when creating the superclass, by either pulling too many things into the superclass when creating it or forgetting to pull the property into the new subclass (depending on how the initial refactoring happened). Better naming ...


3

The problem you describe is known as the "n+1 select problem" and is referenced in ORM software. It would help if you dug into this question https://stackoverflow.com/questions/97197/what-is-the-n1-selects-problem-in-orm-object-relational-mapping You either need to do a join and fetch duplicate data or do multiple selects. There are tradeoffs in ...


4

Yes. You can issue a query that returns customer_name | customer_id | item_id | item_name --------------|-------------|---------|---------- bob | 0 | 0 | chair bob | 0 | 2 | hat steve | 1 | 2 | hat steve | 1 | 1 | table And then construct 2 Customer instances,...


1

I’ll assume that your set of results is finite and that you perform the prioritization when the set is fully known. First naive approach The prioritization corresponds simply to a mapping function s(o, r)->int which takes as argument an object o of the result set to be prioritized, and the whole result set r and returns a priority score. You may then ...


2

Pipes and Filters The first point is that IN is the model. A given filter can only access this data. As far as the filter is concerned, anything it is given is perfectly mutable, and it can change it as much as it wants, even write that data to its own output. No two filters have to share a model. If they do then there are implied dependencies that filter 1 ...


3

The priorities aren't complicated - they're still just numbers. The logic that assigns the priority number is more complicated. Combining multiple factors by adding (or multiplying) them is normal - that way you can have an arbitrary number of classifiers and easily combine them without entangling the logic.


0

The Other Option Dependency via a reasonably defaulted property. class Kitchen { } class Restaurant { private Kitchen _kitchen; public Kitchen Kitchen { get { return _kitchen ?? (_kitchen = new Kitchen(/*reasonable defaults*/); } set { //an validation logic here ...


3

There is no one-size fits all answer here. Context is key. First option: hardcoded private dependency The main issue here is that you're hardcoding (and hiding) the Kitchen dependency of Restaurant. If you want to be able to unit test them separately, then you can't do that as you're now unable to test Restaurant without using Kitchen. In other words, any ...


1

I'd go for dependency injection via constructor and/or parameter passing. Let's debunk the cons: App now has to know how to instantiate Kitchen. There's no problem with that, as long as instantiation of concrete classes happen only in a factory class of factory methods (abstract factories, builders or any creational pattern that is suitable). Somewhere in ...


0

accept is a statically type-safe way to permit an if-ladder based on something's type. if ( thing instanceof Foo ) { Foo foo = ( Foo )thing; BODY1 } else if ( thing instanceof Bar ) { Bar bar = ( Bar )thing; BODY2 } else if ... becomes new ThingVisitor() { void ifThingInstanceOfFoo( Foo foo ) { BODY1 } void ...


0

In your particular example the memento doesn't really serve any purpose (or, at least, the reasons for having it aren't obvious). If you had a more complicated internal state that you didn't want to expose to clients, but you still needed a way for them to temporarily hold on to that state, then Memento helps. Simultaneously, you can have getters and setters ...


6

You do want to use pointers because you want to represent an object that can be present or absent, depending on the enclosing object's state. But dealing with raw pointers correctly is very tricky: Raw pointers are prone to bugs, segfaults, use-after-free vulnerabilities, memory leaks, and frequently break if exceptions are involved. The solution is to use ...


4

Do LSP and ISP contradict one another? No. These principles actually work in tandem, or at least part of their problem domain overlaps and tackles a similar issue. You could generalize them into the "don't claim and/or pretend to be something you're not" principle, as that sort of gets at the core issue that either of them focuses on. But to be ...


6

Alternatively, if I put interfaces "halfway" in the class hierarchy, LSP is nullified classes Rectangle and Square are no longer interchangeable Yes and no. Some things are mixed up here. And some are omitted. mixed up stuff LSP according to wikipedia if S is a subtype of T, then objects of type T in a program may be replaced with objects of ...


1

Well yes, your example violates these principles, since it doesn't really do anything. If methods are never used at all, they should be removed. That's not the point of the SOLID principles though. The point is that in a real world example, either Shape or one of its subclasses would actually need to be drawable and thus would need an implementation of draw()...


3

I think to do this right you need to detach the method names from the object blocks. The whole point of polymorphism is the separation of the interface from the implementation. It does not help to see the method names within a particular object block, that is only confusing. The method names should be on the outside, at the outer edge of the outer block. ...


2

In the second case, with polymorphism, animal1.move() will still invoke move() of the Cat. In this regard, the diagram is misleading. If you want to get this right and unambiguous in a diagram, you'd have to draw some kind of redirection of the call to the right method whatever the type that is used: a vtable-like presentation in your embedded box diagram ...


2

The builder pattern is meant to encapsulate the steps of the creation process: CarBuilder2 is a variant of Joshua Bloch's builder pattern. The main intent is to facilitate the creation of objects that require many parameters in their constructor. CarBuilder1 is a lighter variant of this pattern that is possible if an only if the Car constructor has no side-...


1

Variables consume 64 bits or so, so 8 bytes. Primitives all fit in that, and objects are kept as references to the heap. So, we are talking about 16 bytes or so. I don't think that matters that much. Also, I just want to mention: Don't use getters/setters, they are bad for you! Setters more so than getters, but they're both bad. Object-orientation is about ...


1

In this specific case, it sounds like you just need a post-processing hook. In its simplest form, it could look like this: class BaseClass { protected virtual void PostProcess() { //No code, do nothing } public void Run() { //Do Task 1 //Do Task 2 PostProcess(); } } class A : BaseClass { ...


Top 50 recent answers are included