Tag Info

New answers tagged

0

To me in practice this question translates to 'Why write smaller code?', because in practice smaller, more unit-able blocks of code invite the possibility of nicer and cleaner design. Manipulating theses smaller blocks becomes much easier than the large ones, and they are more inviting to be refactored as needed. Now, my answer: after mulling over some ...


1

I don't think that id is a database artefact. How do you know that account you are working with is correct? You know it's a correct account because it probably has a unique identifier. In your case the unique identifier is called "Id", so naturally you think it's a database artefact. Because of this I think that it's perfectly fine to have Id property in ...


4

It depends. If your Account class shall be mapped to a relational database, then its not just a good idea, but proven practice, to use technical IDs for every table as PKs (and FKs, referencing those PKs). To my experience, separating the technical PK of all tables from the "domain keys" (like the "bank account number") works very well and helps you to avoid ...


1

Using a parameter object is a good way to avoid (excessive) overloading of methods: it cleans up the code seperates the data from the functionality makes the code more maintainable I would, however, not go too far with it. Having an overload here and there is not a bad thing. It is supported by the programming language, so use it to your advantage. I ...


0

I think this is a good candidate for the builder pattern. Builder pattern is useful when you want to create objects of the same type, but with different representations. In your case, I would have a builder with the following methods: SetTitle (Document document) { ... } SetFirstPageBlank (Document document) { ... } SetMinimumPageCount (Document document) ...


0

I honestly don't see a big problem with the code. In C# and C++ you can use optional parameters, that would be an alternative, but as far as I know Java doesn't support that kind of parameters. In C# you could make all the overloads private and one method with optional parameters is public to call the stuff. To answer your question part 2, I would take the ...


9

Maybe try the builder pattern? (note: fairly random Google result :) var document = new DocumentBuilder() .FirstPageBlank() .Name("doc1final(2).doc") .MinimumNumberOfPages(4) .Build(); I cannot give a full rundown of why I prefer builder over the options you give, but you have ...


0

We could also try to see the problem from another angle. Instead of thinking that the problem is the code duplication, we may consider if the problem originates in the lack of policies for code reuse. I recently read the book Software Engineering with Reusable Components and it indeed has a set of very interesting ideas on how to foster code reusability at ...


3

Let's start by defining what an abstraction is. In Agile Principles, Patterns, and Practices, Robert C. Martin defines an abstraction like this: Abstraction is the elimination of the irrelevant and the amplification of the essential What is essential, and what is irrelevant, changes with the client's perspective. From the perspective of the Composition ...


1

If we were to generalize the rule a bit and make it less legalistic, it might look something like this: Limit what each module/class/function/etc knows about the rest of the system. So you have two types of code: Code that glues our layers of abstraction together (App) The meat of the software that actually solves a problem (Book, Database) Glue ...


3

My interpretation is that the levels of abstraction don't refer to what objects a function can see; it refers to what it's actually doing. It's not inconceivable that a function may have to receive and pass along an object from a much lower level of abstraction in the process of delegating tasks to the level immediately below it. But it shouldn't be ...


5

Quick and easy: AbstractCharacterDelegator does not have abstract functions, but virtual instead. By default, they pass through to the wrapped character and can be overridden. Then you inherit and only override the few you want. This sort of thing isn't particularly useful unless you do quite a bit of decoration and your common interface is particularly ...


3

If AbstractCharacter has 15 methods, it probably needs to be broken down into smaller classes. That aside, there's not much else you can do without the language providing some sort of special syntax support for delegation. Simply leave a comment where all the delegation starts so the reader knows he need not look any further down. As for writing all the ...


0

Map your joints I suggest that after you've planned your new architecture, you should identify joints in your current code base, where a 'joint' is a place you can separate two modules in your old code (by a well-defined message protocol, a DB layer, etc.). Write and retire After you've mapped the system's joints, you can go ahead and write modules in ...


0

As so many have said before, whatever you throw in the air will always come back down. I believe in strong uniformity across a code base. Of course some things really do not matter that much. Naming conventions on local variables within a procedure for example. However for anything structural, it should be fixed right away, before the final merge into the ...



Top 50 recent answers are included