3

I am reviewing a proposed OO software architecture that looks like this:

  • Base
    • Foo
      • Something
    • Bar
      • SomethingElse

Where Base is a static class.

My immediate thought was that every object in any class will inherit all the methods in Base which would create a large object. Could this cause problems for a large system? The whole architecture is hierarchical.. the 'tree' is much bigger than this really. Does this sort of architecture have a name (hierarchical?!). What are the known pros and cons?

Teun Zengerink
  • 127
ale
  • 1,046
  • 1
    see: Where does this concept of “favor composition over inheritance” come from?, Why all classes in .NET globally inherits from Object class? – gnat Sep 11 '12 at 11:33
  • 1
    awful idea...... – Arnis Lapsa Sep 11 '12 at 12:03
  • 1
    @ArnisL. Not necessarily. Issues with inheritance and maintainability aside - if the objects can be represented naturally in hierarchical way, then it's the most natural way of doing so - which often leads to the most obvious, simplest and practical way of representation. Of course, in many cases you just can't force things into hierarchies, and as such it's often a bad idea. – zxcdw Sep 11 '12 at 12:12
  • 3
    You should really ask what they are trying to achieve by having the base class (utility methods, common data fields, leaving things open for some kind of dependency injection?). The relevant anti-pattern name is BaseBean, and I'm struggling to think of any scenario where you could keep the base light enough that it applies to all objects, yet still somehow relevant. As others have pointed out, however, performance is not necessarily going to be bad - it would depend on what's in that base class. – Daniel B Sep 11 '12 at 12:56
  • are you serious? – paxRoman Sep 11 '12 at 13:17
  • about what sir ?! – ale Sep 11 '12 at 13:34
  • @zxcdw Im sure you know what Im talking about. also - "natural" is a hairy thing in software world, "a square is not a rectangle" http://cafe.elharo.com/programming/a-square-is-not-a-rectangle/ – Arnis Lapsa Sep 13 '12 at 06:11
  • @ArnisL.True, it's unusual to express things in natural hierarchy, but it does happen in some cases. Building software design over this is an awful idea, as you mentioned. My intention was not to disagree, but rather to elaborate a possible case where simply mocking the idea as awful might not be that wise thing to do. Regarding your example, square is not a rectangle, but both are shapes. :) – zxcdw Sep 13 '12 at 06:40

7 Answers7

5

The real question is: WHY does the architect want everything to inherit from base? What's the utility of doing so?

If it's for something like serialization interfaces, then it MIGHT make sense if you will need a general serialization facility. But make sure that you actually will need EVERY class in the system to have that functionality. If you don't, then you end up needlessly inflating each class, AND you'll end up having to implement (or stub out) functionality in classes where that functionality doesn't make sense.

I would NEVER implement my own 'uber-base' like this in a system, because I can't conceive of any functionality or interface that I would want in EVERY object EVERYWHERE in my system. The only thing I can think of that it might be useful for is something like heterogeneous containers, but I've never been in a situation where I wanted a completely heterogeneous container - I generally want a set of classes, not just any random thing under the sun to go into my containers.

Unless the architect can demonstrate why they want this uber-base, I'd leave it out.

Michael Kohne
  • 10,046
3

What do you mean when you say "large object"? Memory footprint? That shouldn't really be a problem.

If the methods are static (is that what you mean by "static class"?), they're part of the class, not of each instance. But even if they're instance methods, they shouldn't affect the memory footprint of an object.

If you mean "large object" as in "containing a lot of methods that you rarely use", then... yes, that might be an issue. The shared base class should probably only contain methods that really are shared.

The question is what exactly do you aim to achieve with this architecture? the .NET Framework has a shared Object class, as superM mentioned, but after that, the hiererachy is flat, with most classes inheriting directly (though implicitly) from Object.

Avner Shahar-Kashtan
  • 9,365
  • +1. That's the point - one should really(!) question the reasons behind this architecture. – Doc Brown Sep 11 '12 at 11:40
  • "they're part of the class, not of each instance." - instance methods aren't replicated in each object either. How would you do that even? – Tamás Szelei Sep 11 '12 at 11:43
  • THat's what I wrote afterwards - methods, even instance methods, do not affect the memory footprint. Inherited properties and fields, though, might. – Avner Shahar-Kashtan Sep 11 '12 at 11:49
2

Having each class inherit from a single base class might create a large object depending on what you put in the base class. But, the advantage of this is that all the utility type of functions can be put in the base class and this will offer uniform implementation.

TheSilverBullet
  • 1,091
2

I'm not sure if such architecture has a name, but this is exactly what Microsoft has done (except that not all the methods in the base class are static). In C#, for instance, every type is inherited from the Object class. So every type has methods like Equals(...), GetHashCode() etc. In many MVC applications there is base controller, which is inherited by all controllers.

This approach has a lot of advantages. Here are some of them:

  • common interface for all objects
  • a set of mandatory features, which now every object will have
  • flexibility: new common features can be easily added
  • etc.

The disadvantage is that there might be objects which will never need these methods, but will still inherit them. Though this disadvantages can be easily ignored.

superM
  • 7,383
  • AFAIK that's not correct. Value types are not inherited from object in C#. Nethertheless you can use value types as objects because the CLR does automatic boxing/unboxing (see here http://msdn.microsoft.com/en-us/library/yz2be5wk.aspx) – Doc Brown Sep 11 '12 at 11:30
  • I don't know for sure, but the fact is you still have the common Object methods for them too. – superM Sep 11 '12 at 11:36
  • superM: that's because of the automatic boxing/unboxing. The compiler/runtime make "int i = 5; i.ToString();" transparent for you, but behind the scenes it's boxing a primitive '5' into a System.Int32. – Avner Shahar-Kashtan Sep 11 '12 at 11:37
  • @superM: there is a very good reason why value types are in fact no object - because the memory footprint of small types like int, char and byte would multiply. According to this http://stackoverflow.com/questions/631825/net-object-size the minimum object size is 12 bytes. Imagine if each 'C# byte' value would need at least 12 bytes in memory. – Doc Brown Sep 11 '12 at 11:45
  • IMHO your comparison misses also a second point - the OP was referring to a static base class. – Doc Brown Sep 11 '12 at 12:00
  • @Doc Brown, I've noted the difference in my answer. Besides, it only adds another advantage to the architecture. As Avner Shahar-Kashtan said, static members don't add "weight" – superM Sep 11 '12 at 12:05
  • @superM: you wrote it at the beginning, but your main C# examples "Equals" and "GetHashCode" make only sense for non-static base classes. Also your first two "advantages" are object-related, so not making much sense for a static base class. – Doc Brown Sep 11 '12 at 12:19
  • @Doc Brown, Equals has both static and non-static versions (that's why I used it as an example). and the third advantage is close to the first two, I don't know why you excluded that or mentioned about the first two ))) – superM Sep 11 '12 at 12:28
  • 1
    @DocBrown: Values types do inherit from object. All structs inherit ValueType which inherits Object, and System.Int32 for example is a struct. See http://msdn.microsoft.com/en-us/library/saxz13w4.aspx. The answer in your link specifically refers to reference types. – Misko Sep 11 '12 at 14:25
  • @AvnerShahar-Kashtan: I think Java may work that way, but in C#, int is simply a shorthand alias for System.Int32. There's no boxing/unboxing involved between the two. – Misko Sep 11 '12 at 15:28
  • @DocBrown now I`m curious. which language actually have this feature to inherit static class? AFAIK c# does not. – Arnis Lapsa Sep 13 '12 at 06:14
  • @ChrisMiskowiec int is a struct in c# http://msdn.microsoft.com/en-us/library/system.int32.aspx – Arnis Lapsa Sep 13 '12 at 06:15
  • @ArnisL.: why do you ask me? Ask the OP (probably he means a base class with only static methods, not a real static class in the C# sense). I was not the one who suggested this design. I am actually arguing against it. – Doc Brown Sep 13 '12 at 18:58
  • @DocBrown: According to the ECMA spec, when the Runtime sees a class derived from ValueType, it actually defines two kinds of thing: (1) a heap object type which behaves like a class which derives from ValueType and thus object; (2) a storage-location type which holds neither an object nor a reference to one. Given int x=32; object y=x; variable x will be a 32-bit word holding bit pattern 0x00000020, and y will hold a reference to a heap object of type Int32 which contains, among other things, the bit pattern 0x00000020. The latter derives from Object; the former does not. – supercat Apr 06 '15 at 19:12
1

My immediate thought was that every object in any class will inherit all the methods in Base which would create a large object.

This is incorrect. The reference to the parent type is an extra pointer at worst. If the base type has only methods or static members, it won't add much of anything to the subtype when instantiated.

Could this cause problems for a large system? The whole architecture is hierarchical.. the 'tree' is much bigger than this really.

Deep inheritance hierarchies are a code smell, sure. Having a common base class is often times troublesome because there are very, very few things that apply to everything and behave the same. It often leads to leaky abstractions and violation of the Liskov Substitution Principle.

Where Base is a static class.

This seems a little odd. If the base class is essentially empty from an instance member perspective, that runs into a variety of other issues. At that point specifying a variable of that type allows you to do almost nothing with it, which is... counterproductive.

Telastyn
  • 109,398
  • +1 for pointing out my error - thank you. Your last point about the static base class... do you think you would be able to provide an example ? – ale Sep 11 '12 at 12:03
1

A static base class will allow using of all public or protected functions and members of that base class everywhere through your object hierarchy, without referring to a specific class name (or namespace). This means you will just get global functions and members all throughout your system, which "disables" some of the main ideas of object orientation. You will get a much better architecture when you put those static methods into separate utility classes and group them thematically. Otherwise, such a base class could too easily become a "god class", which is a well-known anti-pattern.

IMHO the whole thing would make sense to a certain degree only if you

  • don't add any functions or members to the static base class

  • need a mixed-type generic container for your objects and you don't have any built-in language support for that

Doc Brown
  • 206,877
0

Short answer:

It seems the design is flawed.

I can't imagine how every class in the solution domain has an "is a" relationship with a single class, except they all inherit from Object, but that's another thing.

If you show us some real class names in that tree, I'm sure that will be obvious.

Tulains Córdova
  • 39,449